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.

During our week-long course with Bert Bongers; Maria, Valentina, Dominika and I redesigned a toaster. You may also want to read part 1 and part 2 of this series of posts to learn about the concepts that we put into practice. Part 3 presents our analysis of the current toaster, and our redesign.

I’m not going to say that were doing our device parsing when we came across something interesting. I’m not going to do that because everyone knows that after you’ve toasted a first pair of slices of bread, it requires superhuman ability to get a second pair equally toasted. However, I’d like to point out that, had we though that this randomness was part of a “surprise me” feature in our toasters, we would have realized that something was wrong with the interaction anyway, when doing the device parsing.

The image on the left shows how there’s something wrong with the mapping between the input and the output, between an action on the part of the user (setting the timer) and the desired outcome (how toasted the toast is). This is a gulf of execution problem.

Depending on how hot the toaster already is and some technical characteristics, the outcome for the same knob position varies. Suposedly you can tell this because you had a look a the components, which is not really needed in the case of a toaster because I guess most people know how it works already. But, in any case, even if the output didn’t vary with variables other than the input, numbers on a knob don’t actually tell you anything about how toasted the toast will be. If you encountered this toaster for the first time, how would you know which number to choose?

So we went on to redesign the toaster for the mapping to make sense. To help the mapping, we kept the knob, but instead of having numbers we introduced the coding in the picture on the right. This is very nice as an interface, no room for ambiguity. But… how would it actually work in terms of the components of the toaster? The current toaster has a timer associated to the knob, you set it and after a while the toast is “ready” (whatever that is). Changing the numbers on the knob for pictures above will solve the mapping problem, for example for first time user of a toaster that doesn’t know what the knob is for, but will not help with the “random toastedness” factor, something inside the toaster has to change: the timer. This is the prototype for our “deterministic toaster”:

There you can see our Flash toaster (in the laptop’s screen) for which you enter how much you want to toast your bread with the knob on the bottom of the picture (to the right of the center) using the coding showed in the previous paragraph. The flashlight (blue thing on top of the plastic cup) lights the toast (green paper thing) so the webcam (white thing) can read the RGB values for the color of the toast . As bread  gets toasted, it emits different amounts of red, green blue and total light, so if you read these values you know (or the toaster knows) how toasted your bread is. We measured this in real toast, obtaining the curve on the right.

Now, replace the flashlight with well mixed RGB light, the webcam with a RGB sensor, compensate for the red glow of the resistor inside the toaster and the initial color of your bread. And when the toaster determines that the color of your toast matches your settings it can pronounce your toast “ready”.