Click here to see the Exhibit Poster

Click here to see the Web prototype

In this prototype, users can send each other a "Is Now Good?" message. The process involves sending a contact a message, which requests their status and then changing your notification option based on the status you get back. Then, the user can update optionally their status when they receive your message, rather than the one they set passively.

Click here to see the interim Web prototype

In this prototype, messages can be sent with differing notification options. Before the message is actually sent, the user is asked to confirm their notification option. This proved confusing to users as the colour changes did not sufficiently communicate the change or the purpose of the change, as well as the message appearing to already have been sent before the notification option was confirmed.

Links to other pages

• Research (assignment and bibliography)
• User Testing Analysis and Designs
• User Testing Raw Data
• Standups

Design Process Overview

The start of this project was inspired by a conversation on a podcast known as Hello Internet. The question raised was "when is it too late to text someone?" (They also referenced this Curb Your Enthusiasm clip, which exemplifies a parallel problem nicely.)

From there, a great deal of desk research was carried out understanding existing systems for understanding and alleviating disruptions caused by notifications. This research considered several areas of investigation, such as automatic context-awareness through using machine learning and phone sensor data to infer user availability. It turned out this is a very difficult nut to crack because availability is not easily measured in most daily situations.

The calm computing vision for ubiquitous computing guided me to consider that the phone shouldn't be getting in the way of communication. Especially given papers I read on the updated vision for ubiquitous computing, the idea of taking agency away from users in their communications seemed like a bad idea that could fail easily and have negative consequences for the user and negative implications for privacy.

I undertook interviews with four participants, each with various uses and requirements for instant messaging. One is a landscaper, one is a professional working in the tech industry, one is a middle-aged professional with little technological know-how and the last is a younger adult who works in social media marketing. While there were many common themes, there were also several conflicting requirements, such as having chat history to refer to in a workplace and not having chat history to avoid records of social faux pas.

All of the user requirements and different problems and solutions offered up by research were swimming around my mind and I could not find a clear thread to follow. At this stage, the design for location framework came in handy because of its focus on motivation, aims and outcomes. There seemed to be a lot of approaches to take and a lot problems to try to solve, but returning to the motivation for the project let me take a step back.

At this point I realised that the problem boiled down to answering the question "Is now a good time to talk?" From early on, I had a picture in mind of someone quietly and studiously working on a laptop with their headphones on. How can you non-intrusively ask them if now is a good time to talk? The MyButler app seemed to do the best at solving this kind of problem and it had a hands-on approach, which I knew would be necessary.

Early on in this process, I understood that to get a proper evaluation of a design it would need to be tested "in the wild". That mean an app that was a functional chat app. MyButler used a peripheral app to KakaoTalk (an IM app in use in South Korea). However, they were hindered by this. The app still showed last-available times and read-receipts, two functions which I wanted to have control over as they cropped up as major issues in my interviews. The whole purpose of the availability awareness signifiers is to replace these functions because of their negative consequences as a result of inconsistent expectations and conventions users have with them.

So, a lot of my time was spent trying to make a fully functional chat app, which I could then layer availability awareness functions on top of. This was also helped by the design for location framework which made me realise one of my own priorities for this work was to learn more about app development. Although I did not get push notifications working (triggering notifications when the app is turned off), I got evertyhing else working to some extent. Chats were working between individuals, notifications were working (though not hooked up to message-received events) and adding contacts worked.

In the end, I had to scrap the app to have something ready before exhibition, so I tested out the UI design I had landed on. There were some glaring issues, including users not understanding the symbology or meanings of colours. The idea of having two interactions with a message, rather than just sending it, was a bit alien. Also, the inclusion of "Is now good" as a notification setting was confusing because it did not integrate properly with users current understanding of notifications.

After this evaluation, the chat feature was removed entirely to focus on the core idea: "Is now good?"
Users found this a lot clearer and understood the purpose of the app, however some weren't sure if they'd use it without the chat feature or at least a way to link up other messaging services.

Overall, this process really brought home the message that starting small and iterating many times can get you a lot further than trying too much at once. I knew this would be a risk when I started developing the app but was willing to take that risk for the possibility of getting genuine and incredibly fruitful user testing results. Researching and evaluating a social technology without proper social interaction between participants, while useful, is limited.