Apptui Remote UI

Brief:

Design the user interface for an app that turns mobile devices into universal remotes for computers. 

Design Principles:

This was one of my earliest projects at Apptui, so I spent a significant amount of time trying to understand the founder’s vision and how he planned to differentiate the product from a handful of existing, but popular computer remote control apps that were available at the time.

After several discussions with the founder and team, it became clear that there were 2 key design principles shaping the first version of the product.

1) A Truly “Universal” Remote Control for Your Computer

Existing remote control apps tended to fall into one of 2 categories – i) single purpose remote control apps for specific websites or applications (IE: VLC Remote, iTunes Remote, Grooveshark Remote, etc) or ii) more general computer control apps that were designed to serve as mobile replacements for a wireless mouse and keyboard (Mobile Mouse, HippoRemote, etc).

We wanted to combine the two categories and create a remote control app that could work both as a wireless mouse and keyboard replacement and as a remote control for popular websites and desktop applications.

2) A “Smart” Remote

One of the founder’s earliest ideas was that the remote should be “smart”, meaning that it would be aware of what the user was doing on their computer and change the remote’s interface to show controls specifically for the active desktop application or website.

For users, this meant that they would get a remote for whatever they were doing on their computer, when they were doing it – for example, a Netflix remote when they were on Netflix, an iTunes remote when they were in iTunes and so on.

Prototyping:

Our first prototype employed a tab bar style user interface.

We opted for a 2 tab design with each tab focussing on a different “type” of remote controls for a user’s computer:

1) The left and primary tab focussed on general computer control, giving users a trackpad and keyboard as well specialized controls for browsers to let them navigate the web and zoom webpages.

2) The right tab gave users site or application-specific functionality such as the ability to play or pause songs and videos, search a website and navigate menus.

Usability Testing:

Usability testing revealed that the users didn’t really understand the tab bar UI inside our prototype. Comments from testers suggested that they weren’t thinking about the remote in terms of the different “types” of control that each tab provided.

Rather, users seemed to be thinking about the remote’s interface in terms of things they wanted to do “right now”, at a particular moment in time (IE: “I want to go to Netflix“, “I want to lower the volume“, or “I want to pause this song“).

Note: In retrospect, it’s clear that this was a bit of a UI design blunder.  We mapped the design far too closely to the software’s “implementation model” and not at all close enough to the user’s “mental model“.

Sketching:

Not keen on having the team develop another difficult-to-understand UI, I sketched several alternative designs, very much keeping in mind the goals of the product and the results of the first round of usability testing.

Given users’ responses to our first stab at the UI, it was clear early on that the next iteration needed to be significantly “lighter weight” than the tab bar version of interface. 

Eventually, I landed on the idea of an interface that had only one view – the remote for the active website or application – with all secondary functionality tucked “one tap” away in popover menus. I explored a few variations of this idea at low fidelity before settling on a design that was made up of two distinct zones:

1)  A common “top bar” containing a series of controls in popover menus for standard computer and browser functionality.

2) A specialized “remote stage” zone with controls for the website or application active on the computer.

Visual Design & Development

Our visual designer created compelling visual designs to “skin” my rough sketches and I implemented them in HTML, CSS and Javascript, adding new features and UI conventions as required.

Result:

The new interface design was a success. It performed well in further rounds of usability testing and also left room for new features to be added from our growing product backlog.

Most importantly though, real users loved the app. Our retention rates were and are (at the time of writing) above industry standard and we’re lucky enough to occasionally receive kudos from happy users.