The depth of the confusion became clear to me recently when, as part of a research project, I had the chance to watch a huge archive of videos of users trying out mobile-specific apps and websites. The results were surprising. Many users struggled to figure out even basic tasks, and I saw the same design mistakes repeated over and over by different developers.
I’ve written a whitepaper on the findings, with many details and examples (you can download it here).* In this post, I want to highlight the biggest problem I saw in the tests, and what I think it means for all of us.
The most common problem I saw in the tests was users struggling with mobile apps and websites that prioritized beauty over usability. Too often, we as an industry equate an app that looks simple with an app that’s easy to use. Those are two entirely different things. Stripping all the text out of an app and hiding all of the buttons makes for a beautiful demo at TechCrunch, but a horrible user experience for people who are trying to get something done with an app.
We tell ourselves that this is OK, relabeling confusion as “intrigue.” How many times have you see an expert online say something like this: “Users enjoy the process of discovering new functions in your app as they gradually explore its interface and learn its hidden features”? From watching real people use apps, I can tell you that’s lunacy. What delights most mobile users is getting things done. The only time they want to explore an app’s hidden nuances is if they’re playing. In a game or other entertainment app, cryptic Myst-like interfaces make for an engaging puzzle. In all other apps, puzzlement is a sign of bad design.
Here are three examples of the trouble we're creating for ourselves:
Low contrast. A trend in modern graphic design is the use of low-contrast graphics and text: light gray or blue text on a white background, or dark gray text on a black background. It looks sexy in print and on the web, but causes problems in mobile. Smartphones are often used outdoors, in situations where any screen image is hard to see. Low-contrast items can completely disappear in direct sunlight. Often companies don’t realize that this will be a problem because they test their apps indoors, or do design reviews by projecting screen images in a darkened room.
If you think this is just an isolated problem, check out the weather app in iOS 7. I love the look of that white text that Apple superimposed over a pale blue sky with puffy white clouds. But can you read it? How will it look in the sun?
Cryptic icons. There are a few icons that mean the same thing on all mobile platforms. For example, the magnifying glass means “search” everywhere. But in most cases, the mobile OS players have used icon designs as a point of differentiation. The table below shows some conflicting icon designs in Android and iOS:
Some developers respond to this diversity by creating separate versions of their mobile app for each OS, with different icons in each version. But users are not as easily segmented. In the tests, I saw cases in which iOS users assumed the Android icon definitions, and vice-versa. The situation is even worse for a mobile web developer, who must use the same UI on all platforms. Which icon set should they use?
When icon designs conflict, they cancel each other out and mean nothing. Many apps are studded with icons that the developers think make sense, but that actually are just tiny meaningless pictures in the eyes of many users.
Missing help. I used to think the ideal mobile app would be so simple that everyone could figure out how to use it intuitively. I now realize that’s a fantasy. The tiny screen and other restrictions of a mobile device make it almost certain that people will sometimes be confused by your app.
When mobile app users get confused, the first thing they do is search in the app for a help function. If help is available and properly structured, the user can usually resolve the problem and get back on task. Unfortunately, in most mobile apps and websites, help is minimal or totally absent. I don’t know why that is. Maybe developers feel adding help would be an admission that their app is hard to use. But that’s like saying you shouldn’t put seat belts in a car because it implies the car might crash. Plan for trouble and your users will be happier.
What it means. The fixes to these specific problems are straightforward:
—Use high-contrast text (black on white, white on black, or pretty close to it). And test your mobile app or website outdoors, in bright sunlight.
—Label all buttons with text in addition to (or instead of) icons.
—Add context-sensitive help to every screen in your app (the help can be as simple as an overlay saying what you’re supposed to do on this screen and what the buttons do).
The harder part is dealing with the underlying design attitude that created these problems in the first place. I don’t know exactly when we went astray on design. Early websites were horribly cluttered, and in reaction to that we started to see a welcome move toward cleaner and simpler designs online (think of Mint.com, which took a complex subject like personal finance and made it feel accessible). The rise of the iPhone, with Apple’s strong emphasis on design elegance, reinforced this trend. But somewhere along the way, we lost track of the user’s needs. Instead of making things simple, we made them simplistic. We hid features for the sake of hiding them, rather than because the user didn’t need them. And we started designing software that would look beautiful to VCs and other designers, rather than being helpful to our users.
If we’re going to permanently solve the usability problems in mobile, we need to readjust our attitude toward mobile design. The most beautiful app is not the one that looks most striking; it’s the one people can actually use. You should design your app to be usable first, and then make it as pretty as you can.
The highest form of beauty is functionality.
__________
*Full disclosure: In addition to my startup role at zekira.com, I’m working on mobile strategy for UserTesting.com. They’re the leading “talk aloud” user testing service, and they gave me access to their test archive for the whitepaper. I controlled the content of the research and the conclusions. And the company had nothing to do with this blog post; I wrote it because I thought you’d be interested in the findings.
No comments:
Post a Comment