Although mobile devices have been around for more than a decade, software developers are still figuring out the rules of what makes a great mobile app. Ironically, one of the biggest barriers they face is the legacy of successful software development on the web. Most developers today grew up in the web app world, and have absorbed the assumptions and best practices of that world so thoroughly that they’re not even aware of them. Those assumptions often steer a developer onto the rocks when creating mobile apps.
One glaring example is the issue of help
In the web world, the ideal is to create a web app that requires no built-in help. The experience is supposed to be so compelling, and so intuitive, that the user will naturally flow through it without any need for assistance. Adding help is seen as an admission of design failure.
This help-free approach is encouraged by several aspects of the web app environment. The first is the use of tooltips: the little explanatory text boxes that pop up whenever you hover your mouse over a button or icon in a major website. Tooltips are almost ubiquitous because they’re incredibly useful; they enable a user to discover what anything on the screen does, without having to actually click it and possibly make a mistake. Tooltips are a hidden layer of built-in help in web apps, and encourage users to explore a website without fear of doing something wrong.
Another important characteristic of web apps is the developer’s ability to monitor user behavior in exquisite detail, and make changes to the website on a daily basis. Although there’s intense discussion in the tech industry about the privacy aspects of user tracking, the most common use of tracking today is to aggregate statistics on what users do in a site, to determine whether it is well designed. Do users abandon the purchase process at a certain point? Do they fail to click where they’re expected to? A web developer can determine this in real-time, and make changes almost as fast.

Editor’s note: Developers! If you’re good and want to be great, our upcoming DevBeat conference, Nov. 12-13 in San Francisco, is a hands-on event packed with master classes, presentations, Q&As, and hackathons, all aimed at boosting your code skills, security knowledge, hardware hacking, and career development.Register now.

This combination of detailed tracking and fast changes makes it possible for a developer to quickly evolve a web app into a finely tuned instrument that is more or less effortless to use. This is such a standard practice that a mantra of web startups is that they should try to ship an embarrassingly bad first version of their product, so they can start the learning process as soon as possible.
Example: Snapseed
Example: Snapseed, an app done right
Using those same approaches in mobile can be a disaster
There is no mouse in mobile, so tooltips don’t work at all. And it’s hard for mobile app developers to iterate their apps quickly because they have to get users to install the new versions. Apple even restricts how often a developer can update an iPhone app. What’s worse, even if a developer figures out how to iterate quickly, a bad experience in the first version of an app can be fatal because it’ll attract bad reviews on the app store, reviews that do not go away after the app has been updated.
So instead of shipping a sketchy app as early as possible, mobile developers need to take the time to give a great user experience from the very first release of their apps.
That means pre-release testing is important, but it also means developers need to think about design differently. Instead of assuming that users will be able to navigate an app on complete intuition, mobile app developers need to assume that users will get stuck, and give them a path to graceful recovery. This is especially important because the limited screen space of a mobile device makes it very hard to explain multiple features, and because the absence of tooltips means the features can’t explain themselves. It is almost impossible to create a completely intuitive mobile app, especially if it performs a function with any level of complexity to it.
When we test mobile apps on real users, time and again we see users struggle to figure out how to perform even straightforward functions with mobile apps. And when they get stuck, the first thing they usually do is search for a Help function. If help is available, and if it’s properly structured, users can usually answer their own questions and go back to using the app. But if they can’t find help, or if it doesn’t give the information they need, they’re likely to get frustrated, and may abandon the task altogether. The result is lost users and bad reviews in the app store.
Example: WebMD
Example: WebMD
What to do
Obviously, it’s important to make a mobile app as intuitive as possible. But rather than making perfection a design goal, developers should design with the assumption that users will sometimes get confused. That means the Help function should be:
  • Accessible on every screen. Ideally through a prominent button (question mark icon works well)
  • Context-sensitive. Should be relevant to whatever the user is doing at the time.
  • Searchable. Recognize that the user’s question will not always be related to the current screen in the app. Make it easy for the user to ask about a different topic. This can be achieved through something as simple as a searchable FAQ list.
More than 90% of the apps we test do not follow these guidelines, and based on informal surveys of the app stores, the percentage is even higher in the app base as a whole. But apps that do help right generally test better and are easier for people to use and learn.
Examples of help done right
  • Snapseed (a photo editing app) offers a help overlay for every screen. Tap the question mark icon and it shows how to control the app.
  • WebMD includes an on-screen tutorial that tells you how to use the app and what the buttons do. Note the tooltip-style illustrations.
Michael Mace is Mobile Strategist at UserTesting.com. A longtime veteran of Silicon Valley, he cofounded two software startups, worked as an executive at Apple and Palm, and consulted on strategy and product planning to many of the tech industry’s leading firms.