I would have preferred to have a working mock up, but as we were all doing this as a side project and we had so many features, this proved impossible. So a comic had to do.  Should we have done something simpler which was easier to convey? Well, time was a constraint, there were no clear guidelines, no client, nothing at stake, so I think we just indulged: it’s a lot more fun to develop an idea than a prototype. And even if the philosophy behind the group of features we presented wasn’t explicit and we could be accused of lack of cohesion, the audience were experts in the industry, we expected them to be knowledgeable enough and trend-aware enough to put the pieces together and see the concept behind :)

You can see the prototype here.

I worked on this project, some time ago, with Wenzhu, Valentina, Paulo. When I was told we had to design a remote control for elderly people, I googled it, and then sighed. Usually I try to avoid the “yet another…” projects but this time it was not up to us, so I set to work thinking at least that socially it was quite a relevant project. Actually I learned that most developed countries have around 10% 65+ people (I knew it was a lot, but 10% is mind blowing) and that they watch TV an average of 3,5 hours a day, so it makes sense to want to adapt remote controls for their especial use.

What I didn’t know, or had never thought about, is that remote controls have been around since the 50s (commercially) and have been popular since the 70s. So these people actually lived pretty much their whole lives with remote controls, it’s different than with computers, it’s just that:

1. Remote controls have radically changed
2. Their bodies have radically changed

So we focused on this.

As a first step, we created a user profile using literature and previous studies of  remote controls for the elderly. This is it:

• Age: 60+
• Health:
  - Cognitive: Tasks that use well-practiced skills or familiar information are generally not affected by age. However, complex tasks that require taking in new information and analyzing it may become more difficult. Many researchers attribute this to deficits that occur in attention, speed of processing, and memory. Many older adults have increasing difficulty distinguishing between information that is relevant and information that is irrelevant to a particular task (attention problems). In general, memory tasks that are complex and require manipulating a lot of new information quickly become more difficult with age. Well-practiced skills and abilities remain intact.
  - Sensorial: Weak vision, more light needed to see clearly. Decreased ability to hear high frequencies and sounds in general. Low sensitivity to touch.
  - Motor: Diminished dexterity and coordination compromise fine motor skills and strength diminishes. Limited finger reach distance when gripping. Weak hand grip, slow reaction, poor accuracy.
• Gender: male/female (more female than men).
• Experience: Unfamiliar with technology in general, for most of their lifetime electronics didn’t exist or were very simple. However, they have experience of using a TV remote control. Someone who is 60, was in their 20s when the remote control was popularized, however this kind of remote controls were a lot simpler than modern remote controls.
• Goals: Change channels, adjust volume, turn on/off the TV.
• Needs:
  - Social and emotional needs: independence, a way to occupy their time / entertainment, self-confidence, inclusion.

After identifying the goals, we did a task analysis. In this case, it’s interesting because as the users have cognitive, sensorial and motor impairments the task analysis looks quite different than you’re used to. Really simple stuff can be an issue so everything has to be included, all the trivial steps being present. For example, to turn on/off the TV:

Although interpreting feedback as to whether the TV has been effectively turned on or off may not in general be a problem with the average user, it can be for elderly people. Changing channels (without zapping) is even harder:

So we did this for every goal and identified the problematic stages through an heuristic evaluation based on our users’ cognitive, sensorial and motor health. Some difficulties we identified in current remote controls are:

• The decreasing size of remote controls means small keys and small labels that people with visual disabilities find inaccessible. Some people are unable to distinguish between certain color combinations used on keypads.
• Hearing impaired users cannot identify commands or controls that require hearing, so visual or tactile feedback when keys are pressed would be recommended.
• Some current remote controls have a huge number of keys for various functions. Those with cognitive impairments may have particular difficulty in learning the function of so many keys.
• Due to reduced mobility and manual dexterity lifting and carrying a remote control or pressing small keys may prove difficult for those with physical impairments.
• The existing remote control is too large and uncomfortable for holding.
• Most elderly people often make mistakes of operation, pressing the wrong button.
• Layout of menu selection: elderly people need to memorize and navigate through the location of buttons since there are approximately 19 – 30 buttons.
• Most elderly people do not know what the outcome of their actions is, feedback is not appropriate.

And then we made some design choices. It’s strange, because if you look at our report on the design (and I’ve seen this in many reports and presentations) the fact that we made these choices and why we made them is not explicitely stated there at all. The likely reason, I think, is that many of these design choices are only supported in some obscure place in the back of our brains by anecdotal data that managed to make an impression on us. The problem is that on the way to become a UX designer we’re told a hundred times to run user tests/studies and not to trust anecdotal evidence, so we just ignore these choices, never write about them and the result is that most people don’t even realize that these were choices at all (meaning that there actually was another way to do it). However, UX design isn’t and shouldn’t be (else no innovative interfaces would ever be created) a purely scientific discipline. Let’s say that your design should always be exclusively and logically derived from user study results, well there wouldn’t be a lot of variety then. Intuition, power of observation and willingness to take some risks are as essential to UX designers as whatever knowledge about how to run a within subjects summative study and do some t-testing afterwards. Actually, IMO, anyone can read a couple of books and learn how to carry out a user test, it’s the ability to use intuition and derive successful results from it (and the ability to recall some curiosity you observed in the subway, at the right time, and use it well) that makes the good UX designer (and separates him/her from the self-proclaimed-UX-designer developers). This can only happen if you have trained you brain to think as a UX designer, then he’ll do the work for you recalling and bringing up the right idea at the right time. But you know what they say (UI developers, I’m looking at you), Rome wasn’t built in a day ;)

We didn’t have time to run a user study before going on to design the first iteration. So, a considerable number of our most important choices were based on facts like: my grandmother and Valentina’s hold the remote control in the palm on one hand and press the buttons with the index of their other hands. Just like this guy:

So we thought, wouldn’t it be nice to afford this? Most remote controls for the elderly are simplified versions of the regular ones, with bigger buttons. But the buttons are distributed all over the surface and this makes this kind of gripping very uncomfortable.

Most remote controls for the elderly have only “arrow up” and “arrow down” zapping buttons. This simplifies the interfase but makes it annoying to change from channels that are far apart. At the same time, most of the elderly we know only watch a small range of channels. So why not try some favorite buttons?

So this is what we made:

And these are its features, explained:

• Functions: favorite buttons (the green ones with varied shapes, featuring shortcuts to a set of favorite channels, based on the fact that it is likely that elderly people most usually watch a restricted set of channels repeatedly), zapping buttons, volume buttons, on/off button, sound on/off button, back button (undo one step button, that takes the user to the previous state of the system in the event of an error given that operation errors are one of our users concerns), mute button. The remote control was stripped of all other possible buttons to keep it simple and just address the primary needs of our users.
• Feedback: feedback for battery level in the back, just like the led lines in a MacBook (some elderly people have trouble changing the batteries, so it could be helpful for them to have a battery level indicator and ask relatives or caregivers to change their remote control’s batteries if they are about to be empty when they have the chance). Also, some buttons (on/off, volume, channel, back) are backlit for a small time window when pressed to indicate a change in state (this allows users to feel more in control of their actions, having better knowledge of their outcome). Some other buttons (favorite buttons and mute) stay backlit when pressed to indicate current system state.
• Shape of the remote control: Thin and narrow to be suitable to hold in the users’ palm. Anti-slipping surface for better grip. Light in weight. Wide infrared pointer that extends towards the back of the remote control (the elderly sometimes have tremors or their accuracy is diminished, so having a big pointing surface helps them to aim at the TV more easily. Also, it can be useful to people who have vision problems to be able to hold the remote towards them to better see the buttons while still pointing). A hand strap is provided to secure the remote to the hand of the user.
• Physical characteristics of the buttons: Buttons are big and well spaced to avoid operation mistakes and facilitate their recognition. They are also grouped according to functions and the layout matches usage patterns, having buttons that have to be pressed repeatedly (zapping and volume) in the most accessible positions. A concave shape for the buttons gives tactile feedback indicating the user that his/her finger is in the right position without the need of visual feedback. Haptic feedback when the buttons are pressed allows users to feel more in control of their actions, eliminating uncertainty towards the completion of an action. Buttons are soft and not much pressure is needed to press them (a decrease in hand strength is one of the signs of aging, also accuracy increases when force diminishes, so this is expected to reduce the number of operation mistakes).
• Other features: A caller is embedded in the remote, so that the user can attach a sticker button to the TV and press it to have the remote control light the buttons and beep a sound for findability (this is expected to particularly help users with memory problems to locate their remote control if they forget where they have left it).

We went to a retirement home and tested our remote control with our users (the test was controlled replicating the tasks with an ordinary remote control). The test was quite messy, because it’s not every day that some new people arrive at a retirement home and ask for help testing some piece of gadgetry ;) but our participants were super helpful and the results were quite nice :) Here they are:

1. They liked the shape of our remote control very much. They emphasized that the shape was a perfect fit for the way in which they hold the remote.
2. They thought the size of our remote control was good. Their hands were able to grab it tightly.
3. Finder function: this function was not implemented in the prototype but the idea was explained and the feedback was positive.
4. Favorite channel button. The participants’ favorite channels amount to not more than 4 in all cases so the number of favorite channel buttons implemented is enough for their requirements. The different shapes of favorite channel buttons did not confuse the users, but helped them memorize them. Feedback was positive for different shaped buttons.
5. The users did not understand the function of back button. One mentioned reason was that the text (“back”) on the button is in English. Another reason is that they confused the back button with the backwards arrow in the zapping buttons. Using “undo”, they mentioned, would be better than “back”.
6. Wider infrared pointer feature was not tested.
7. Battery level indicator: one of the users pointed out that she asked other people to change the battery for her every time. None of the users gave the feedback on whether the battery level indicator was useful for them or not.
8. Sound and light feedback on the buttons. This feature was not implemented in the remote control prototype either. The concept was explained to the users. However, it was difficult for them to understand it. In the design, once a button is pushed, this button will be backlit for 5 seconds; however, the users’ assumed that once a button is pushed, the TV screen or TV would be highlighted. Maybe with a working prototype we could be luckier :)
9. The hand strap was not implemented in our prototype. After listening to an explanation, the users thought this feature was not necessary without stating any reason.
10. The users gave the positive feedback about the buttons being big and the layout being simple. Even though there are 11 buttons only, they include all the functions the users used daily. They suggested labels would be a good addition, because they would be able to know the functions of buttons more clearly.

So, not only was the feedback positive but also our users’ preferred features were those that came up seemingly out of nowhere and that no other remote control for the elderly we surveyed had: the weird shape and the favorite buttons. And I think this is a nice morale to this story about how it’s never the case that everything has been said about something, no matter how many commercial versions are there, and not to be afraid to add some deliberate serendipity to the design process sometimes :)

Link to full report here.

Around a month ago, I got to do my first solo project. With great power comes great responsibility and, luckily, the ability to choose the subject that better suits my interests :) And this is how I embarked on the redesign of browser error messages.

Browsers are old. It’s weird. I would have thought that major industry players would have figured out this kind of core issues by now. Error messages are not about new or experimental interactions, their design is probably as linked to basic UX design principles as can be. That’s why I was startled when I started to get the answers to my questionnaire… users mistaking DNS errors with HTTP 403 response codes and attributing SSL certificate warnings to malware. There’s a lot of educated talk on the web about how bad some error messages are, these however are savvy users’ rants and none of them come close to describing how the average users misses on their web experience, one of my participants even describing the experience as “distressing” :S

Anyway, after a week of questionnaires, qualitative analyses, guideline drafting and prototyping, I came to understand why error message design is not a popular discipline and some other interesting conclusions.

I’m posting the guidelines I came up with here, and if you feel like reading the whole analysis and taking a look at my redesign, you can download it from here.

These are my guidelines for error message design, illustrated with some examples taken from the browsers I studied (IE, Firefox, Opera and Chrome):

1. Explicitness: messages should make clear that something has happened. Either there was an error or the system is trying to warn the user because it encountered a potential threat. This error message (in the form of a Live Search result page with no results) appears in IE when the address includes a character that is not allowed as part of a URL. It fails to be explicit. The users I interviewed thought that they got this page because the browser had misinterpreted their intentions: they wanted to go to a website but the browser “thought” they were trying to look for something using the search functionality embedded in the address bar.

2. Human readability: error messages targeted to people should be readable by people. They should use human language and avoid obscure codes. This Opera error message is an example of what shouldn’t be happening: the term “illegal URL” accompanied by the ASCII code of the disallowed character carries no meaning in human colloquial speech.
3. Neutral tone and politeness: error messages should carry a neutral tone and be polite, avoiding placing the blame on the user. In this Firefox message, where it reads “did you make a mistake [...]?” could be, according to this guideline, rephrased as “are you sure this is [...]?”.

4. Precision: error messages should tell the user exactly what happened or allow them to diagnose what the problem is. As different users have different levels of expertise and facing the risk of being overly verbose, this is arguably one of the trickiest principles to master. This Chrome error fails to achieve this (even in the case when the user has typed the URL in the address bar, it mentions a broken link) while the Firefox error above was found to be too verbose for the users to read.
5. Inclusion of advice: errors should include advice for the user on what to do next, how to tackle or solve the problem. Error messages are part of a dialog that is taking place between the user and the system as a strategy leading to solving a problem that has arisen. In such a context, the responsibility of an error message designer does not end once the message is displayed. Suggesting and anticipating user response is part of error message design. When designing an error message, it is important to keep in mind that how much the user will trust an error message and will engage in performing a suggested action (presumably enhancing his/her experience) depends on the accuracy and simplicity of the advice. This Opera error prompts the user to check his/her Internet connection and this is what the users I interviewed said they would do if they got this error: “check the cables, check the router, look at the Wi-Fi icon”.  Checking if the user has an active Internet connection can be done automatically by the browser when this kind of error is triggered saving a lot of useless work and frustration on the part of the user. This guideline is probably the single most important piece of advice in the quest to create intelligent messages that can effectively dialog with users and to end the current paradigm that makes users see error messages as a dead end.
6. Focus on the user: error messages are, from the point of view of the user to whom they are targeted, a response of the system to an action performed by the user. As such, to understand from his/her point of view what caused this error and how to avoid it in the future, the user is interested in seeing a message as a response to his/her action and not an obscure technical complication that arose from the action. From the point of view of the user, the error from which Opera shows this message may either be the result of the user clicking on a broken link or the user misspelling a URL the fact that the address could not be resolved because it contained disallowed characters (although it is valuable information for the user and can help troubleshoot the problem) is not a straightforward response for his/her action.
7. Conciseness: error messages should be short and to the point. They are an interruption to the optimal process in accomplishing the user’s action and they should consume the less possible time. Lack of conciseness or overly complicated messages, can result in the user disregarding the message and abandoning their goal. In the case of this Firefox error message, for example, even if the first suggestion pointed to the right course of action, users failed to read the message at all, misidentifying the cause of the problem: they said that if they got this message they would check their Internet connection.

8. Context: error messages, when possible, should be context relevant. If the same technical complication occurred in two different scenarios (in this case, for example, when clicking on a link or typing a URL which can be discriminated by the browser), context can be the answer to providing sensible error messages. In the case of error message above, asking the user if he/she made a mistake when typing the URL is irrelevant if the user just clicked on a link, as well as in the case of this Chrome message stating that the link is broken is inaccurate if the user typed the URL.
9. Appropriateness and potentiality: error messages, and especially warnings, should convey the right degree of alarm. It should be apparent for the user that the danger involved in accepting a certificate that is valid when the date settings in his/her computer are incorrect does not offer the same security risks as accepting a certificate whose serial number was issued for a different website. All of the SLL certificate warnings of the browsers I studied (IE, Opera, Chrome and Firefox) failed to do this. This can be frustrating for the user that misses on his/her experience, or worse it can result in the user disregarding the importance of more serious warnings.
10. Clarity of origin: error messages should make clear that they are a normal part of the interaction with a system and they are not inherently something bad. As well as the user is not to blame for an error, error messages should also be designed in a way that avoids the system as being perceived as defective on the part of the user when this is not necessarily the case. For example, when users were presented this message, although it represents the intended response for the user action, users considered the system to have malfunctioned and mistaken their intentions.