Most mobile applications are used only intermittently, so they must be especially easy during initial use. In particular, upfront registration shouldn’t be required before users experience an app’s benefits.
In preparation for our iPhone Apps Usability seminar, I’ve been sitting through numerous test sessions watching iPhone owners use hundreds of applications.
Based on these sessions, we’ve identified many specific usability guidelines that make it easier for people to use apps on the small touch screen. Clearly, current apps are far from user-experience nirvana.
In many ways, these test sessions reminded me of testing early Macintosh applications in 1986, when interaction designers hadn’t yet figured out how to use the mouse and a mid-sized GUI. Now they need to get better at supporting fingers and a tiny GUI. There are plenty of guidelines for the seminar — in fact, I’ve never failed to derive a rich day’s worth of material whenever we test a new generation of user interfaces. The “master guideline” remains the same as in 1986: don’t port a UI from an old interface paradigm to a new one. In the past, this meant not slapping a GUI on top of something that was inherently a clunky mainframe flow. Now, it means not adding touch-screen access to a desktop-oriented direct manipulation design — users can’t touch as precisely as they can click, so the number of manipulable graphical objects should be much smaller (so that each one can be much bigger).
Still, despite the weaknesses, my main conclusion from watching iPhone app users is that they suffered much less misery than users in our mobile website tests. In fact, testing people using iPhone apps produced happier outcomes than testing people attempting to use websites on the same phone.
On mobile devices, applications are easier to use than websites. (Given the current state of affairs; browser-based sites would be easier to use if designers started following more mobile usability guidelines.)
Why are apps better than sites for mobile? Because the more impoverished the device, the more the design must be optimized for the platform’s exact abilities, instead of bowing to a cross-platform common denominator.
Mobile Apps Are Intermittent-Use Apps
A very strong conclusion from our iPhone study is that people install many more apps than they actually use.
In the first part of each session, we asked users to walk us through their own iPhone apps. We frequently heard comments such as, “I downloaded this because [it sounded cool/a friend recommended it], but I haven’t had time to try it.” Users also often said something like, “I used this a few times right after I downloaded it, but I’m not using it anymore — I just haven’t gotten around to deleting it.”
The first conclusion from this finding is that pure download numbers are obviously irrelevant. To measure your app’s success, you must measure actual use. And, to assess whether you’re really meeting user needs, you must go even further and measure sustained use. If people use something a few times and then give up on it, you have a failed mobile design on your hands.
A few mobile apps do get frequent use, ranging from Facebook to the Weather Channel. But most businesses can’t realistically aspire to enter this category; mobile apps have different usability criteria than core desktop applications, as well as the mission-critical enterprise software that people use every day on the job.
Mobile mainly equals intermittent use. This does indicate a deeper level of user commitment than the ephemeral applications we often study on websites.
An example of a Web-based ephemeral app would be the customization and configuration utilities often found on car sites. For such apps, users have zero commitment and arrive at the first screen with no knowledge of the functionality beyond what they may have gleaned from passing through previous pages on that site. (And we all know how little users read during most website visits.)
Mobile apps score a little better than ephemeral website apps, because users actively decide to install them. This creates a minimum level of commitment to explore the app — though, as we found, this level is often very low indeed. Still, it’s higher than zero.
Second, the app icon is a continuous presence on the phone, which acts as a tiny voice gnawing at the user to try it out. Again, this isn’t a very strong force; humans are great at selective attention (as further discussed in our seminar on the human mind). Basically, people tune out anything they don’t really want to pay attention to, so users’ eyes pass by unused icons very quickly.
These are simply facts of the overall iPhone user experience: an app is easy to download from the App Store, and social pressure causes many “fun” apps to migrate quickly through large user pools. As a result, the “Springboard” (the app launching page) quickly becomes polluted with frivolous icons that people don’t really need and don’t use after leaving the bar or pub that evening.
If you’re designing a “serious” business app that you think offers real benefits to your customers, you might feel above the fray of rude-bodily-noise apps. But you’re not. Frequent readers of this column might recall Jakob’s Law of the Web User Experience: Users spend most of their time on other sites (than your site). Your website is part of the Web ecosystem, and your site’s usability is dictated by the overall Web user experience, which is dominated by the sum of all other sites people visit.
When you’re posting business information on social media sites, for example, that information has to live within your followers’ personal space, which is constructed by their family and real friends. Similarly, if you’re an iPhone app, your app is a small part of the total app user experience.
Fair or not, that’s life. Deal with it. Design for it.
Early Registration Must Die
The finding that iPhone apps are intermittent-use apps gives rise to many design guidelines. Here, we’ll discuss a key guideline from the initial user experience:
Avoid making users pass through a registration screen as the first step.
In our testing, we saw countless apps that asked users to register before having proven their worth in the slightest. This is wrong. Remember: users start out with a fairly low level of commitment to your app. Unless yours is a truly great app that offers immense value, people won’t use it enough to make registration worth their while.
Registration can certainly provide added business value and added usage convenience to your customers. But this is true
only if people actually complete the registration. Sadly, if you push registration at users before they’re sufficiently convinced of your app’s value, many will simply back right out of the app and never try it again. You’ve then lost the one chance you’ll ever get at making a first impression (actually, any impression).
Cautioning against early registration is hardly new. Since 1999, a key usability guideline for e-commerce shopping carts and checkout processes has been to allow users to buy without having to register. Sites that allow “guest checkout” have much higher conversion rates than sites that require users to make up a userid and password before they’re permitted the rare privilege of forking over their money. After all, we can’t allow just anybody to shop at our site — or at least that seems to be the thinking.
Registration will cost you business on desktop websites where it’s only somewhat of a pain. In the mobile environment, every extra hoop that users must jump through causes considerably more pain. Furthermore, users are less committed to an app they’ve just downloaded than they are to an e-commerce site where they’ve spent time browsing and adding items to a shopping cart.
When you combine
more pain
less commitment
it’s easy to see why upfront registration costs you even more lost business on mobile than on the desktop.
Example: Pizza Ordering Application
We saw many examples of too-early registration and too-burdensome screens in our iPhone testing.
Users are hit with this registration demand when all they want is to browse a selection of yummy pizzas. This was very off-putting to our test users.
The proper sequence?
Show the list of basic pizzas.
Let users customize their order.
Show the price, along with any salient ordering info (perhaps after having users enter their ZIP code to get delivery times and such).
Take the order. At this point, it’s appropriate to ask for personal info because users are now sufficiently committed.
To test the actual application, we forced users to proceed beyond this registration screen; in real use outside the lab, they would never have gone far enough to see a pizza.
Inside the app, there were some smaller interaction design problems, but the company could still double mobile pizza orders by getting rid of the upfront registration screen and asking users for their info after they’ve whetted their taste buds by showing them the pizzas.
Finally, none of the users clicked the button labeled “Not ready to order? Demo the app.”
When we tried this button (for the sake of the experiment), Pizza Hut served up the exact user experience recommended in steps 1–4 above. So, the designers know how to do it. Just not in the main UI flow 🙁
Why don’t users try the demo feature? Because they don’t want a demo. They want to see the pizzas on offer. Although “just looking” is a classic shopping strategy, no one tells a department store clerk that they’re not quite ready to buy a new sweater, but they would like one demo’d. No — they enter the store, look at the sweaters (all lined up for that exact purpose), and try on the ones that most appeal to them. Only from the store’s perspective would this scenario be considered “a demo.” For the customer’s perspective, it’s simply “shopping,” and you don’t have to apply in triplicate for a permit to do so.
Although I’ve said it a million times, I apparently have to say it again to penetrate some thick skulls at Pizza Hut: Speak the user’s language in the UI.
iPhone apps are obviously a class of user interfaces, so it should come as no surprise that general UI guidelines apply, in addition to the special mobile guidelines. The difference between iPhone apps and desktop apps is that, with the former, these UI guidelines are much more critical because mobile typically implies intermittent use. Thus, the initial hurdles must be very low and easy to jump or users will never get accustomed to using your app.
Learn More
Full-day seminars on:
Application Design 1 (Page-Level Building Blocks for Feature Design) and Application Usability 2 (Dialogue and Workflow Design)
Complex Application Design (3-day seminar)
Presented at the annual Usability Week conference. (Different topics are presented in each city, so check your preferred city’s agenda for an exact list of seminars.)
