As VoD specialists, we have done plenty of user testing in front of TVs. When we’ve created prototypes for TV, we’ve noticed a few differences from the prototypes and tests we have created for websites and mobile apps.
An important design constraint is the input device: the remote control. Despite TV being a much older invention than the computer, internet connected TVs are relatively young and present a disparate landscape for users and designers. When designing for TV UIs, there are fewer established design patterns to draw on, which gives us flexibility, but also means that we can’t rely on the common user habits and learned shortcuts that we do on the web. Third party apps on Smart TVs are opening up the TV platform, but it is early days yet. Experience has taught us to keep the essential interactions mapped to the most familiar and common remote control buttons. Any additional functionality can be mapped to less common remote control buttons or moved to on-screen menus.
Wireframing these interactions is also a challenge. For each UI state you draw up, you need to consider what each button on the remote control will trigger. It is much more complicated than traditional mouse point-and-click UIs that we are used to. A typical mouse has two buttons and scroll control, whereas a Smart TV remote control typically has 40+ buttons. As a design prompt and to help maintain consistency, we created a wireframe template where the common remote control buttons mappings were listed and we just had to fill in the annotations.
During user tests, remote controls can be a pain. There is no consistency between platforms, brands and models and they have buttons doing different things, with different icons and different labels. We have seen that users normally have 1-3 TVs at home, so it often takes users a little while to adjust to an unfamiliar remote control in the lab and sometimes they will need instructions or help from the test moderator. Remember that you are testing your app prototype, not the remote control used in the lab. We have found that pertinent on-screen prompts and hints about button functionality can be helpful, but are cautious of relying on them as some users will not or cannot read the copy.
Another constraint when designing for TVs is the processing power available to exploit. It is easy to overestimate people’s expectations with TVs from a design perspective, but people expect them to be at least as responsive as their own TV. On the web, we are used to animations and fancy designs, but with TV we have to restrain ourselves. As Google suggest, it is best to think of a TV UI as comparable to a mobile phone rather than a website viewed on a laptop. Rendering web-like designs on a TV can result in lag and an unresponsive app, so design should be seen as a lower priority than responsiveness.
To mitigate, use design best practice: Do use square corners, not rounded Do use a condensed font No or limited gradients and transparencies No or limited animations
We will continue to learn and respond to changes with TV hardware and software. There are many useful resources that we refer to when approaching a new project, pick of the best listed here.
- Google TV’s invaluable design guidelines
- Remote control text entry design solution
- An old, but sadly still relevant, post about remote controls by Nielsen Norman Group