The Living Room UI

Just as we start talking about post-screen interface design (no UI! The internet of things! Berg! Etc!) it seems that TV as a medium may get a second renaissance. There are two new consoles around the corner, manufacturers are still pushing smart TVs and the idea of a la carte viewing might become vaguely compelling to the mainstream in the next five years. It is looking like the living room TV could be both the first and last screen frontier.

And with all of this going on I find myself talking to a lot of people about designing for this big, low resolution screen with its crappy peripherals and lazy users.

Viva la difference

Designing for TV is different, and it is not always the obvious rules that apply. It’s easy to start thinking about it in terms of what you might know from your desktop, or perhaps your tablet. In my experience the closest parallels to a TV experience are found in the most basic mobile apps out there. If you ever designed for a Nokia 3310 type device then you can skip the rest of this essay.

The data and interaction resolution on TVs is very low. The most common input method, the TV remote, is a crude device - generally four arrow keys and couple of function buttons. Even when you are talking about games controllers generally all you get are extra buttons (so. many. extra. buttons). Analogue sticks feel horrible when used to navigate an interface.

And then there’s the people. Even as we move through full HD and toward 4k screens, viewers tend to sit a fair distance from the screen; they lean back from the experience both physically and mentally. People switch on the TV expecting it to entertain them with zero effort. ZERO EFFORT. Anything you make them do, every button you insist they press is additional uncalled-for effort and therefore detracts from the expected experience. Viewers didn’t sign up to carry a heavy cognitive load, they’re not here expecting to expend energy thinking about the difference in meaning between the videotape icon and the movie film icon. No one wants to read lots of text on the TV, anything more than a tweet will make your eyes hurt and, you know, it’s not TV is it?

On top of this, viewers have deeply ingrained expectations about how their TV should work. The TV as living room campfire, a shared experience between family and friends, has been an established part of our culture for fifty years. Like fiddling with shirt buttons when we invented velcro six decades ago; logical arguments about efficiency don’t always make sense when you are discussing design paradigms that have sunk to a more primal cultural level.

OK, OK, OK… Go!

Luckily most people approach the TV with fairly low expectations. Generally viewers are happy to switch on to the channel they were watching the day before. There is a lot that hasn’t changed from those TVs you used to tune with a dial. 

For those of us designing marginally more complex interfaces the first test you should carry out is to close your eyes and press OK five times. Where did you end up? How quickly did you end up there? Did you get stuck in a loop opening a modal then canceling the modal then opening the modal then canceling the modal then..?

Defaults are important and the single most important thing about any screen is where the cursor defaults to. This is the path of least resistance through your experience and it should go without saying that this will match your key use case. The second most important use case? Well the button for that should be second in the list. In a TV interface, navigated with a standard remote, the button order and positioning is key. In a seven item menu the viewer has to navigate through all the items to move from top to bottom. If they are doing that every time they access the home menu then it is going to get frustrating pretty quick.

Think about how you flick through the TV guide on your cable - the mental model of how your controller affects the interface is about steps - step up, step left - rather than moving a cursor around the screen. For this reason try to cluster related functions, there is strange psychic effort required to push the cursor from an option at the left of the screen and have it jump through the void to one on the right. Remember our viewers don’t like to be forced into making any effort.

All this speaks to broader simplifications: Less text, fewer buttons per screen, a single red-line flow per use-case. Additional features have additional flows: by all means give more to the lean-forward user, but keep it out of the way of everyone else.

Pretty soon you will find yourself faced with some interesting problems that require more flavoured solutions (and flavoured solutions are what distinguishes one product from the next) - what is the key information a player needs to choose a level and what can be deferred to a “more details” screen? What do you default to when a returning user boots up the app? How do you jump to audio controls at any point during the experience? What is the story here?

A Note On Hardware - All those wonderful buttons

Don’t be afraid of controller buttons. It is not only my experience, but proven by the console gaming industry in general, that viewers seem to be less freaked out by loads of physical buttons then you might expect. Of course how you educate viewers about which button does what is another problem entirely.

A Note On Hardware - The Screen Itself

If you are designing on your lovely third generation Macbook Pro then you are doing it wrong. Get an HDMI adapter, get a TV, move fifteen steps away from the screen. Suddenly your text is too small and that background is too fussy. And even more surprising is that, given your safe zone, there are still elements of your design cropped by the edge of the of the screen. Note: the plastic bezel around the edge of the screen likely overlaps some of the display. 

Mike Green

Glowmade Ltd, 77 Walnut Tree Close, Guildford, England, GU1 4UH