In July, I went to The Usability Week 2012 Conference hosted by the Nielsen Norman Group. One of the talks I attended was about “Mobile Application Usability for Touchscreen Phones and Tablets”. We were given statistics on mobile adoption, usage rates between phones and tablets, and nuances between the iPhone and Android variations. The presentation concluded with guidelines and best practices for mobile usability.
These guidelines won’t surprise user experience practitioners, but they’re important and worth repeating:
- Make your application interruptible
- Make it fit your orientation
- Make it responsive
- Make it easy to use
When examined closely, they boil down to fundamental usability principles, but the mobile context gives it a unique spin. I see these situations in problems we try to solve at Intelliware, and I’ve seen them in applications that I use regularly.
Make a design interruptible.
A lot of factors contribute to how we interact with our digital devices. Determining the type of device we have is an easy one. Is it a tablet, a smartphone or an e-reader? We can detect this relatively easily and with a fair amount of accuracy. Environmental and psychological factors are a lot harder to predict and are, therefore, the most difficult to design for.
Is the user moving? If they’re in the subway, they could lose their data connection. Is the user fatigued? They could fall asleep while reading their e-book. Do they have children? What happens when the phone rings? What happens when their battery runs low? Perhaps, they don’t understand something or need to look something up – how do they do that?
In these and many other scenarios, the users are physically or mentally removed from their tasks. Sometimes they begin their task half-focused, other times they’re interrupted in the middle of it. We make our designs interruptible for unforeseeable changes to context. Ultimately, that means when a context switch occurs, we need to allow the user to suspend our application and resume safely.
- Include contextual cues like a meaningful title. When the user is interrupted, they will need clues to re-orientate themselves and remind them of the task they were doing.
- Fail safely. For tasks with serious repercussions when interrupted (e.g. completing a financial transaction), provide a failing mechanism that will allow the user to resume at a more convenient time. “Lost connection” or “Timed out” dialogs are examples of these scenarios; they let the user know that the transaction didn’t go through and that they need to try again.
Make the design fit the orientation
Responsive design is a popular approach to addressing different screen sizes from different devices. It uses a fluid framework to adjust content blocks to fill the screen (or to downgrade to a smaller resolution) regardless of size. Just as we consider different screen resolutions, we need to be mindful of how our design choices affect device orientation, i.e. landscape vs. portrait.
When translating from a wide screen to a narrow screen, content may be crammed together which leads to an uncomfortable reading experience.
Conversely, if we go from narrow to wide, we risk disassociating content.
- Use traditional design elements like lines, shapes and proximity to connect page elements and to direct the user’s eyes.
- Use the mobile-first approach; at least as a content prioritization exercise.
- Test, test, test! Unfortunately, this isn’t something that we can automate. Have someone who is not on your team look at it. Better yet, have your intended users look at it.
Make the design responsive
People are impatient. People want to interact with things and they want immediate gratification from doing so.
At minimum, we need to give the user enough feedback to indicate that the application has received their input and is working on executing their request. This can simply be a “please wait” message.
The faster we give the user the end-state, the better the experience. What would make for a more positive experience would be to connect the resulting screen with the input screen through a series of interim states using animations. It’s an opportunity to delight the user and an opportunity to teach the user how your application works. On the backend, it may also buy you time to calculate the output before the animation finishes.
Take Angry Birds, for example. Aiming the bird is the input. Settling the dust after the bird has crashed is the end state. By following the bird’s path to its target, the player is gratified by the transparency of how their decision impacts the outcome. Furthermore, it tells the player that their goal is somewhere to the right of the screen, implying the user can pan left and right to see the entire landscape before they make a decision.
Such a robust animation makes sense for a game. In applications where performance is key, we should engineer the system to respond with the end state as fast as possible.
- Use animations. The most popular example being the loading animation. But in general, movement means progress; it communicates to the user that something is happening. Using an appropriate animation can also help the user learn about your application.
- Tell white lies. Have your application respond in the front end as though an action has been completed, even if it hasn’t, then complete the action in the background. Use this approach only when it does not render immediate consequences. Then do it in the background.
Make the design “intuitive” easy to use
Intuition is a deceptively ambiguous concept. Everyone has a different mental model of how the world works that is shaped by their own unique experience.
A lot of times we approach intuitiveness by designing the application to mimic the real world. Skeuomorphism is when we try to make software look like its real world counterpart, but many of the functional elements from the original design are retained for aesthetic reasons. A leather-bound book is good for grip and water-resistance; an application with a leather-bound splash is decorative.
There’s nothing wrong with skeumorphism in and of itself; however, when we try to translate that physical interaction to the digital medium, we often create an unnatural interaction with the device. The mental model for that physical object doesn’t align with our mental model of the device.
For example, your interaction with a physical piano is similar to how you would interact with the digital version. Skeuomorphism lets the user know that this is how you should interact with the device. On the other hand, the Pocket Trumpet is a less well-designed application. The user interface displays the 3 valves of a trumpet from the profile-view. It requires you to scrub the screen up and down to create a sound. While swiping the screen is a familiar gesture for the device, it’s an unnatural way of interacting with a real trumpet which requires your fingers to push down on the valve. A better, but not perfect, metaphor would be to display the valves from the top.
- Aim to make features discoverable and easy-to-use rather than “intuitive”. Use skeuomorphism judiciously.
- Use visual affordance to make action elements appear as though you can interact with it.
In summary, pay attention to the context in which your application will be used and respect that the user will be trying to do a million things at once, by choice or as required. Think about the device and the platform, but don’t forget about the orientation and scale. Usability is only one aspect of user experience; respond fast, respond accurately, respond in a way that the user expects and in a way that will delight them. Finally, don’t overcomplicate it! Be simple and direct. Fancy animations and beautiful graphics can get in the user’s way unless they are deliberately designed to achieve something – engineer them that way.