Mobile Usability 2nd Edition

Usability of Mobile Websites and
Applications
Design Guidelines for Improving the User Experience of Mobile Sites and Apps
by Raluca Budiu and Jakob Nielsen
2nd edition
WWW.NNGROUP.COM 48105 WARM SPRINGS BLVD., FREMONT CA 94539–7498 USA
COPYRIGHT © NIELSEN NORMAN GROUP, ALL RIGHTS RESERVED.

To buy a copy, download from: http://www.nngroup.com/reports/mobile
This page is blank for double-sided printing.
2 INFO@NNGROUP.COM Executive Summary

Contents
Executive Summary ...................................................................... 7
User Research ......................................................................................... 7
Mobile User Experience Improving Slowly .................................................... 8
Apps Beat Sites........................................................................................ 9
Most Usability Guidelines Confirmed ........................................................... 9
Mobile Design = Small and Targeted ........................................................... 9
What’s New in the Second Edition ............................................... 11
Research Overview ..................................................................... 12
What People Do On Mobile Phones .............................................. 14
Mobile Information Needs ........................................................................ 14
Mobile Activities ..................................................................................... 16
Success Rates on Mobile Devices ................................................ 18
Success Rates: Full Sites versus Mobile Sites Versus Apps ........................... 18
Success Rates: Does the Phone Matter? .................................................... 19
Success rates: Historical Comparison ........................................................ 21
Mobile Strategy Guidelines.......................................................... 23
Should You Go Mobile?............................................................................ 23
Application Versus Mobile Website ............................................................ 27
What to Include On Mobile ...................................................................... 31
Who Your Users Are .......................................................................................... 31
What Your Top Tasks Are: What You Should Support on Mobile .............................. 32
Content that Should Be Included on Mobile .......................................................... 34
Mobile Sites ........................................................................................... 34
Do Users Prefer Full Sites or Mobile Websites? ..................................................... 34
Mobile Site, But Which Device? .......................................................................... 35
© NIELSEN NORMAN GROUP WWW.NNGROUP.COM 3

Accessing a Mobile Site ..................................................................................... 37
Designing a Mobile Site ..................................................................................... 43
Mobile Apps ........................................................................................... 43
Differences Between Mobile Platforms for Apps .................................................... 43
Making Your App Findable.................................................................................. 44
What to Include in a Mobile App ......................................................................... 47
From Desktop to Phone ..................................................................................... 49
Principles of Mobile Usability ...................................................... 52
General Guidelines for Mobile Websites and Apps ....................... 54
Homepage ............................................................................................. 54
Typing .................................................................................................. 57
Dropdown Boxes, Menus, Carousels.......................................................... 69
Forms ................................................................................................... 78
Logging in and Registering ...................................................................... 86
Search .................................................................................................. 98
Lists and Scrolling ................................................................................ 104
Navigation ........................................................................................... 119
Content............................................................................................... 131
Readability .......................................................................................... 149
Images, Animation, and Videos .............................................................. 151
Icons .................................................................................................. 166
Errors ................................................................................................. 169
Maps and Location Information .............................................................. 174
Shopping ............................................................................................ 183
Banking and Transactions...................................................................... 188
Feature Phones ......................................................................... 191
General Guidelines for Touch Phones ........................................ 195

Targets: Size, Placement, Affordance ...................................................... 195
Gestures ............................................................................................. 206
Horizontal Swipe ............................................................................................ 210
Tapping and Content....................................................................................... 213
Orientation .......................................................................................... 215
Input .................................................................................................. 218
Guidelines for Apps ................................................................... 222
Immersive Apps ................................................................................... 222
Input .................................................................................................. 226
Modal Dialogs and Alerts ....................................................................... 233
Registration and Log In ......................................................................... 234
Notifications ........................................................................................ 238
Tab Bars and Tool Bars ......................................................................... 240
Task Flow ............................................................................................ 244
Progress Indicators ............................................................................... 246
Instructions and Help............................................................................ 247
Initial Experience ................................................................................. 251
Hybrid Apps ......................................................................................... 256
Physical Buttons on Platforms Other than iOS ......................................... 259
Methodology ............................................................................. 266
Diary Studies ....................................................................................... 266
Overview ....................................................................................................... 266
Participants ................................................................................................... 266
Method 267
Usability Testing .................................................................................. 268
Overview ....................................................................................................... 268
Participants and Devices.................................................................................. 269

Method 270
Materials ....................................................................................................... 270
Design Reviews .................................................................................... 275
List of Guidelines ...................................................................... 277
Acknowledgments ..................................................................... 292
About the Authors ..................................................................... 293

Executive Summary
There’s no need to declare this “the year of mobile.” If anything, 2010 was the year of
mobile in terms of the growth in both mobile usage and the availability of mobile sites and
apps. Now, however, it’s time to redesign your mobile site, because your existing version is
probably far below users’ growing expectations for user experience quality.
The mainstream Web’s history repeats itself here. In the beginning, the Web was
experimental — accordingly, it was acceptable to have a somewhat shaky, experimental
website. Many sites were crippled by misguided design advice, which was common in the
early years, and most companies didn’t know any better (because they didn’t do usability
studies). Now, people simply expect websites to work.
Same with mobile. Earlier, it might have been cool simply to have an app. Now, that app
better be good. Requirements have gone up. Luckily, our new research shows that mobile
sites and apps have been improving their usability, even though it’s still far below that of
regular websites accessed from a desktop computer.
USER RESEARCH
We conducted eight rounds of user testing: five in the United States, and one round each in
Australia, Hong Kong, and the U.K.
The first two rounds of testing were conducted in 2009, and formed the basis for the 1st
edition of this report. In that initial research, we tested all three categories of mobile
phones:
• Feature phones: primitive handsets with tiny screens and very limited keypads that
are suited mainly for dialing phone numbers.
• Smartphones: phones with midsized screens and full A–Z keypads.
• Touch phones: devices with touch-sensitive screens that cover almost the entire
front of the phone.
For our six new studies, we dropped the feature phones for three reasons:
• Our first research found that feature phone usability is so miserable when accessing
the Web that we recommend that most companies don’t bother supporting feature
phones.
• Empirically, websites see very little traffic from feature phones, partly because
people rarely go on the Web when their experience is so bad, and partly because the
higher classes of phones have seen a dramatic uplift in market share since our
earlier research.
• Pragmatically, almost all participants in our mobile user experience courses tell us
that they don’t design for feature phones. Thus, we don’t need to collect updated
video clips or other seminar materials about feature phones.
In the first two test rounds, touch phones were mainly iPhones, with a smattering of
competing, though primitive, devices. In the recent testing, we still had many iPhone users
but also many Android users as well as some Windows Phone users.
All together, we tested 105 users—53 males and 52 females. Of those test participants,
12% were 50 years or older, while the remaining 88% were evenly distributed across the
ages of 20–49 years. Occupations ran the gamut, from fashion consultant to patent lawyer
to television producer.
Tasks ranged from directed to exploratory:

• Highly specific tasks. For example, "You are in an electronics store and consider
buying a Canon PowerShot SD1100IS as a present. The camera costs $220.25 in the
store. Check adorama.com to see if you can get a better price online."
• Directed, but less specific. For example, "Find a moisturizer with SPF 30 or above
that is suitable for your skin." (While using the Walgreens app.)
• Open-ended, but restricted to a predetermined site or app. For example, "See if you
can find any interesting pictures related to today’s news." (While using the China
Daily app.)
• Web-wide tasks that let users go anywhere they wanted. For example, "Find out
which is the tallest building in the world." (While giving users no indication of which
site might have the answer.)
In all, we observed participants doing 390 different tasks: 194 application-specific tasks,
154 website-specific tasks, and 42 Web-wide tasks.
In addition to user testing, we also conducted two rounds of diary studies to discover how
people use mobile devices in their everyday life. One diary study was in the U.S.; the other
included participants from Australia, The Netherlands, Romania, Singapore, the U.K., and
the U.S. In total, 27 people participated in the diary studies, providing us data about 172
person-days of mobile activities. Again, participants had a wide range of jobs, from
bookkeeper to football coach.
MOBILE USER EXPERIENCE IMPROVING SLOWLY

In the 1st edition of our report, mobile users’ average success rate was 59%.
In the new research, the average success rate was 62%. Better, but only 3 percentage
points better in 2 years. Although this improvement rate might seem disappointingly slow,
it’s about the same as the pace we recorded for desktop Web use in 263 studies over the
last 12 years.
The current success rate for mobile Web use is about what we measured for desktop Web
use in 1999. The current desktop success rate is 84%; unless mobile usability starts
improving more rapidly, we’ll have to wait until 2026 to reach that level.
The 62% success rate was computed across all tasks that we could reasonably categorize as
having been done correctly or incorrectly.
Measured usability varied substantially, depending on whether people used a mobile site or
a full website. (By way of definition, a “mobile” site is one designed specifically for use on
mobile devices, whereas a “full” site is a regular website designed mainly for use on a full-
screen desktop computer.)
• Mobile site success rate: 64%
• Full site success rate: 58%
This leads to the first, and maybe most important, guideline for improving the mobile user
experience: design a separate mobile site. Don’t expect users to access the same site from
both desktop and mobile browsers. (The exception would be people using large-sized tablets
like the iPad. Our separate studies of iPad users show that they do fairly well browsing full
sites.)
A second key guideline is to have clear, explicit links from the full site to the mobile site and
from the mobile site to the full site. Unfortunately, search engines often fail their mobile
users and erroneously point them to the full sites, even for companies that offer mobile
sites with much better user experience. As long as users don’t need to navigate, they might
actually be okay when they’re dumped into a site that works poorly on their phone. Search
engines frequently offer deep links to pages directly related to the user’s query. But if users
want to know more than what that one page offers, they’ll suffer if they’re stuck on the full

site. That’s when the link to the mobile site will come in handy. (And why the search
engines should have pointed to the mobile site in the first place.)
APPS BEAT SITES

While a mobile site is good, a mobile app is even better. We measured a success rate of
76% when people used mobile apps, which is much higher than the 64% recorded for
mobile-specific websites.
Of course, it’s more expensive to build an app than a mobile site, because you have to code
different versions for each platform. Thus, we can really recommend building mobile
applications only if you’re either rich or offer a service that’s particularly suited to mobile
use.
MOST USABILITY GUIDELINES CONFIRMED

The 1st edition of our mobile usability report contained 85 design guidelines. Of these, 83
were confirmed by the recent research, one was somewhat revised, and one was deleted.
As we have said many times before, 1 usability guidelines remain very stable over the years
because they mainly depend on human behavior. (The one guideline that was revised
related to the use of Flash, and was thus more technology-dependent than most usability
guidelines.)
The main news? From the 1st to the 2nd edition of our mobile usability report, the number of
design guidelines increased from 85 to 210. This is partly because we now know much more
about mobile usability and partly because requirements have increased. Sites and apps
have definitely gotten better, raising the bar for acceptable user experience, and thus
increasing the number of guidelines that designers should follow.
In particular, Android apps have gotten much better, probably because the platform’s
growing market share has caused companies to invest more in the quality of their Android
apps.
Also, users have become more aware of horizontal swiping than they were in our previous
research. The horizontal swipe gesture is often used to “flip” through deck-of-cards or
carousel features. Swiping is still less discoverable than most other ways of manipulating
mobile content, so we recommend including a visible cue when people can swipe, or they
might never do so and thus miss most of your offerings. Also, you should avoid swipe
ambiguity: don’t employ the same swipe gesture to mean different things on different areas
of the same screen. This recommendation is the same for mobile phones and tablet
usability, showing the similarity between these two gesture-based platforms.
It’s interesting to consider the difference between mouse-driven desktop design and
gesture-driven touchscreen design here. Desktop websites have a strong guideline to avoid
horizontal scrolling. But for touch-screens, horizontal swipes are often fine. Indeed, mobile-
device users typically expect to horizontally swipe their way through a carousel. Of course,
this is just one more example of the meta-guideline that sufficiently different platforms
require different user interface designs. This, again, is the underlying reason that mobile
sites perform better than full sites when used on a mobile device.
MOBILE DESIGN = SMALL AND TARGETED

To have a successful mobile site or app, the obvious guideline is to design for the small
screen. Sadly, some don’t, and we still see users struggle to hit tiny areas that are much
smaller than their fingers. The fat-finger syndrome will be with us for years to come.
1
Please see “Change vs. Stability in Web Usability Guidelines” at
http://www.useit.com/alertbox/guidelines-change.html

The second point is more conceptual—and harder for some people to accept: When you
have a smaller screen, you must limit the number of features to those that matter the most
for the mobile use case.

What’s New in the Second Edition
Our initial 2009 mobile-usability report was based on usability studies of mobile websites, as
they worked on a variety of devices: feature phones, smartphones, and touch phones. (For
our purposes, feature phones are defined as phones with Internet access, but which have a
reduced keypad [mainly the number keys]; smartphones are phones with Internet access
and full A–Z keypad, and touch phones are touchscreen phones.) Since then, we found that
the vast majority of users of the mobile Web are smartphone and touch-phone owners.
Moreover, this segment is continuously increasing and analysts estimate that it will soon
outpace that of feature-phone owners. At the time of the writing of this report, 35% of US
mobile subscribers owned a smartphone or a touch phone 2. In 2009, that number was only
19% percent. Thus, in the second edition we focus on smartphones and touch phones. We
still have a short section devoted to feature phones, but most of the examples in the report
come from smartphones and touch phones.
There are two big additions to the second edition: a section covering guidelines specific to
touch devices, and a section for application guidelines. Most of the applications that we
studied were on touch devices (specifically, on iOS and Android devices); therefore, some of
our guidelines are specific to these types of phones.
Many of the guidelines in this report do apply to touch-based tablets. However, there are
two big differences between tablets and mobile phones: (1) the tablet screen is bigger; (2)
tablets are used in different ways than mobile phones. (Whereas many of the tasks carried
out on mobile phones need to be quick, tablet users are not usually “in a rush”, to quote
one of our users.) Because of that, we do not address tablets in this report. Readers
interested in that topic are referred to the two NN/g reports on the usability of iPad websites
and applications. 3
2
Aaron Smith. 35% of American adults own a smartphone. Pew Internet & American Life
Project. July 2011.
3
See http://www.nngroup.com/mobile/ipad.

Research Overview
The main purpose of our research was to understand how people access the Web on their
mobile phones and what challenges they face when they use websites and applications on
their phones. The result of this research effort is a set of design guidelines for websites and
applications that are usable on mobile devices. We based these guidelines on methodical
observations, interviews, user diaries, as well as expert reviews.
In this section we present a brief overview of our research project. For details about the
methodology, please refer to the Methodology section in this report, starting on page 266.
The research project encompassed three different methods:
• diary studies,
• usability testing,
• expert reviews.
Diary studies. To understand what activities are normally done on mobile phones, we
carried out two diary studies: one international and one in the US. The international diary
study involved people from six different countries in Europe, Asia, Australia, and America,
who owned different types of phones (feature phones and smartphones, including
touchscreen phones). For the second diary study, we focused on iPhone owners in the US.
Participants used their mobile phones at least several times a week. They logged all the
activities that they carried out on their mobile devices for approximately one week. The
diary gave us information about the range of mobile activities done by advanced users and
informed our traditional usability testing.
Usability testing. We carried out eight separate usability-testing studies over three years.
The majority of the studies were done in the US; we also ran testing sessions in the UK,
Hong Kong, and Australia. In all these studies, participants brought their own mobile phones
into our lab. Our first two studies involved all types of phones, ranging from touchscreen
phones, smartphones, and feature phones. The remaining studies focused on smartphones
and touch phones only. Where applicable, we asked participants to show us the apps that
they had installed on their phones, and then we gave them tasks to complete using either
mobile apps or the Web.
The tasks could be grouped in two different categories:
• Specific tasks, in which users were asked to go to a given website or use a specific
app to find specific information. These tasks specified the app name or the website
URL. The URL could have been a mobile website (designed specifically for mobile
devices — e.g., “Use mobile.fandango.com to find out what movies are shown at
your local movie theater”) or just a domain name (e.g., “Use fandango.com to find
out what movies are shown at your local movie theater”).
• Open-ended information-gathering tasks, in which users were free to use any
website or application in order to find specific information (e.g., “Find how many
calories a slice of cheese pizza typically has.”).
Please refer to the Methodology section for examples of tasks.

We observed users as they worked and encouraged them to think aloud. As part of the
sessions, we also interviewed participants about their common mobile practices and asked
them to demonstrate some of their favorite sites and applications.
Sessions lasted between 60 and 90 minutes. Overall, we had 105 participants, out of which
84 were from the US. We studied 64 touch phones (35 iPhones, 19 Android phones, 3
Windows phones, and 7 other), 27 smartphones, and 14 feature phones.
12 INFO@NNGROUP.COM Research Overview

Our first studies gave us a clear indication that one of the biggest hurdles encountered on
the mobile Web is reaching a company’s mobile site. Because the major goal of this
research effort was to produce guidelines for mobile-platform design (applications and
websites), we were less interested in how people navigate full sites on mobile. Therefore,
our later studies looked mostly at how participants use mobile apps and mobile sites. Most
of the time, when users were not able to find a mobile site on their own, we directed them
to the mobile site.
Expert Reviews. The last source of information for our guidelines came from expert
reviews. Over the course of three years we reviewed many apps and mobile websites on a
variety of platforms. The list of these has become too long to include in this report, but the
Methodology section contains a subset of sites and apps that were reviewed.

What People Do On Mobile Phones
A recent survey by Pew Internet Research found that 42% of American cell phone owners
used their phone to kill time, and 51% used their phone to find information they needed
right away. Moreover, about 40% of the cell owners used the phone in an emergency
situation 4.
The activities that people do on mobile fall into two big categories: killing time and
searching for a specific piece of information. In an attempt to make the time pass faster
when they’re waiting at the doctor’s office or in a bus stop, or to seem busy while having
lunch by themselves 5, users browse around (using games, news, email, or social networking
apps) and consume the content that is readily offered by apps and websites.
The other type of activity – searching for specific information – is typically very focused: we
don’t see people planning their career or researching hotels for their next vacation on the
phone. The single window and small screen are strong limitations for any complex
information-gathering tasks that require putting together multiple sources of information.
Instead, when they are on mobile, users might need to answer questions such as where the
closest gas station is, where to find a good place for lunch, what kind of reviews the product
in front of them might have, or even if they have enough money in their checking account
to go to the store and make a purchase. Many of these questions have a strong local
component: users are interested in answers around them.
MOBILE INFORMATION NEEDS

In the first edition of this report, we discussed a study published in CHI 2008 6 that
investigated what kinds of needs people have when they are away from home or work.
Unlike in our diary studies, where we asked people to log every activity they actually did on
their mobile devices, in the CHI study users added an entry to their each time they had a
question, whether they were able to answer that question using their mobile device or not.
(Note that the majority of the users in that study did not have mobile Internet access.) By
design, this study focused on the second type of activity that we normally see on mobile —
searching for specific information — and ignored the kill-time aspect.
It is interesting to compare what people need to do when they are on the go with what they
actually get to do.
The figure below shows what kinds of questions people had when they were away from
home or work. Even though the study may be considered “old” by now, these are fairly
universal information needs that won’t change much over time. In fact, it can be considered
an advantage of the 2008 study that it was based on identifying intrinsic information needs
as opposed to measuring what people did with the devices they had at the time.
4
Aaron Smith. Americans and their cell phones. Pew Internet . August 2011.
5
13% of American cell phone owners pretended to be using their phones in order to avoid
interaction with other people (Aaron Smith. Americans and their cell phones. Pew Internet .
August 2011).
6
Sohn, T., Li, K. A., Griswold, W. G., Hollan, J. D. A diary study of mobile information
needs. CHI ‘08 Conference Proceedings.
14 INFO@NNGROUP.COM What People Do On Mobile Phones

Mobile Information Needs (Sohn et al., 2008)
Trivia
18.5%
Directions 13.3%
Point of interest 12.4%
Friend info 7.6%
Shopping 7.1%
Business hours 6.9%
Personal item 6.4%
Schedule 5.7%
Phone # 5.7%
Traffic 4.5%
Sports/news/stocks 3.8%
Email 2.6%
Movie times 2.4%
Weather 1.4%
Travel 1.0%
Recipes 0.7%
The most frequent information needs were trivia: questions such as “Where did Bob Marley
die and why?” Such questions occur often in conversation or are prompted by some
contextual element. After trivia, the next most frequent questions concern relatively simple
facts such as directions, business hours, schedule, and contact information.
Sohn et al. also looked at how often the information needs were addressed. Their data
showed that only 45% of the information needs were addressed at the time, by a variety of
means that included the Internet (18%), but also calling someone, making a phone call,
printing beforehand the information that was needed, or going to a specific location.
Therefore, in that study, most of users’ information needs remained unaddressed or were
addressed using means other than the Internet.
Sohn et al. was replicated later by Heimonen (2009) 7. The gallery of information needs
mirrored that from the earlier study (confirming the durability of the research into intrinsic
information needs); however, in Heimonen’s study, 98% of the needs were addressed at
the time of the need. Moreover, 94% of the needs were addressed using the mobile
Internet. That is a huge difference (an increase by a factor of 5 compared to Sohn et al.’s
7
Heimonen, T. Information needs and practices of active mobile Internet users. Mobility
2009.

users), and is a testimony to the tremendous growth of the mobile Web in a short span of
time. It is also a testimony to users’ trust in their ability to find an answer using the mobile
Web.
MOBILE ACTIVITIES
The following graph shows a histogram of the mobile activities in our two diary studies,
combined:
Histogram of Mobile Activities
communication 171
entertainment 51
news 51
travel/transportation 44
weather 37
picture-related 33
shopping 31
utility 23
banking/financial 22
personal data 20
local info 20
information (public data) 15
device maintenance 12
personal care/health 12
work 6
In this chart, the numbers indicate how many times each mobile activity was performed
across the 172 person-days for which we collected the diary. Shopping includes purchasing,
but also activities like price comparison and checking order status.
By far, the most frequent activity for our users was communication (including email, social
networking, and forums) — consistent with other third-party large scale surveys 8. Out of
that category, email had the biggest chunk: checking email is still the preferred way to kill
time on the go.
Looking back at the results of our first diary study, in the second diary study, which was
carried out a year after the first, we saw an increase in activities related to banking and
shopping, and the use of utility applications. Part of the difference can be assigned to the
mixture of phones that we tracked in the first study (feature phones, smartphones, and
8
Comscore 2010 Mobile Year in Review.
16 INFO@NNGROUP.COM What People Do On Mobile Phones

touch phones) compared to the second (iPhones only): there was a wider assortment of
apps available to the iPhone users, so, overall, activities such as shopping and banking were
more accessible in the second study. But the other part of the difference is probably due to
time: a year later, users are more likely to engage in shopping-related activities and
transactions on mobile. Again, this is consistent with research briefs coming from companies
with larger samples than ours 9, which indicate an increasing trend in mobile e-commerce
and banking.
9
Comscore 2010 Mobile Year in Review.

Success Rates on Mobile Devices
SUCCESS RATES: FULL SITES VERSUS MOBILE SITES VERSUS APPS
For our usability testing studies, for each participant and for each task we rated whether the
participant performed the task successfully. We measured success rates based both on
whether the participants were able to find the information they were asked for in the task
and on their feedback about whether that information satisfied their needs.
When we computed success rates, we eliminated cases where the users failed due to poor
cellular signal.
The graph below shows the average success rates across our 8 studies. Overall, the success
rate on the mobile Web was 62% — a 3% increase over the initial 59% reported in our first
edition of the report and obtained by looking at our first 2 studies only. When we split the
tasks into full and mobile (depending on whether participants had used a mobile or full
website), we obtained a 64% overall success rate for mobile sites and 58% success rate for
full sites, indicating, not surprisingly, that mobile sites tended to be easier to use than full
sites. The difference is small (and certainly smaller than the 10% difference that we
reported in our first edition). Does it mean that full sites have gotten better and that we
shouldn’t bother creating mobile sites? No. We think that the difference is due to our focus
on mobile sites versus full sites. Most of the tasks in our last 6 studies involved mobile sites
or apps; the open-ended tasks that did not specify any site or app were the only ones
where users dealt with full sites. And often search engines helped users get a quick answer
(by taking them to an internal page instead of letting them deal with the full site’s
navigation).
The graph also shows the success rate for apps (76%) — a 14% increase over the mobile
Web. This difference in success rate is reflected in users’ preference for apps versus the
Web, and it is rooted in the simpler, more streamlined functionality of the apps, as well as
in the better, more phone-specific design.
Success Rates
76.40%
63.61% 62.36%
57.87%
Mobile apps Mobile Web Full Web All sites on

mobile
18 INFO@NNGROUP.COM Success Rates on Mobile Devices

SUCCESS RATES: DOES THE PHONE MATTER?
With the introduction of the iPhone back in 2007, we have seen an explosion of interest in
the mobile Web — applications have been built and many companies have created mobile
Web sites. The question is: Is it worth it? To what extent do more sophisticated phones such
as iPhone and Android phones have an advantage on the mobile Web?
To answer that question, we looked at how success rates vary with the type of phone. The
graph below shows the success rates for feature phones, smartphones, and touch phones.
For reference, we also included the typical desktop success rates that we get in our desktop
studies.
Success Rates on the Mobile Web

(by Phone Type)
84.00%
74.29%
55.19%
43.75%
Desktop Touch Smartphones (no Feature

touch)
Overall, on the mobile Web the phone does matter. Touch-phone users have higher success
rates (74%) than smartphone users (55%), which in turn are more successful than feature-
phone users (44%). This is not a surprising finding: during our usability sessions we
observed many feature phone users struggling with basic things such as typing or scrolling.
Moreover, many of the full sites are “optimized” on feature phones so that they could be
displayed on the phone browser. Unfortunately this optimization linearizes the page in a
highly unpredictable manner and often makes it hard to find even page elements that were
fairly salient on the original full site. On the other hand, smartphones or touch phones are
often able to render the full page. The problems that these users confront are mostly due to
the small screen (and lack of access to detail) and to downloading speed — full sites often
contain images and animation that take a long time to appear on the phone screen. More
often, features such as Flash does not work well on many phones, and smartphone or
touch-phone users often encounter difficulties when accessing such pages on their devices.

Adorama.com site is “optimized” for a feature phone.
The following graphs show how the success rates for different types of phone vary for
mobile sites, full sites, and mobile apps.
Success Rates by Phone Type
Mobile apps Mobile Web Full Web
77% 75% 73%
57% 57%
53%
48%
37%
Touch Smartphones (no touch) Feature
For all types of phone, full sites tend to do worse than mobile sites in terms of success rates
(77% versus 73% for touch phones, 57% versus 53% for smartphones, 48% versus 37%
for feature phones). Whereas the difference is biggest for feature phones, it still maintains
on other platforms. (We discussed before the reasons for the smaller differences in success
rates for the other kinds of phones.)

Because success rates are relatively small overall for feature phone, and because of the
overall trend of consumers turning to smartphones and touch phones, in this report we
focus mostly on these two more advanced types of phones.
SUCCESS RATES: HISTORICAL COMPARISON

In 2000 Nielsen Norman Group tested the usability of the mobile Web in a user study done
in London and concluded that WAP usability failed miserably: users were struggling with
basic tasks such as checking news or the local weather forecast 10.
To see how the usability of the mobile Web has changed since then, in our 2009 London
testing we included two tasks that were also done in 2000. The two tasks were:
• Find the local weather for tonight.
• Find what’s on BBC TV 1 tonight at 8pm.
We looked at success rates and task times for these two tasks specifically. The results in
2000 and now are presented in the table below. Only the times when the participants were
able to complete the task successfully were considered for computing statistics.
Weather BBC TV 1
SUCCESS RATE 90% 100%
2000 MIN 54 82
TASK TIME
(20 users) MAX 299 242
(SECONDS)
MEAN 164.3 158.6
SUCCESS RATE 100% 85.71%
MIN 18 65
CURRENT
MAX 482 360
TASK TIME
(14 users)
(SECONDS) MEAN 247 199.1
MEDIAN 264.5 182.5
Interestingly, on average, users performed more poorly in 2009 than in 2000. In 2009 users
were not using their carrier portals to accomplish their tasks; most of them used a search
engine such as Google to find the information that they needed or they navigated to a site
that they knew about (e.g., Met Office). This portal-independence apparently comes at the
price of speed: most often people had to type in order to enter query data; when they used
a search engine (and they used it even for typing in the URL of the site they wanted to get
to), they waited for the list of results and then selected another site and waited again for
the site to download. From 2000 to 2009, users moved from a portal-dependent browse
mode (where they browsed through the links available in the portal to find out what they
needed) to a search mode where they used a search engine to find the information they
needed. Whereas the browse mode offered some relative speed advantage, the search
10
The report from our WAP study can be downloaded from
http://www.nngroup.com/reports/wap/.

mode offers infinitely more flexibility, with people being able to use search to find an
arbitrary piece of information.
Let’s see how the times to perform these tasks varied according to the type of phone that
people had. The graph below shows the distribution of times for the two tasks, grouped by
phone type. The two red-bordered data points for the BBC TV 1 task correspond to tasks
that users did not complete successfully. One of the iPhone users used an application that
he had installed on his phone and thus was able to find the answer to the weather task in
18 seconds.
Task Time (seconds)
Other Smartphone Touch

Failures
800.00
698 697
700.00
600.00
482 481
500.00
386 360
400.00 335 345
300
280 266 263 259
300.00 239
202
231
176 163 151 142 156
200.00 120 134 121
86 86 65
100.00 18
0.00
Weather BBC TV 1
The graph shows that, whereas users of touch phones and smartphones tend to be faster,
there is a lot of variation among individual users (and phones and cellular network speeds)
even for these higher-end phones.
Our 2000 WAP report concluded that “WAP doesn’t work” based on users taking longer than
2 minutes for basic tasks such as finding the weather and the TV listings. In our current
studies we found that users take even longer to complete the same tasks. So does that
mean that mobile Internet doesn’t work and is not ready for prime time? While it is true
that websites are far from being usable on mobile devices, the differences in success rates
between touch phones such as the iPhone and the other types of phone indicate that we
finally have the tools needed for the mobile Internet to flourish.

Mobile Strategy Guidelines
SHOULD YOU GO MOBILE?

The first decision that businesses need to make even before building a mobile platform is
whether it makes sense to have one, or they should limit themselves to a full (desktop) site
and hope that it can be used from phones as well as PCs. We’ve seen that mobile sites and
applications have higher success rates than full sites, with applications having the highest
success rates. That finding generally holds true for all types of phones — touch phones,
smartphones, and feature phones (see the section Success Rates: Full Sites versus Mobile
Sites Versus APPS).
However, if you have budgetary constraints and think about optimizing your ROI, it may be
worth asking the question whether people are likely to use your site on a mobile device.
Your site analytics may be able to offer some insights into that issue. How many users
access your full site on a mobile device? 11 If you do get a substantial percentage, what
kinds of devices do they have? Do you have repeat users that access your site again and
again on their mobile devices? Is there a set of tasks that is often done from a mobile
device?
The answers to all these questions, as well as a basic understanding of the kinds of
activities that are typically done on mobile (see section What People Do On Mobile Phones),
can shape your mobile strategy and may help you get the best return over investment.
After all, you don’t want to spend a lot of money implementing a complex mobile website or
app and have no users for most of the features of that platform.
When should you go mobile? Here are some general guidelines based on our experience
with how people use mobile devices.
1. If your budget allows for a mobile platform (website or app), build one:
your users will do better with it.
2. Use site analytics to determine how many full-site accesses come from
mobile devices and to decide whether it’s worth building a mobile platform.
As a general guideline, if over 7-10% of your full site access comes from a mobile
device, you should build a mobile platform.
11
Of course, if you were to launch a mobile site, your mobile usage stats would probably
increase, because users would be getting a better experience — which again would make
them more likely to come back. However, the current analytics from your full site still form
a good initial baseline for then extent to which users desire to access your content and
services from mobile devices.

3. Build a mobile platform if people use your site to communicate with each
other.
4. Build a mobile platform if people come to your site to kill time and browse.
5. If your site has content that changes often (e.g., once a day, or several
times a day), create a mobile platform.
6. Build a mobile platform if people do small, quick transactions on your site

under time pressure.
These types of sites include those where people can check their account balances,
make an impulse donation, buy books, small gifts, or products with limited
availability, check auction information.
7. Build a mobile site if you provide content that is likely to be needed when
people are away from home.
Examples in this category include TV schedules, but also product prices, addresses,
emergency information.
Overall, we find that there are few sites that do not benefit from having at least a basic
mobile site. Later on, when we discuss the kinds of features that should be translated into
the mobile space, we’ll see that mobile websites or apps do not need to support all the tasks
that a typical website does. But, at the very least, a mobile website with contact
information, hours of operation, and directions to physical locations can benefit most
companies.
What sites do not need a mobile version? Back in 2009, the only site that had a 100%
success rate was a full site — the site of the restaurant Chez Panisse. Users were able to
find the information they needed on this site easily, because the site had a simple design
that was rendered reasonably well on all types of mobile phones. Moreover, the navigation
structure was salient (the home page was just a set of navigation options, which is often the
case for successful mobile Web pages) and shallow (there were not many layers in the
navigation hierarchy).
24 INFO@NNGROUP.COM Mobile Strategy Guidelines

(a)Chez Pannisse: full site on a PC (older version)
(b)Chez Panisse: full site on a Blackberry (older version)

(c) Chez Pannise: full site on iPhone (older (d) Chez Panisse: full site on a feature-
version) phone (older version)
An older version of Chez Panisse’s full website rendered on (a) desktop (b) Blackberry; (c)
iPhone; (d) feature phone. The full site worked on a mobile device because it had a simple,
shallow navigation structure that was accessible on the homepage. The site did not use
Flash or JavaScript.
(a) Chez Panisse’s intro: full site (b) Chez Panisse’s main site (after intro): full site
on a PC (newer version) on a PC (newer version)

A newer version of Chez Panisse started with a Flash introduction (a) and then took
users to their main page. The introduction was less usable on a mobile phone.
Since then, however, Chez Panisse has changed their website to a “fancier” version.
Although the newer version still had a limited content, the Flash introduction made it harder
to use on mobile 12.
Simple, limited-content sites that do not use Flash and wisely take into account the screen
size in a style sheet may work reasonably well on a phone, even though they were not
necessarily optimized for mobile access. Other sites, however, will most likely benefit from a
dedicated mobile website or app.
APPLICATION VERSUS MOBILE WEBSITE

Once you have decided to create a mobile platform, the next question that often arises is:
should you build an application (or maybe even multiple apps) or should you create a
mobile website?
There are pros and cons for each option.
• Applications may allow users one-touch access to your service.
Usually one click is enough to start an app (compare that with entering a website
address in the browser). This is mostly true for frequently-used apps or apps
positioned on the first phone screen.
This is what a user in our diary study had to say about a YouTube application:
“I like that it’s right on my screen, [you can] hit a button and search what
you’re looking for. I don’t have to go to [my] Safari [browser] to find it.”
However, accessing a rarely-used app can be as difficult as finding a website.

One reason is that people tend to have a lot of apps on their phone. When asked to
use an app that they had installed on their phone, many of our study participants did
not remember that they had it or confessed that they had never used the app
before. Even if people may have used the app before, they often have trouble
finding it in an app list that spans several screens.
When apps can be grouped in folders (as in the iOS), the extra level of organization
can paradoxically make the finding process more tedious. Was this app under
“Utilities” or was it under “Lifestyle”? Often people end up resorting to search in
order to find an app on their phone. And search is also the main method of access
for websites.
• Applications provide closer integration with other phone features. For

instance, they can take advantage of GPS, compass, accelerometer, camera, or of
apps such as maps, phone, and contacts. Some of these features (e.g., GPS,
orientation info) have become available to websites as well, but it’s still unlikely that
mobile websites achieve the same level of integration with the device as mobile
apps.
The example below shows the steps needed to find directions to a restaurant using
the mobile version of Yelp.com. When the user first enters the search string (in this
case “Mexican”), he has to type in a value in the Near field. Once the user gets a list
of results, she can select one particular restaurant, and then she can inspect a map.
The map has a different interface than the regular map application that comes with
12
To Chez Panisse’s credit, they automatically skip the Flash introduction on the iPhone,
probably detecting that it does not have a Flash player.

the phone. Moreover, if the user wants to obtain directions to the restaurant, he
needs to enter a start address.
Yelp’s mobile website
Finding directions to a Mexican restaurant. When the user first enters the search string
(in this case “Mexican”), he or she has to type in a value in the Near field. Once the user
gets a list of results, she can select one particular restaurant, and then she can inspect a
map. The map has a different interface than the regular map application that comes with
the phone. If the user wants to obtain directions to the restaurant, he needs to enter a
start address.
Let’s compare this set of steps with those in the Yelp application on iPhone. The user
needs to enter the same search string, but there is a default location (Current Location)
that, if appropriate, will save the user some typing effort. Again, the user needs to select
a restaurant, but, once he’s done it, he can call the restaurant easily by clicking on the
phone number, or he can get directions by clicking Directions to Business. When this
latter link is chosen, he is given directions from his current location to the restaurant in
the native iPhone map application. Note that, with the application, the user only needs
to type once: when he enters the search string (the type of restaurant he wants to find).
On the website, the user needs to type at least three times: to fill in the search string,
to fill in the Near field, and to fill in the Start address field.

Yelp app for Android
Finding a restaurant using a mobile application. Users are offered a Current location
default for the Near field. They can also click directly on Directions to Business; the
native map application will give directions from current location to business. The user

does not have to type anything besides the initial search string.
One of our study participants talked about the ShopSavvy application for Android.
ShopSavvy is a price comparison application that is integrated with the phone
camera: it saves typing by allowing users to take a picture of a product barcode.
“[I would not use] the Web directly, I would not use my browser [to shop for
a better price]… I would actually use my ShopSavvy app. I don’t have the
product with me […] I could search for a product …It’s a pretty cool interface,
see I could scan a barcode or I could use the keypad to search for it […] And,
then, I could go browse the website or I could email myself a link right off the
bat.”
• Applications can work when the phone is offline. As people move around their
day, the quality of the cell signal or the availability of a wireless network varies.
Applications often pull data from a server when the phone is connected and use it
offline. Some apps store data on the phone and require few (if any) server accesses.
Users appreciate being able to use their phone when they have poor or no
connectivity.
• Applications require platform-specific development. As companies develop

applications for various devices, they need to train staff and have potentially
different development teams and processes for different platforms. It can be more
costly to create several mobile apps versus a single mobile website. Although you
may need to have three variants corresponding to three different types of phones
(feature, smartphone, touch), the same website can work on an iPhone and on an
Android phone.
• iOS applications need to go through an approval process before they

become public. iPhone apps need to be approved by Apple before becoming
available in the Apple’s App Store. Although users potentially benefit from this
process (by experiencing a consistent look-and-feel across apps), in practice, it also
means that the app’s launch in the App Store can be delayed.
• iOS apps need to abide by Apple’s purchasing and subscription model, as

well as by acceptable content rules. Many content publishers dislike having to
share part of their revenue with Apple, so they sometimes try to create web apps
that replicate more closely the experience of a regular app, but are, in fact,
webpages.
• Users need to install and update apps. Another potential disadvantage of apps is
the user effort required to install and maintain it. Most users are fairly familiar with
installing apps on their phone, but they don’t necessarily update their apps
religiously and often think of app maintenance as a chore.
Websites do not need to be downloaded, upgraded, or updated by users; the
maintenance work is entirely delegated to the website.

• Apps are less discoverable than websites. Users have to know first about an
app in order to install it 13; moreover, they need to search for the app in an app store
and install it. In contrast, everyone can access a website — whether they had heard
about it or not (via a search engine).
• Apps are for repeat users. Installation, in particular, forms a high barrier to
adoption. Because the cost of installing an app is quite high (in terms of time, but
also space taken on the device), users will not bother to do it unless the estimated
benefit they get from the app is on par with the cost.
Even if a user may have heard of an app, it’s unlikely they will install it if they
estimate a one-time use. Mobile information needs rarely lead to apps being
installed: when people have specific information needs (as they often do when they
are on mobile), they look for answers on the Web. The exception is when users
estimate that they will have that need over and over again. For instance, if every
week they order pizza from the same place, an app is probably more convenient
than a website.
Because of that, we usually advise to design apps for repeat users: for people who
are familiar with your company and will engage with your app repeatedly.
Consequently, it’s highly important to personalize the app to the user and save
history and state, so that users can perform their usual tasks as fast as possible.
• Applications make it easier to personalize the content to the user.

Although nowadays some personalization is available in websites as well, we do not
see it as much as in applications.
WHAT TO INCLUDE ON MOBILE

This section applies to both websites and apps.
Who Your Users Are
Browsers and Searchers

When deciding what kinds of tasks you should support on mobile devices, it helps if you
think back at the two types of activities that people do on mobile (see the section “What
People Do On Mobile Phones”): killing time (or browsing) and searching for specific
information.
When users browse, they look for something interesting to do. Searchers look for one
particular piece of information — they usually need that information to achieve a real-life
goal (e.g., eat lunch, get to your store). Searchers want to be done with your site as quickly
as possible, in order to go on and pursue their bigger goal.
Think about who your mobile users are: are most of them browsers or searchers? Do they
come to your app or website to look around and kill time or to find facts? When you
consider the kinds of tasks to include on your mobile platform, you need to understand who
your users are and what kinds of goals they have. The mobile design and content will be
affected by whether your users are browsers or searchers (or both).
What Phones Your Users Use
13
On their search-results page, Bing (both the iPhone-specific mobile website and the
iPhone app) shows applications that match the query, making it easier for people to
discover apps.

It’s also important for you to understand what kinds of devices are used to access your site.
Go to your analytics data and gather as much as you can about your mobile accesses. Do
you see a lot of feature phone access? Do you get many Blackberrys? These answers are
also related to the kinds of things users will do on your site (for instance, feature phone
users tend to be mostly browsers), but, most importantly, they will also help you figure out
what platforms you should focus on.
What Your Top Tasks Are: What You Should Support on Mobile
Your mobile site or app should only include those functionalities that are typically needed
(or likely to be needed) on a mobile device. You can use site analytics and surveys to get a
sense of what mobile users are already doing on your site. Also, take a look at what is done
most frequently on your full website. What are your top ten tasks on the desktop? Out of
those, pick a few tasks that are most likely to be done on a mobile device.
Most of the time, your tasks will be highly particular to your industry, or even to your
company, so you’ll have to figure them out by yourself. Here we include some general
guidelines to help you out in that process:
8. Tasks that have a deadline are more likely to be done on mobile devices.
In our diary studies, participants were more likely to do transactions on the phone when
they were under time pressure. Examples include buying a gift at the last minute,
paying bills during vacations, checking bank account balances before writing a check.
A diary participant recalled how she used her bank site on the way to the grocery store:
“I was sitting in my car and I checked my bank account, and made sure I had
money and didn’t need to transfer from the other account I have […] [The
site] came up and showed that I had money, and, if it hadn’t, I could have
made the transfer right on the phone.”
9. Tasks that involve rapidly changing information are more likely to be done
on mobile devices.
Examples of such tasks are sports scores, traffic, flight information, order status, movie
schedules, or product availability information (i.e., is a product available at a given
store).
10.Tasks that require privacy are more likely to be done on a mobile device.
According to data from 2007, the most frequent searches done on the Internet involve
adult content 14. While this finding reflected the infancy of the mobile Web at the time, it
also pointed out that small-screen devices are ideal for activities that we want to keep
private. Although none of our participants mentioned adult content, several did note that
they used their phone at work as a discreet way of checking personal email or doing
non-work related tasks.
This is how one diary participant put it:
14
Kamvar and S. Baluja. Deciphering trends in mobile search. Computer, 2007. See also
Church, K., Smyth, B., et al. A large scale study of European mobile search behaviour.
MobileHCI ‘08.

“I was at work … I read some email and visited some [news] websites [on my
phone]. My work usually tracks our Web usage, so I try not to do some
personal things on my work computer.”
11.Finding information about businesses is a task likely to be done on a mobile

device.
According to our diary studies, information gathering is the second most frequent type of
activity done on a mobile device (see the section What Do People Do on Mobile Phones).
This kind of activity most often involves quickly finding a specific fact that is needed in
order to accomplish a real-life goal. The tasks that we observed our participants do
involved finding business hours or business locations, finding particular types of stores
(e.g., pizza), finding the phone number of a restaurant.
A Dutch diary participant was trying to find stores that sell glasses on his mobile phone:
“We were going to buy glasses, so we wanted to know where the stores were
located. [We] wanted to get an idea where we should go to buy the glasses,
and know the best route to walk to make it an efficient way to spend our time
today.”
An UK diary participant used her phone to look for bars that stayed open late:
“I was looking for bars/pubs that had a late Sunday license. […] I managed
find bars/pubs in the area and was able to call them to find out what time
they closed.”
12.Finding directions and public transportation information, as well as

information needed in an emergency are tasks likely to be done on a mobile
device.
Under this guideline you can put any needs that people have when they are away from
their home or desk. Most often these needs involve directions, maps, and public
transportation information (How do I get there? When is the next bus coming?)
Occasionally, however, emergency information may be required (e.g., what to do when
you are stung by a bee, or when your child accidentally swallowed some detergent).
Emergencies occur in all circumstances, and, often, the phone is the only source of
information for users, so they use it to figure out what to do in such a situation. Content
that pertains to emergency situations should be readily accessible and readable on
mobile.
13.Tasks that require communication with others are likely to be done on

mobile phones.
In our diary studies, we found that the most frequent activities performed on mobile
devices involved some form of communication with others (see the section What Do
People Do on Mobile Phones). The most encountered examples involved email, social
network sites, and forums. In some situations, the communication was around a
product: users emailed pictures of that product to friends or relatives in order to decide
what to buy.
One of our male diary participants used email to decide which boot to buy:

“I was shopping for boots… I took photos and sent them to my wife to see
which style of snow boot she preferred.”
In contrast, tasks that are less likely to be performed on a mobile device are those that are
complex or very time-consuming, such as thorough research, large amounts of reading, the
comparison of many options, or advanced transactions. Support for such tasks can safely be
relegated to the full website, thus simplifying the mobile site, as long as you follow guideline
40 (below) to include a link to the full site on the mobile site.
Content that Should Be Included on Mobile

When the mobile offering is impoverished compared to the full site, people complain. If you
have 1000 items in your Web catalog, but only 100 of those appear on mobile, then user
will be disappointed. And justifiably so: the answer they will find on mobile will be
substantially different than what they could find on the desktop.
So when thinking what content to include on mobile, always abide by these rules:
14.The response to a user question on mobile and on desktop should be the

same.
15.It is ok if some questions have answers only on desktop.

In other words, if I am looking for an item such as a book on mobile and on desktop,
I should be able to pick the same one. I shouldn’t have to settle for a different book
on mobile because my favorite book from the desktop is not available. However, if
the mobile site included no books at all, that would be acceptable – I will know that
the information is not available on mobile and go to the full website.
MOBILE SITES
Do Users Prefer Full Sites or Mobile Websites?

Users often say that they’d rather go to a desktop site than to a mobile site. That’s mostly
due to the prior experience that users have with mobile-optimized content: part of it is
encountering sites that have been automatically “optimized” for a small screen, and that
typically rearrange the links on a full page in a long list. Another reason is the limited
content that users often encounter when they go to a mobile site. In an attempt to make
the content more digestible, some sites include only a tiny subset of the full-site offerings
on their mobile site. And, finally, some users declare that the mobile site looks simple and
impoverished.
One of our participants was trying to make a reservation on MGM Grand Hotel’s mobile site.
The first thing she said when she saw the site was that it was very barebones, and she
expected more flashy websites from MGM. However, she was able to finish the reservation
quickly and the pages downloaded fast. In the end, she came to appreciate the simplicity of
the site and was pleasantly surprised at how easy it was for her to complete the task.
The bottom line is: You should not listen to what users say, but rather look at what they do.
When people use mobile sites, they typically are more efficient and more successful. But
when you ask them whether they prefer mobile sites, they might tell you otherwise.

Mobile Site, But Which Device?
Once you decided you want to build a mobile site, a related question comes up: for
which kind of phone should you build your site? Should you build a site that works on
all types of phones, or should you focus on one particular phone?
The answer is: it depends on your audience. Since feature-phone users tend to use
the mobile Web less than other mobile users, for most sites it makes sense to focus
on the powerful phones. However, there are exceptions. For instance, news or
weather websites, university websites, and other websites of very broad interest may
be visited on all types of phones.
Ideally, you should build one site for each of the three big phone types (feature phones,
smartphones, and touch phones). Different phones have different constraints, so it is not
surprising that the optimal page layout will vary. For instance, feature phones have very
small screens, so every bit of space is precious. For such phones you may need to give
priority to new content at the expense of navigational links or search boxes (which may get
pushed down the page). For phones with bigger screens, although screen space is still
precious, you may afford to keep navigation or search boxes at the top of the page.
BBC had different websites for at least two different types of phones: smartphones and
touch phones.
(a)BBC’s mobile website for (b)BBC’s mobile website for Blackberry

iPhone
BBC’s mobile website had different variants for different phones.
Sometimes, it may not be feasible to build multiple mobile sites. If that is your case, we
recommend first taking a good look at your users: what kinds of phones do they use when
they access your site? Do you get many mobile accesses from feature phones (likely if your
site is a news site or a content aggregator)? If yes, you should probably build to the lowest

common denominator: your mobile site should work well on every type of device,
irrespective of the size of the screen.
However, most sites do not fall under this category. In fact, a survey carried out by Pew
Internet Research in August 2011 showed that 84% of all smartphones or touch-phone
owners used the Internet on their phone in the US, whereas only about 15% of the other
phone owners in the US used the mobile Internet 15.
Moreover, our own data (see the section Success Rates: Does the Phone Matter?) suggests
that the better the phone, the higher the success rate — people with higher-end phones
simply are more successful on the mobile Web and, thus, more motivated to come back.
Not only are smartphone and touch phone users more likely to use your site, but they also
may be hurt if you deliver a site built for feature phones. For instance, the examples below
show how a site designed with feature phones in mind can make touch phone users do
extra work — the links on QVC’s mobile site are so close together that it is hard for users to
click/tap on them accurately, and the text on The Trainline (a train ticket retailer in the UK)
is simply too small for the big screen of a modern touch phone.
(a) m.qvc.com (b) m.thetrainline.co.uk
Two mobile sites that do not display properly on Android phones; users need to zoom in to
click on individual links accurately or to even read the text.
Based on these observations, we make the following recommendations:
15
Aaron Smith. Americans and their cell phones. Pew Internet . August 2011.

16.Build a different mobile website for every major type of phone (feature,
smartphone, touch).
17.If you must build only one mobile site, build a site for the high-end phones
(touch phones and smartphones).
Accessing a Mobile Site

In our usability testing sessions, we observed people use a search engine even when they
had the exact URL of the site they were trying to reach.
As one user put it, a search engine allows people to type less and corrects spelling
mistakes:
“I typically like to use Google or something like that to [get to a website] —
just so that I type less … You probably noticed I always do that instead of just
trying to go to the website directly. I just try to minimize the typing strokes.
And, then, there’s a better chance that I get what I want sometimes — when
I’m texting I might misspell something, but Google usually interprets that
pretty quickly.”
A search engine can also help users on a mobile phone by exposing them to the information
structure of the site and allowing them to get to the page they need faster. For instance,
when searching for the Chez Panisse website, many of our users were able to get directly to
the menu page from the search engine results page (see the figure below).
Google search result for “chez panisse” included links to the different sections of the
site. Users could click directly on the link labeled Café Menu, without going to the
actual site.
However, unfortunately, this dependence on search engines makes it harder for people to
get to mobile sites. Search engines like Google rely on page-rank algorithms that give
priority to sites with many links pointing to them. Mobile sites do not have many links

pointing to them — even if your site typically gets a high rank on a search engine result
page, your mobile site will probably not get the same rank.
Another problem related to search engines is that, although they have variants that
prioritize mobile-friendly sites, when they detect a smarter phone, they often direct it to the
full (desktop) version.
That means you must work harder to direct your users to the mobile variant of your site.
The following guidelines help you make your mobile site findable.
18.Detect if users are coming to your site on a mobile phone and direct them
to your mobile site.
It is surprising how often sites do not re-direct mobile users to their mobile variant.
Although much money and effort may have gone into that mobile site, users are left to
struggle with the full site on their phone.
During our testing sessions, it’s almost the rule that users will get the full site when they
just type in the name of the company into a search engine or even the company’s URL
into their browser. When we test mobile sites, we often end up giving user the mobile
URL.
(a) Abc.com (b) m.abc.go.com
When users typed “abc.com” in their mobile browser, they were taken to the full
website instead of being redirected to the mobile website.

19.Don’t ask users if they want to go to the full site or to the mobile site on a
separate page.
Most of the time, when users are on mobile, they want to get to the content as soon as
possible. Deciding whether they want to go to the mobile site or full site is
counterproductive for several reasons: (1) they may think they want the full site to get
the full experience and not risk missing anything, without realizing that they will struggle
with the interactions (see section Do users prefer full sites or mobile websites?); (2)
they will have to think and make a decision, spending valuable time on mobile; (3) the
full site should be accessible from the mobile site anyhow (see guideline 40).
We witnessed many users who were not sure what they were supposed to do when
confronted with a screen like that from Fandango below. Plus the words “Web version of
the site” are misleading – the mobile page is also a Web version of the site, but, from
this wording, people may think that it implies that the mobile site is not on the Web.
Fandango.com on iPhone
Don’t force users to choose among different platforms.
20.Include a link to your mobile site on your full site.
21. The link labeled “Mobile” on your full site should not point to information
about your mobile site.
The link to your mobile site serves two purposes:

1. It can increase the search ranking of your mobile site (since one more page links
to it)
2. It can direct mobile users who were not re-directed to your mobile site.
The link should correctly point to your mobile website.
This is an example of how it’s (correctly) done: on the BBC website, they had a link to
mobile that was highly salient at the top of the page, and, when you clicked on that link,
it directed you to the mobile page.
BBC
BBC had a salient link labeled Mobile on their full site. The link led to the mobile
BBC site.
On the other hand, United.com hid its Mobile services link under a dropdown menu. That
link pointed to a page with information about the mobile services offered by United,
instead of leading to the mobile page.

United
The full site United.com did not contain a link to its mobile site. Their Mobile
services link was buried under a menu item and led the users to a page with
information about how to access United’s mobile site.
There is an additional, unexpected benefit from linking to your mobile site from your full
site: mobile sites may make the desktop user experience better for people with
accessibility issues. Indeed, “optimized” websites — that is, websites that are
“linearized” in order to be rendered on a mobile phone — resemble the list of links that
screen readers read aloud for blind users. For both screen readers and websites
“optimized” for mobile, the links are presented in an arbitrary linear order. Order in that
list does not translate directly into visual salience on a two-dimensional screen; that is
why a highly salient page element on a two-dimensional page may become buried under
several linear pages of links.
We can push the parallel even further: full sites displayed on smartphones are not unlike
full sites displayed through a screen magnifier. In both cases, to get access to details,
the user needs to zoom in; in doing so, she loses the panoramic view of the page and
she can easily get disoriented (see below).

(a) United’s full site on iPhone, after (b) United’s full site viewed through a
pinch-zooming to the travel-booking screen magnifier on a regular PC (as
form. would be seen by a low-vision user).
Thus, if mobile sites were accessible on desktops, users with visual impairments may be
able to use them and benefit from their features.
22.Use the word “mobile” in the title of your mobile site.
23.Use SEO to increase the visibility of your mobile site.

Both guidelines 11 and 12 will make your site more findable by a search engine.
24.Standard domain names and URLs (m.site.com, mobile.site.com, site.mobi,

www.site.com/mobile) should all point to your mobile site. If you can
afford only one of these domains, use m.site.com.
Some users may be tempted to go to the mobile variant of your site and type
mobile.yoursite.com, expecting this address to work. Unfortunately, there is still a lot of
inconsistency in naming mobile websites. Some sites use hard-to-guess addresses (e.g.,
pda.sky.com, 101cookbooks.com/iphonerecipes/, 3gnewsroom.com/avantgo/). Do not
force people to guess the name of your mobile site. Typing on a mobile device is hard
already.
For some of our usability-testing tasks, we actually gave users the URL of a mobile site.
We sometimes saw people abbreviate “mobile” to “m” — for instance, one of our users,
instead of typing “mobile.fandango.com” (the URL that we gave to him), typed
“m.fandango.com”, expecting to get to the same site. Whenever the abbreviations did

not work, users were annoyed to have to spell the entire word “mobile”. That is one of
the reasons for which we recommend using this URL, if only one domain can be used.
If you follow the guideline to make all the addressing variants work, auto-forward all of
them to one canonical URL. No matter what people type, they should end up in the same
place. This can also be helpful for SEO and will reduce confusion.
Designing a Mobile Site

Because of the small screen and the painful interaction (due to slow downloading speed
and/or small keypads), you should think seriously about which elements and functionalities
of your full site need to be transferred to mobile. Anything that you put on a mobile page is
likely to grab a portion of the user’s attention — the more items you put on the page, the
less attention each of them is going to get and the slower the downloading speed is going to
be. Moreover, the task workflow on mobile should require just 1-2 clicks — since each click
represents an opportunity for a dropped connection and for slow downloading. If your site
forces users to click many times to get a task done, the chance that they give up will
increase.
The quote below comes from a user commenting on the functionality available on his
banking site:
“There’s way too much information, way too many choices in there… To me,
it looks like there’s a lot of extraneous information … If I’m on my phone, I
just want to check the balance I have in there, to make sure, you know,
[that] I don’t have any bouncing checks or [decide] if I’m gonna [need to]
transfer funds … I don’t need all this stuff — having questions and there’s a
lot of other goopy stuff… This stuff is all well and good for the website when
you’re on a PC, but for a phone — I don’t need all this… That’s just more stuff
it takes to load the page and that will make it slow; all these things — I don’t
need that.”
25.When designing a mobile site, minimize the number of clicks required to

complete a task.
Note that this guideline sometimes applies to apps, but sometimes it doesn’t. If a click
does not make a request to the server and does not bring in new data (as it is often the
case in apps), then the number of clicks is not that important. What’s essential in this
process is minimizing the waiting time and the chance of a dropped connection.
MOBILE APPS
Differences Between Mobile Platforms for Apps

Over time, we noticed a convergence between Android and iPhone design – more and more
apps look the same on the two platforms. Although that could eventually mean more
consistency across apps, it can also lead to ignoring major differences among platforms.
Perhaps the most fundamental difference between the iPhone and the other platforms is in
the physical buttons available to users. The iPhone only has a “Home” button, whereas
other platforms also have a “Back” button, a “Search” button, and, in the case of Android, a
“Menu” button. At least in theory, that can mean that interface functions can be taken away
from the screen, leaving more space to content. In our section Physical Buttons on
platforms other than iOS, we discuss in more detail whether that is a good idea always.
Another big difference between iOS and Android phones is multitasking. Whereas iOS does
allow multitasking, it is much more limited than the true multitasking that Android

implements. In practice, while Android users can benefit from tasks being carried out in
background, they also have to deal with issues such as memory and task management.
Android users seem more concerned about preserving battery life and making sure that
they don’t have many processes running. Anecdotally, they also seem to be more
conservative with the installation of new apps, as they tend to run more often into problems
of space when they have many apps installed.
Finally, Windows Phone 7 comes with the deck-of-cards navigation model embedded in the
OS. Apps are invited to follow that navigation model, which is not as frequently encountered
on other platforms due to a lower discoverability. Windows Phone 7 sets some good
examples for how to signal this navigation model to users.
(a) Android (b) iPhone (c) Windows Phone 7.
Physical buttons on different platforms. (a) Android phones have “Back”, “Menu”,
“Home”, Search” buttons. (b) iPhones have a single “Home” button. (c) Windows
Phone 7 phones have three physical buttons “Back”, “Home”, and “Search”.
Making Your App Findable

iPhone and Android app stores already have hundreds of thousands of apps. In an ocean of
apps, what can you do to make your app easy to find and recognize?

26.Choose app names that are unique, recognizable, and memorable.
First, make sure that your app has a recognizable, unique, but also memorable name.
Names that are too common are not identifiable – if someone recommends your app to
a friend (and 45% of apps are discovered through word of mouth 16), you want that
friend to be able to easily find your app.
27. Choose an application icon that is descriptive and easy to recognize.

Application icons that are too generic or too obscure don’t help users recognize your app
any faster when they’re looking for it. The icon should also be indicative of the app’s
functionality, so that users can “guess” what the app is about, even if they don’t
remember using it.
(a) (b) (c) (d)
Application icons. (a)-(c) include a logo, which makes them more recognizable. (d) is
less identifiable: it’s harder to guess what the app is about just by looking at the icon.
28. Your app description should clearly explain what the purpose of the app is
and if it has any special features compared to other apps (and especially, to
the free or paid version of the same app).
29.Your app description should not be too long.

Users are not going to sit in awe, reading carefully pages and pages of app descriptions.
Limit the description to the key points and format it according to the rules of writing for
mobile (see guidelines 98–108). If the app is special in any way, prioritize the
description of that feature. If a new version includes updates that were requested by
users, make sure to mention that in the description. If you have several versions of the
same app, it’s important to explain the differences so people know which to get.
16
The Nielsen Company, 2011. http://blog.nielsen.com/nielsenwire/consumer/you-have-an-
app-for-that-now-what

Out of Milk Shopping list: app description
The description ran over 6 screens. The first paragraph stated the obvious (“With Out
of Milk your Shopping List stays with you everywhere you go and you’ll have it on hand
once you’re ready to go grocery shopping.”) The description did explain the
differences between the paid and the free versions of the app.
30. Advertise the app on your mobile website. Make sure that you promote the
right platform on the right device.
31.Advertise the app as a link on your homepage rather than on a separate

page.
If users come to your site and you have an app, let them know. But don’t force them
into making a decision between whether they need to download the app, go to a mobile
site, or go to the full site. Users want the answer as soon as they can. Don’t delay them
by having them think and make a decision.

(a) m.fandango.com on Android (b) Imdb.com on Android
Advertising your app on your website. It’s better to include an ad on your page (a)
rather than force users to choose among different platforms (b).
Sometimes users may already have your app, but choose to go to the Web to get more
information from several sources at once. For instance, searching for a movie into a
search engine will give pointers to both Wikipedia and IMDb; a movie buff who wants to
see both sources may prefer the Web for that particular task, rather than carrying the
search twice in two separate apps.
What to Include in a Mobile App
32. Find a core function and design around it.
33.Keep the app functionality simple.
34. Don’t add features that are unrelated to your core function.
After watching a lot of people use apps on their phones, we can confidently say that the
secret of a good app is keeping the functionality simple. We find that, whenever features
are exposed and easy to access, users are successful. The trouble appears when the tasks
involve some complex feature that’s hidden under a chain of buttons.
In the section on success rates, we have seen that the success rate for apps (about 74% for
touch phones) is relatively close to the one on the desktop (84%). Does that mean that, in
the near future, if the rate will get around 80%, we’ll be ready to get rid of our computers

and replace them with our phones? No. In fact, most of the tasks that users perform on
phones are a lot simpler than the ones that people typically do on desktops. And this is,
partly, because most apps support only a very small number of tasks that are very simple in
nature. And that’s how it should be.
However, the temptation of bigger and better things arises every so often. We see apps that
attempt to fit any possible (sometimes remote) feature in their app. If a single user
requested that feature in a review, developers feel compelled to oblige – with ten users
asking for ten different things, they have the chance to bloat their app to the point of
becoming unusable.
We often get asked: if my company supports multiple kinds of tasks, should I build an app
for each or should I divide the app into multiple apps? Most of the time the answer is to split
the app into several apps, especially if the tasks are disparate.
Grocery IQ is an example of app that strayed from the basic tenet of designing around a
single functionality. The app is a shopping list - that is its core function. However, next to
the shopping list, there is an almost separate coupon feature: users can clip coupons
available in the app and add them to the shopping list. They don’t necessarily get coupons
suggested to them for items in their shopping list.
The result is that the shopping list is suddenly cluttered with items that are non-essential.
Instead of being able to quickly figure out if they need to go to the store or not, users see a
long list of coupons added to the list.
Grocery IQ for iPhone
The app is a shopping list, but also has a coupon section, where users can add coupons
to their shopping list. The final shopping list gets cluttered with unnecessary content.
And the coupon and the shopping list features are not tightly integrated.

(a) Weather app for iPhone (b) The Weather Channel app for
iPhone
Two weather apps. (a) focuses on just the basic information, whereas (b) has an
abundance of features that are unlikely to be needed and that clutter the interface.
The Weather Channel has suffered many changes over time, both on Android and on
iPhone. With each new version, new features seem to be added to the app. A recent version
did a lot more than simply report the weather forecast: it allowed users to see tweets
related to the weather or post their weather on a variety of channels, it showed dew point,
visibility, as well as sunrise and sunset information, and also weather alerts, videos of the
weather, photos shared by others in the area, allergy indicators, info about their TV
channel, and a map of the weather. Compare that with the Weather app that comes with
the iPhone: there you just see the current temperature and the forecast for the next few
days.
Your app should be as simple as possible. Hidden features are hard to reach, and they
increase the visual clutter. The more users have to choose, the more they have to think
about it and the longer it takes.
From Desktop to Phone

What if you already have a desktop app and you want to move it to mobile? Should you
provide the same functionality on the phone? The answer is no. Users cannot do on the
phone the same kinds of tasks they do on mobile.
35. Do not implement your full desktop app on mobile.
36. For the phone variant of your desktop app, choose only a small subset of
features that revolve primarily around consuming rather than producing
content.
Think hard at the types of functions supported by your app that are likely to be needed on
the go. If your app is a productivity app that requires a lot of input from the user, chances

are that on the phone users won’t need the same plethora of editing functions. Look for
instance at Quick Office — a version of Microsoft Office for iPhone. From all the features that
Microsoft Excel implements on the desktop, they picked a very limited subset that
essentially allows users to do some basic formatting and, most importantly, lets them view
Excel documents on their phone.
Change format Add/del columns Change sheet Find Undo/Redo

or rows
Quickoffice for iPhone
Only a few features from the desktop are supported by the phone version.
Similarly, PS Express, an iPhone version of Photoshop, an application notoriously difficult

on the desktop, had many fans among our participants. The app supported only a few
basic photo-editing features that enabled users to quickly correct the pictures taken by
their phone camera.
37.Design for a continuous experience.

If you have multiple platforms (e.g., a website or a desktop app and a phone app),
users’ data should be consistent across platforms. Users shouldn’t have to worry about
syncing their data – they should have access to them wherever they are.
Mint, for instance, allows users to see the transactions entered on their phone when
they use their regular computer. Similarly, Epicurious, a cooking app, allows users to

sync their recipe box (on the phone, on their tablet, and on the website), but only if they
pay an extra fee.

Principles of Mobile Usability
Most of the guidelines in this report are instantiations of a few basic mobile usability
principles. We enumerate them here to help you devise your own guidelines in situations
that ours might not cover.
 Design for interruptions. Save state for the users and allow users to save
state.
Interruptions are bound to happen when users are on the phone: they eventually will
need to switch their focus of attention to some other stimulus in their environment.
Sometimes the source of interruption might be outside users’ control: connections might
drop or problems might arise with the phone.
The mobile app or website must save state at all times and be prepared for such
interruptions. It should also try to do the transition back to the app/website as smooth
as possible, so that the user doesn’t have to redo work already done before the
interruption.
Moreover, when on mobile, users don’t always make definitive decisions, but may want
to return to certain content in contexts with larger bandwidth or screen. Allow users to
save history, as well as to email or share information with themselves or others. And
also allow them to return to their data on other platforms and access any actions they
may have carried out on mobile.
 Don’t ask users to go elsewhere for information.
One of the main limitations of phones is that a single window is available at a time.
Users must leave your app or your website to find information that the app/website may
require, but that it doesn’t provide. Remember that pen-and-paper, even if available,
are often unusable on the go. Your app/website should be self-sufficient and should not
necessitate any external props, be them physical or virtual.
 Take advantage of the phone features.
If the phone comes with a camera, don’t ask users to type in barcodes. If the phone has
a GPS feature, don’t have them enter zip codes. Use the phone features as much as
possible to lessen users’ work.
 Consider the opportunity cost of each design element.
Because the screen is so small on mobile, whenever you include a new design element
on the screen, something else gets pushed out (or below the fold). Think hard of the
opportunity cost of each new element: what does it mean for the users if you leave out
widget B in order to include widget A? Is widget A more important than widget B?
Although we provide general guidelines in this report, your answer likely depends on the
kinds of users and tasks that you have.
 Minimize the interaction cost.
This is the Holy Grail of usability: deliver to users the information that they need without
having them lift a finger. Of course, this is impossible for most pairs of tasks and users.
But that should be your goal. This principle subsumes all the others and it says that you
52 INFO@NNGROUP.COM Principles of Mobile Usability

should design your apps so that the reading, the scrolling, the clicks or the taps, the
waiting, the looking around trying to find information, the thinking, the remembering –
all these be as close to zero as possible.

General Guidelines for Mobile Websites and Apps
HOMEPAGE
What to include on your mobile homepage mostly depends on the type of site and users
that you have. However, there are at least two items that should be present on any mobile
homepage: the company logo and a link to the full site.
38.On websites, include the company logo or name in a salient location at the
top of the mobile homepage.
39.On websites, include the logo on every page of your site and make it link to
the homepage.
The mobile screen is small, so it may seem like a waste to include a logo on each page.
Wrong! Unfortunately, on a small screen people often get disoriented and confused; they
may ignore or not see the context in which the information is presented. Many times
they reach the webpage via a search engine and have no idea where they are. The URL
bar and the title bar may not be displayed in some mobile browsers, so unless you tell
them explicitly where they are, it may be hard for users to find out.
Still, do make the logo fairly small, as long as you keep it recognizable. Big headers are
only for the desktop Web.
One of our users was using Google to search for Wikipedia on a feature phone. She got
the results back, but the result page contained the search box with her search string
(she had entered “mobile.wikipedia.com) at the very top of the page. The search box
looked very much as a URL bar, so she mistakenly assumed that the search-results page
was the Wikipedia page. A more salient logo on the page could have helped with
making her understand where she was.
The screenshots below show how the logo can be incorporated on the page, without
taking too much space.
54 INFO@NNGROUP.COM General Guidelines for Mobile Websites and Apps

(a) iphone.zappos.com (b) m.youtube.com
The logo for Zappos (a) and YouTube (b) appeared on the homepage, without taking
up too much space.
Note that for apps it’s not so important to have a logo. With apps, users are much more
in control: they decide which app to use by launching it from their home screen. So,
most often, they already know what the app is. It’s also unlikely that the user be taken
to a random page in your app while using a completely different mobile app, as might be
the case when using the Web.
40. Include a link to the full site on the mobile homepage.

Because mobile platforms only support a limited functionality, it is unavoidable that, at
some point, some user will be looking for content that is not included on your mobile
site, but does appear on your full site. To help the user in those situations, link to your
full site from your mobile homepage.
We’ve seen many users being disgruntled and suspicious of mobile sites, in general;
such users prefer full sites because they think mobile sites have less content (see Do
users prefer full sites or mobile websites?). Although we don’t believe that the user
experience is better on full sites, a link to the full site has the potential to satisfy these
users.
Below are examples of how two different sites have included a link to their full page. On
Zillow, a real-estate site, the link to the full site was visible without scrolling. On ESPN’s
site (sports-related site), the link was at the bottom of the page, under the fold.

(a) Zillow (b) ESPN
Mobile homepages that contain a link to the full site. (a) On Zillow’s homepage,
the link to the full site was visible without scrolling. (b) On ESPN’s site, the link was
at the bottom of the page, under the fold.
A user failed to find a map on the nextmuni.com mobile website:
“I don’t think [that there is a map on the mobile site]… unless I go to the
standard website and search for a map there.”

He subsequently followed the link to the standard website.
41.A search tool and navigation should be present on the homepage.

We discuss search and navigation in more detail later in this section and we have a set
of specific guidelines involving each of those. When people are in searcher mode (that is,
they are on a mission to find a specific piece of information), they typically go for the
search box, sometimes without even scanning the content of the page. Moreover, users
default to search if the navigation structure is too obscure and none of the links seem to
be appropriate for their particular goal.
At the same time, navigation is equally important on a mobile phone. Clicking on the
right link may save the user the pain of typing a search query.
However, both navigation and search come at a price: they occupy screen space and
grab users’ attention. If the screen space is really scarce, a search box or navigation
links at the top of the page can interfere with the users’ ability to get to new information
fast and may make the user work more. That is why this guideline only applies to
higher-end phones with larger screens, and does not apply to feature phones.
TYPING
Even for touchscreen phones, typing can be challenging: many of our touch-phone users
had difficulty hitting the right key on the virtual keypad and would often make a mistake. As
one iPhone user put it:
“I don’t like about the iPhone that the screen here is so sensitive, and you
accidentally call some other people. Also, it’s slippery, the phone itself is, so
you have to put a case on. In having this case on, the letters and numbers on
the side here — you tend to push one number over or above.”
In fact, it is not only a problem for those who use a phone case; the keys are just too close
for most people to be able to type reliably in portrait mode.
Because typing is painful, our general recommendation is for your site to save as much of
the users’ work as possible. Next, we make specific recommendations intended to ease the
burden on the users by reducing typing.
42.Use auto-complete and suggestions whenever users fill in a textbox.

The strings that you suggest may be based on site analytics and may reflect what your
site’s users typically fill in those boxes (if there are more common values).
43.Allow for typos and abbreviations.

The harder it is to type, the more likely users are to make mistakes. Instead of exact
string matches, you should do partial matching on the input strings whenever the
entered strings are used for a query in a database.
In one of our usability session, one user searched for the movie “Revolutionary road”,
which he spelled “Revolutionary rd”. The Fandango website was not able to find any
results, because “rd” was not expanded to “road”. The figure below shows the
Fandango-app search-results page when the search string was “road” versus “rd”.

(a) Fandango app for Android (b) Fandango app for Android
Mobile apps and websites should tolerate typos and abbreviations. (a) Fandango
returned zero results when we searched for “rd”. (b) The same app found 74
matches when we searched for “road”.
44.Use personalization and history to provide good defaults for text that needs
to be input.
45.Use GPS information to detect location automatically and allow the use of
current location.
One way to save the user some typing is to produce good defaults. Sometimes the
defaults can be based on what the user has typed in the past (e.g., zip codes, names,
addresses), or on other data that she has previously submitted.
The Time magazine app for iPhone remembered recent searches and allowed users to
easily perform them again. So did the Red Laser application on the iPhone and the
Barcode Scanner on Android.

(a) Time app for iPhone (b) Barcode Scanner app for Android
Recent searches. Both Time and Barcode Scanner remembered recent searches, making it
easier for the users to input them again. (Note, however, that Barcode Scanner did not
show recent searches in a very readable format – it would have been even more useful to
name the products with those barcodes).
It used to be that only applications could access the phone’s GPS and detect the current
location. Most mobile browsers today, however, support that functionality, and many
(but not all) mobile sites take advantage of the capability.
Most users came to expect that sites and apps compute location information for them.
One of our users was upset when he had to enter his zip code to find movie-theater
locations:
“My phone has built-in GPS… I’m kind of mad that now I have to go and do
another type, I have to click on this [textbox] and [type] 94555 and get show
times... I know there’s technology nowadays where it’ll read my IP address
and where it’s coming from globally and locate where I am … I don’t know
why they don’t do that. I’d expect them to do that… it’s like a feature, so I
don’t know, that’s just weird to me, I guess…”

(a) m.fandango.com (b) m.walgreens.com
(a) Fandango made it easy for users to enter the current location by using the GPS.
(b) Walgreens asked users to type in their zip code, city, or state explicitly.
Users are grateful for any work that you can save them. One of our participants was
using the Movies application on his Android phone, and, although his GPS was not
working at the time, the application filled in his zip code based on past sessions:
“[The message says] `Could not determine your location’, but it did give me
what it thinks it’s the closest zip code and, automatically, without me having
to type in the zip code, it brought in the movies for that zip code.”
46.Allow users to easily delete default field values.

This guideline complements the previous one on having good defaults: once you use
defaults, they are bound to be wrong occasionally. If that is the case, users shouldn’t
have to manually erase the text field character by character, by clicking the Delete key.
They should be able to erase the defaults by pressing a single button that clears the
entire field.

The iPhone has a standard button for clearing a (search) box: an “x” that appears to the
right of the search box once the user has typed something in it (see the figure below).
Following this convention on other platforms is not necessarily recommended, though.
Even for iPhone users, the clear button occasionally causes problems: in one of our
sessions, a participant wondered what the “x” may mean and pressed on it, only to
discover that it made him lose his query.
Another possible complication for having a “Clear” button immediately at the right of the
textbox is that it may be confused with the “Go” button that initiates the action for the
textbox (in our case, the search). We recommend not placing the “Clear” button next to
“Go” (like the TV Guide Android app does in the screenshot below) to avoid accidentally
pressing the wrong button. A solution for non-iPhone interfaces may be to have the
“Clear” button at the left of the textbox. (It is almost always an overriding usability
consideration to follow platform conventions to make your user interface consistent with
user expectations, which are driven by the sum of their experiences with other UIs on
that platform. Thus our advice to place the “Clear” button to the left doesn’t apply to the
iPhone.)
(a) Standard placement of the (b) TVGuide app on Android

clear button on iPhone.
(a) The iPhone has a “Clear” button that appears to the right of the search box,
once the user starts typing. (b) Placing the clear button to the right, close to the
“Go” button (as in the TVGuide Android app) makes it too easy to clear the search
query by mistake.
Sometimes textboxes are filled “by default” with a placeholder describing the content
that should be typed in there; if that is the case, that description should disappear when
the user moves the cursor into the textbox to start typing.
A user was trying to plan a journey, and had to enter the start point and the destination:
“One thing I don’t like on this site, when I click this box, where it says
‘Address, intersection, or landmark’ — when I click on it, it doesn’t disappear
and I have to delete it.”
The Carrier app on iPhone asked for users’ email in the settings; unfortunately, when
users tried to type in their email, they discovered that first they have to erase the
placeholder.

The Carrier app on the iPhone.
The placeholder for the email field had to be erased character by character
before entering the email.
(Whenever possible, placeholders should not be used. It’s better to show the description
of the field and/or an example of input either above or next to the field. This will also
allow the users to see the field description/example as they are typing, instead of having
to commit it to memory).
47.Where possible, compute field values rather than asking the users to enter
them.
A lot of information can actually be computed and filled in for the user. For phones
equipped with GPS, apps and websites can detect the exact location. When users enter
an address, the default for the country of destination can match the country where the
phone is being used. Once they enter a zip code, other information can be automatically
computed (like the state and the city). Even if the city is not uniquely determined by the
zip code, we can still offer the user the option of selecting among several alternatives
(or even use autocomplete and suggestions, based on the initial letters that are typed
in).

In UK we had the pleasure of seeing this idea at work: on all the UK sites that we tested,
once the users entered their post code, they could select their complete street address
from a short list. (It turns out that in the UK, there are just a few addresses that have
the same post code.)
The example below is from Interflora’s mobile website. Once the delivery post code iwas
entered, the user was prompted to select their correct address.
(a) (b)
m.interflora.co.uk
(a) Interflora asked users to enter a delivery post code. (b) Addresses that
correspond to that code were shown for the user to select one, saving users
from typing them.
48.Do not make people memorize information from one page to another.
On a desktop, people usually have access to multiple windows; they can easily move
back and forth between them and use information from one window into another. If they
need to refer to a list of instructions while they fill in some complicated form, they can
always keep the two windows next to each other and refer to one while working in the
other.
Unfortunately, this is not possible on mobile devices. Users only have one window
available to them at any given time. Because of that, that window needs to be self-
sufficient – it shouldn’t ask users to refer to other sources of information.
An earlier version of the Bank of America application asked users to select a business
day for an electronic-bill delivery date, but it did not tell them which days were business
days. People had to quit the app, find a different calendar app, then come back, log in
again into their Bank of America account (because the app did not preserve login
between sessions for security reasons), go through the schedule-a-payment process
once more, and finally enter a good date (provided that they could still remember it).
Luckily, Bank of America has fixed this problem in newer versions.

(a) Bank of America app for iPhone (b) Bank of America app for iPhone
(older version)
When setting up a bill payment in the Bank of America app, users were asked to enter
a delivery date that was a business day. (a) The older version of the Bank of America
app did not tell users which days were business days. (b) The newer version corrected
that problem by displaying a calendar.
We still see mobile websites offering coupon codes on one page, and then asking users
to fill in the coupon code on a different page. In the best case, users would have to copy
the coupon code and paste it into the appropriate field at checkout (assuming that cut-
and-paste were supported); why not automatically populate the coupon code for the
users or at least show it on the checkout page so they could select the one they wanted?

mobile.victoriassecret.com
Users had to memorize the coupon code and enter it at checkout.
49.Make textboxes long enough so that users don’t have to scroll within.
Anybody who has tried to scroll within a textbox on a touchscreen with no trackball
knows it’s no easy task. Because scrolling within the textbox is so tedious, if people
want to modify the input string, they simply delete the last characters of the string until
they get to where they want to make the change; then, they type again. But even if a
trackball is added, hiding part of the text in the textbox is conducive to mistakes – users
don’t see all the characters that they entered and can easily ignore a typo.
Of course, the size of the textbox is limited by the screen width: you cannot (or
shouldn’t) design textboxes that are wider than the screen width. But be generous with
the textbox length, especially if you have wide variability in the strings entered. It’s ok
to use short boxes for strings that you know are short (for instance, year, state, or zip
code).

(a) mobile.victoriassecret.com (b) m.zillow.com
Textboxes should be long enough to accommodate the string that goes inside. (a)
Victoria’s Secret had too short textboxes: the entire email address was not visible at
once. (b) Zillow also had short textboxes, but they were appropriate for the types of
strings entered in them.
One of our iPhone users was typing a long search string and was annoyed that he
couldn’t easily scroll within the textbox:
“I look at the results, and it returned no articles in the past 30 days… Hmm…
well, that’s because I misspelled ‘salmonella’… Now I need to go back, check
my typing… I hate it when that happens… yes, there’s the ‘i’, should be an ‘o’
: ‘s-a-l-m-o-n’ … I’ve got to tell you, I don’t like it when you get to these
windows where you can’t necessarily see all the text you’ve typed in, it’s kind
of annoying… I want to advance to the part where my error is and I can’t do
that because the window is too small, so I’m going to make a guess that I’ve
correctly spelled ‘salmonella’ but…”
Another user was attempting to log in to eBay on a Blackberry, but the username
textbox was too short, so she could not see what she had typed. She kept getting login
failures and did not realize that the problem was the username, rather than the
password. (eBay seems to have fixed this problem since). The picture below is taken
from our video recording of the session.

mobile.ebay.com
Logging in on eBay: the user-id field was too short and users could not see the
entire string that they had typed in.
50.Allow users to paste information into an input field.
51.Allow users to copy any content that you may present to them.
Although not every user is familiar with cut-and-paste, those who are expect to be able
to use the technique whenever possible.
One of our participants was using the Salesforce app on his iPhone to manage his many
contacts at work. He shared that his company had an agreement with Skype, so that
whenever he needed to call internationally he could save money by using Skype. Our
participant proceeded to show us how he would call a contact: he called in Salesforce
(using the regular Phone app), then he quickly canceled the call and copied the number
that he had just called. Next, he opened Skype and wanted to paste the number into the
dial box; unfortunately, that version of Skype no longer supported the paste operation.

Users can copy the Users cannot
phone number. paste here.
(a) Phone for iPhone (b) Skype for iPhone
(a) One of our participants copied a phone number from his recent calls list. (b) Next,
he tried to paste it into Skype unsuccessfully.
Another participant searched for car navigators in his Best Buy Windows Phone 7
application. The application had no reviews for the product that he was interested in, so he
decided to go to Amazon to find reviews. He wanted to copy the product name and paste it
into the Amazon app – however, that was not possible because Best Buy did not allow his
content to be copied.

(a) Best Buy for iPhone (b) BBC News for iPhone
(a) Best Buy did not allow users to copy content such as product names from his
app. (b) BBC let users copy text from its articles.
DROPDOWN BOXES, MENUS, CAROUSELS
52.Make sure that your menus look expandable. Use menu labels that clearly
indicate that they expand to a set of options.
Using dropdown menus and other expandable menu formats is especially attractive on
mobile devices because they allow some space saving: a group of links is compressed
under one button. Unfortunately, users often ignore menus, and, hence, the links hidden
under them. The main reason is that menus are not salient enough – often, they don’t
look like something may be hidden under them, and users don’t think to press them.
For instance, on ESPN’s website, a menu was used to switch between different kinds of
results (women’s, men’s, singles, etc.) in a tennis tournament (see figure below). The
menu was not salient (it blended with the background and looked more like a title than
like a menu – the arrow next to it was really small and barely visible). The menu label
(Men’s Singles) did not suggest that there are alternative options to explore. The icon in
the top left corner was also easy to ignore.

m.espn.go.com
The ESPN website used menus to allow people to switch between women’s and
men’s results in a tennis tournament. Unfortunately, users usually ignored the
menu. Note also, that, if they used the menu and changed the selection to
Women’s Singles, they would also have to click the Go button to actually be able
to see the new page.
When we tested this website, users had a hard time finding a way to get to the women’s
singles results, since they were hidden under a menu labeled “Men’s Singles”:
“It’s the men’s singles. I would assume, since they don’t have the women’s
singles up here, that they’re not even playing today […] We’ll go with
[reading link names] Daily Results, Men’s Singles, Results. I think only men
played today, and I’m trying to back into — okay, today is the 27th, let’s go
back to the 26th [after clicking on link]. They still do men’s coverage only here
… Ok, let’s see if we can change this to women’s coverage, [finds menu] ok,
Women’s Singles, ok, go to Women’s Singles, ok.”
Another example comes from the ESPN Score Center app. Both the Android and the
iPhone apps hid a menu under a small arrow. Our users did not think to press that arrow
and did not discover the news section. The Score Center app on Android also had an
upwards-pointing arrow at the bottom of the screen, that, when pulled up, showed the

content of the different horizontal screens. Most of our participants did not consider
pulling that arrow up either.
(a) ESPN Score Center app for Android (b) m.oprah.com
(a) Users did not realize that they could pull the two arrows to get menu options.
(b) Participants in our study noticed the explicit dropdown box at the top of the
article pages on Oprah.com and appreciated that they could easily move from one
section to another.
We’ve seen menus work best when the descriptions were very explicit. For
instance, on Oprah’s mobile website (see screenshot above), users were
prompted to select a section. Users quickly discovered the dropdown box and
took advantage of it to navigate to a different section.
53.Do not use animated carousels. Use carousels that can be controlled by
users.
Carousels are more and more popular on mobile. Animated carousels take more time to
download. Because the screen is so small on mobile devices, chances are that the users
won’t even notice them — by the time the carousel has changed, users are likely to have
scrolled past them.

Because of that, we recommend that the use of carousels be restricted to user-
controlled ones, where the user decides when and if they want to move to the next
section of the carousel.
54. Do not separate the carousel controls from the carousel.

An older version of ESPN’s mobile website used an animated carousel (that could also be
manually controlled) to display sports scores (see below). Our users missed the
automatic changing of the screen. The ESPN carousel also had a set of controls (NCAAB,
NBA, MBL, NHL, MORE) that allowed the users to select a different sport and see scores
related to that sport. Unfortunately, many users did not understand that those buttons
controlled the carousel. In fact, for one of our users, the buttons were above the fold
and the carousel under; changing the buttons resulted in no visible effect other than
confusing the user (who had expected that the buttons take him to a different page):
“Where does it say ‘basketball’? Usually if you got to ESPN it gives you
choices — where is it? Oh, here it is, Scores & Schedules [clicks on Scores
and Schedules], NBA [clicks on NBA]. [Nothing happens] You know what I
really would do at this point? And it’s not even moving, I wonder why … Let’
me try these other ones to see if there’s something else going on [tries to
press MLB]… Maybe there’s no ESPN game tonight, I don’t see anything
scheduled… “
The newer version of the ESPN mobile page still used a carousel; the menu at the top of
the carousel allowed users to change the sport and see different scores. Both the new
design and the old design have the same problem: as described before, it’s easy for a
user to be oblivious of the content of the carousel, while trying to get scores for, say,
tennis. The newer ESPN carousel was no longer animated; however, the arrows that
advance the display were at the bottom of the carousel, separated from the display.

The sport (and the scores
underneath) can be changed by
tapping on one of these buttons. The sport (and the scores
underneath) can be changed
by tapping here.
(a) m.espn.go.com (older (b) m.espn.go.com (newer

version) version)
Carousels: (a) The animated carousel on an older version of ESPN’s site was not
noticed by users and slowed down the site. The buttons at the top controlled the
sport displayed in the carousel. (b) A newer version of ESPN still exposed itself
to the same problems by keeping the carousel and the control at the top
separated. At least the carousel was no longer animated.
Travelocity had a better implementation of a carousel: the arrows that moved to the
next picture were part of the carousel and could not be separated from the carousel by
scrolling.

m.
iphone.travelocity.com
Travelocity used a carousel to show pictures of individual hotels. Their version

was more usable because the controls that moved to the next picture were part
of the carousel. Such a design is unlikely to run into the scrolling issues that we
noted with ESPN.
55.Use cues to show users that they can see more items in a carousel.
One of the problems of the non-animated carousels is that they can have low
discoverability: users may never guess that they can get more content. Therefore, it’s
important to signal to users that they are dealing with a carousel.
Some carousel cues are stronger than others. As we discussed before, arrows placed in
line with the carousel image(s) are better cues than arrows place under or above the
carousel. Dots are generally weak cues (because people often don’t notice them). Half
images or text that looks like it’s continued to the right of the image are strong cues –
users quickly understand that they can get more content.
Below are a few examples of designs with either strong or weak carousel cues.

(a) Crackle app for iPhone (b) Engadget app for Android
Weak carousel cues: (a) Crackle showed an arrow under the carousel and dots within the
carousel. The arrow seemed to lead to an article about Will Smith and Tommy Lee Jones, but
in fact advanced the carousel. The dots blended with the white-and-grey context and were
hard to notice. (b) Engadget showed dots at the top of the carouse; although these dots were
more conspicuous than those in Crackle, they were still a weak carousel cue.

(a) IMDb app for Android (b) News and Weather app for Android
Strong carousel cues: Half images (like in (a)) and incomplete words (like in the News and
Weather example (b)) signal users that there is more content to the right or left.
56. Do not use dropdowns (or pickers) if you have many items and users need
to scroll a lot to read all of them.
Dropdowns and pickers, by definition, occupy only a fraction of the available screen.
They are useful for those situations when there are just a few options to choose from. If
users need to scroll through one or more screens of options to get to the last one, it’s
better to use a different format that takes advantage of the entire screen space to
display those options (for instance, a tabular view on a separate page).
On Staples’ website, the 28 different kinds of paper that users can select were displayed
in dropdown box. It was tedious to scroll through the entire box to see them, and the
app would be better off if it used the entire screen. Similarly, displaying numerical
values in a dropdown box (like Redfin and ZipRealty did, for years, respectively prices) is
counterproductive: there are so many values, that it would be faster to enter directly the
number than scroll through the different alternatives. In contrast, Zillow below used the
dropdown box appropriately: all the different options fit on the screen with no scrolling.

m.staples.com
There were 28 possible subcategories for paper: too many to be displayed in a

popover (here we’ve shown only the first 11).
(a)Redfin app on iPhone (b) ZipRealty app on (c) Zillow app on

Android Android
(a)-(b) There were too many options in the dropdown. (c) The dropdown correctly
included only a few options.

57. Make sure that all the text of each option in a dropdown or popover is
visible.
Another problem that occasionally appears with dropdowns is that options that are too
long get truncated, and users have no idea what they’re choosing.
Kayak below had a non-conventional navigation bar on the left and non-conventional
popovers. Unfortunately, the hotel names did not fit completely in the popover. It would
have been better to use a regular tabular display instead.
Kayak app for iPhone
The hotel names did not always fit in the popover.
FORMS
58. In a form, put the field description above the textbox. Use the colon “:” to
indicate that the description refers to the textbox below.
On a small screen it is easy to lose context and become disoriented. That is why the
descriptions are important. The colon adds directionality to a description: it indicates
that the description is for the following box, rather than for the one before.

Indicating which description corresponds to which box is even more critical in a form,
where many fields have to be filled in. In Victoria’s Secret’s checkout form, should the
city go in the empty box above the word City* or in the empty box under it (see figure
below)? The colon could have been used successfully in this situation to disambiguate it.
m.victoriassecret.com
On Victoria’s Secret website, there was an empty box above the word City*
and an empty box under it.
Note that this is not a show stopper: most users have some prior experience with forms
and, if they look around, they can eventually figure out what they need to enter in any
given box. However, an extra colon is a very small price to pay for saving the users the
effort of thinking more about a form, especially when they are on the go.
59. Make sure that all the fields in the form are aligned.
This guideline seems so obvious: not only does the form look better to the eye when the
input boxes are properly aligned, but it’s easier for the mind to determine what field
needs to be completed next. However, we still encounter examples of poorly formatted
forms, as demonstrated in the example below from Zappos.

iphone.zappos.com
The fields were scattered all over the page; users had to parse all the content carefully
to understand what they must enter.
60.To signal an input error in a form, mark the textbox that needs to be
changed.
61.The error message in a form should be next to the error (and not at the top
of the form).
62. Don’t use alerts or fading popups to signal an error.

When the user has made a mistake in a form, the textbox that she needs to correct has
to be clearly marked. The user should be taken directly to the field that he needs to
change. Otherwise, if the error is displayed only at the top of the screen, because of the
limited size of the screen, the user may not understand what field he needs to change
and might even try erroneously to fix a correct entry.
A user who was looking to check a flight status on United’s website got an error
regarding the From field. Unfortunately, the textbox that she needed to change was not
marked, so she modified the To field instead. Users often do not read the text of the
error message in detail, and if they see that an error has occurred, they will make their
best guess in terms of what the error was.

mobile.united.com (older version)
United’s website signaled an error regarding a From field, but did not properly mark
the field. The user chose to modify the To field instead.
One of our participants was unsuccessful when she tried to log in on ebay’s mobile site.
She got an error message, but no incorrect field was marked, and the message did not
point out which of the fields (user name or password) needed to be changed. Our user
kept changing the password, although there was an error in the username. It is possible
that the designers of the webpage may have chosen not to signal where the mistake
was for security purposes; however, the login process on a mobile device is so tedious,
that, for many sites, making it even more so in the name of security is not worth it.
mobile.ebay.com
Logging in on eBay: the error message did not indicate which field needs to be, nor
was the field marked on the screen.

If an error occurs in a longer form, it’s better to show the error message right next to
the invalid field rather than at the top of the form. The users should be shown the exact
place where the first error occurred, to help them easily locate the error and also see a
description of the problem in front of their eyes, as they are correcting their input.
(a) m.interflora.co.uk (b) m.bananarepublic.com
The errors were marked in situ on both websites; the user was taken to where the
error occurred. However, the small popup in (b) was incorrectly placed and the error
message was hard to read.
Some apps use alerts or messages that fade away after a while to report errors in forms.
We don’t recommend that – they put too much load on users’ memory. They require
them to memorize the error message, dismiss it, and then use what they can remember
to fix the error.

(a) Macy’s iShop app for iPhone (b) Best Buy app for Android
Alerts and popovers for errors: (a) Macy’s app used an alert to indicate an error. (b)
Best Buy used two different kinds of popups for signaling errors. The grey one
disappeared after a few seconds, without the user taking any action. The red one
disappeared after the input focus was moved into the zip code box. In all these types
of situations, users must remember what they need to do and then find the problem
and fix it correspondingly.
63.On a website, minimize the number of submissions (and clicks) that the
user needs to go through in order to input information on your site.
(This is a more specific variant of guideline 25).
Each time the users need to submit information to a server, they have to wait for a
response. Moreover, the chance of the connection being dropped increases, and the
users may lose all their hard work. That’s why it’s important to minimize the number of
steps that make server requests and incur wait time.
Note that applications suffer less from this problem: if an application keeps data on the
phone, an extra click or tap will not necessarily incur a request to the server and it will
not take any significant wait time. That being said, there are applications which keep
most of their data on a server; for them, this guideline still applies.

A user ordering flowers at Interflora.com complained repeatedly about having to
complete 8 steps in order to be able to order flowers:
“You’ve got your options for color, yes, that’s moved in quite quickly… There
was only 6 or seven options on the last screen [where flowers were chosen],
you could’ve made your color selections on the same screen, instead of
having a screen just for color selection … [Next step] add something extra —
that’s fair enough, they’re trying to make money … Maybe a fast track would
be useful … Delivery code, post code … I have to read all that because we’re
moving towards the nitty-gritty […] Ok, there’s some excess page here ..
When I’ve put the postcodes, the options [for the addresses] should have
come up right there… Even when you’ve got pages coming up every two
seconds, you’re at work, you’re not meant to be doing this, you know, it’d
need to be sped up lot and you also want the simplest website you can get …
[Entering the recipient] is unavoidable, but choosing flowers and choosing
color, that’s too much. Now a message… My reaction is the process is
dragging, I’m halfway through, yes, I have to put in my credit card and so on,
but, it’s essential, if you could get it down to six screens or something… Right,
billing details… Again, to be honest, there you have a telephone number you
can ring, and it’s usually quicker to call someone … I’ve got a billing
confirmation — is this necessary? Surely we could have all confirmations…
you could have the flowers, where it’s going to, you don’t get to make that
much of a confirmation, you could have made a mistake early on…”
Several steps on the interflora website could have been compressed together – all the
information needed from the user (delivery date, name and post code of recipient, gift
message and buyer information) could easily have been compressed on a single screen.

m.interflora.co.uk
Interflora checkout process. The user needed to submit information and wait. Many of
the steps could have been compressed together.
On an older version of Fandango’s website, to search for a movie, users had to enter the
movie title and then enter their zip code on a separate page. One user observed that
these two steps could have been easily compressed into one:
“Now I actually have to go and search for this movie…And now I’m doing all
this again, where I have to enter my zip code, and this is like, oh, my god,
why couldn’t have I put my zip code and the movie title at the same time —
that’s one less webpage I have to visit, that’s one less loading time… “

LOGGING IN AND REGISTERING
One of the most common forms that people encounter on mobile devices is the login form,
where they are asked to enter a username and a password. We have observed many users
repeatedly trying to enter usernames and passwords, and failing to successfully do so.
Typing on a phone is hard, but passwords and usernames are even harder than regular
typing. Part of the reason is that passwords and usernames often contain a mixture of
upper-case and lower-case characters, as well as special characters. Accessing these kinds
of characters can be tricky even on powerful smartphones and touch phones. To add insult
to injury, passwords are masked — people cannot see what they typed and they cannot
check for mistakes.
64.Do not ask users to log in unless absolutely necessary for security reasons.
Many websites that implement authentication rather than security (that is, they want to
make sure that the users have the right to access their content — either because they
have paid for it before, or because they have registered before) lose business when they
ask users to log in on mobile devices, simply because, many times, logging in is so
painful that people give up. Consider seriously allowing people to access your content
without having to authenticate themselves.
65. When logging in must be done, consider letting users define a numerical
pin.
Sometimes users need to log in. If that is the case, one way to make it easy to enter a
password is to lessen the constraints normally imposed on passwords: if users only had
to enter 4 numerical characters, they would not have to juggle multiple keyboards and
the chance of making a mistake would be smaller.
PayPal allowed users to define a PIN to be used only to log in into their mobile app; so
did QVC (both on their mobile apps and on their website).
(a) Paypal app for iPhone (b) QVC
Pins as passwords.

Unfortunately, one of the disadvantages of defining a PIN (on top of a regular password)
is that users have to remember one more thing.
66.When logging in must be done, have an option that allows the user to see
the password in clear.
What makes it even harder to get passwords right is that users cannot see what they
type. There is no reason for masking passwords. The only argument for masking is that
someone else may be snooping over the shoulder and may easily read the password.
That problem has an easy fix: allow users to toggle between masking the password and
typing it in the clear — they can judge whether they have enough privacy to unmask the
password or not.
In fact, there is at least one circumstance where unmasking of the passwords is already
being done: setting up a wireless network on Android. Below is a screenshot:
Setting up a wireless network on Android. The password can be displayed in

clear.
67.When users need to create a password, tell them if the password has to
satisfy any constraints (e.g., number of letters in the password).
Progressive disclosure has its place in a variety of interface-design contexts, but it
should not be applied when instructing users how to create a password.

One of our users was trying to create an account in the Best Buy app. Unfortunately, the
registration form did not warn him that the password had to be at least 6 characters
long, so when he chose a shorter password he got an error and had to go back and
create another password. Not only did the user take an extra step, but he also had to
remember what the password format needed to be. If a password must be created on
mobile, it’s better to make the process as smooth and fast as possible.
Best Buy app for Android
Users were first told that they must create a 6-30 character password; after they had
typed their new password twice (!), they were also told that the password must
contain a number.

68.Do not require people to register or sign in on a mobile phone.
69.Always have a guest checkout option.
70.The guest checkout/skip registration option should always be the first

option displayed on the checkout page.
Users are annoyed at sites that make them register, especially if they think that they are
not going to use the site again. As one of our users put it:
“Another thing that gets me is registering on a thousand different websites. It

annoys me to no end, because you’re going there for very basic information,
so what’s the point?”
Registration incurs an extra interaction cost even on desktops; the cost is greater on
mobile devices, where typing can be tedious and every extra click takes a lot of extra
time.
Many websites require registration before making a purchase; this is what a user had to
say about it:
“I hate registering… I have to spend time on the site to register instead of

buying it. It’s simple enough, but I’ll never have to go back… It’s
frustrating...”
The website should offer the option of proceeding without registration or sign in as the
most salient option, since that is the option most likely to be chosen by users. Even
when users have an account with the site, they are unlikely to sign in on mobile, not
only because they hate typing in user names and passwords, but also because, most of
the time, they cannot remember their account information and they don’t have access to
the piece of paper or file where they’ve stored it.
This is what one of our users had to say about Walgreens’ mobile website:
“I like that they have an area for guest checkout, so that if you don’t have an
account with them you don’t have to create one, which is sometimes easier,
especially if you have (like I do) a bunch of accounts [..] I keep my
passwords on a piece of paper next to my computer.”
Note, however, that the Walgreens site first listed the “Register” and “Sign in” options.
Although this user noticed the guest checkout, we’ve witnessed countless situations
where people simply ignored that alternative because it was too low on the page and
they just clicked on the first button they saw.
Victoria’s Secret nicely allowed users to checkout without signing in on their mobile
website; they also placed that option first on the page, and, thus, made it the more
salient one.

(a) m.victoriassecret.com (b) m.walgreens.com
Both Victoria’s Secret and Walgreens allowed users to skip signing in. However,
Victoria’s Secret rightly made it the most salient choice by listing it first. Walgreens
listed the sign-in and registration options first.
71. Don’t ask users to log in or register (or enter extensive information)
before delivering any value to them.
Although a website can offer to users the option to register once they have entered a lot
of information about themselves, it should never ask for registration upfront, before
delivering any value to the user. Most people want immediate gratification, and they
need to be highly motivated and patient to want to work before seeing what they need
to work for. Apps and websites that ask people to register before offering any content
slam a door closed in front of the users: they don’t know if it’s worth opening it at that
point, and the work involved is considerable enough to not warrant the effort. Often
users simply want to try out the app and decide if it’s for them – they should be allowed
to do it without having to register.
Kindle asked users to register or log in right away, before showing them anything. Many
of our users were put off by the registration; some had Amazon accounts but did not
remember their passwords. Why not show them a few sample books right away to whet
their appetite and motivate them to create an account?

Rue La La, a flash-sale app, also required users to first log in before seeing any of the
products they offer. By contrast, Gilt, a similar flash-sale app, allowed users to see their
product and asks them to log in only when they want to add items to their cart.
(a) Amazon Kindle (b) Rue La La app for (c) Order Pizza for
app for Android iPhone Android
App apps required users to log in or sign up before seeing any content.
Even for companies such as Hulu and Netflix, which provide content only to subscribers, it
makes sense to show a preview of the content available: the quality of the content may
convince users that it’s worth signing up for the service (although they may do it at a later
time on their desktop).
Older versions of the Pizza Hut app also required registration before placing an order. A
more recent version rightly eliminated that “feature”, but, unfortunately, although users did
not need to register, they still had to work before being able to see the offerings. If they
chose delivery, they had to first enter the address of the delivery location. (If they had
chosen carryout, they still would have had to select a Pizza Hut location).

Pizza Hut for Android
Users did not have to register, but needed to enter a carryout address before placing
an order.
72.Whenever registration is an option on mobile, require only the minimum

information to create an account. Let users add extra information at later
times.
Redfin required users to enter only their name and email to create an account – it was
one of the most economical registration forms that we’ve seen. Most sites or apps asked
all sorts of questions that they are unlikely to use, starting from address and phone
number and ending with birth date, security question, or title. Even if that kind of
information might be useful, if it’s not essential – don’t include it. It’s better to ask users
at a later time (preferably on a desktop) to fill in that information. And, always, if you
ask for confidential information such as birth date or social security number, tell users
why you need it and how they may benefit by sharing it with you.

Redfin app for Android
Redfin had a simple, one-screen registration form that asked for a few pieces of
information

Pizza Hut asked users to fill in four screens of mandatory information, including birth
date, mobile number, security question, and consent to receive promotions.
One of our participants who had to register for an account with Pizza Hut using her iPhone
app confessed:

“I am not a fast typer on this [phone]… Oh, lord! Let’s just say – if I was at
home, I wouldn’t mind filling in all that stuff, but this seems like a lot to do.
[…] To be honest, these kind of fields – I am not really keen on entering on
my iPhone ‘cause I don’t like typing a lot. Date of birth? I hate using my date
of birth, I really don’t like giving that information out.”
73.Don’t ask users to confirm their registration through email.

Registering on mobile is a tedious process in and by itself. You don’t want to add any
extra hurdles for users by asking them to confirm their email. Not only does the email
confirmation increase the users’ work load, but it also disrupts their task flow: now they
have to go to a different app, read their email, click on a link in the email, and get taken
to a new Web page.
Big Oven users had to confirm their account by tapping a link received in an email. Once
they had clicked the link in the email, they were sent to the Web. Users who were trying
to use the Big Oven app had to find the app again, restart it, and log in with their new
credentials.

Big Oven app for Android
Big Oven required users to confirm their registration by clicking a link in an email
message. This process inserts takes extra steps and disrupts the task flow.
74.Be upfront about the benefits that registration brings to the users.
Whenever you ask users to register, tell them what advantages they get by doing so. If
there are features available only to registered members, tell them what they are. But
don’t mislead them into thinking they can get a feature by registering, only to find out
later that they need to pay a fee on top of the registration to get it.
When users tried to get calorie information for a recipe in Big Oven, they were shown a
login screen, which led them to believe that they could access that feature if they
registered. However, once they completed the painful registration process, they
discovered that a paid “pro” membership was needed to access the nutritional
information.

After registering
and logging in
Big Oven app for Android
Misleading users into registering: Big Oven asked users to register to access caloric
information, but then informed them that they need a paid “pro” membership.

SEARCH
People use search for a variety of reasons: to find a particular piece of content, to navigate
(if the site’s navigation structure is not transparent enough), or even to narrow down
browsing. Search is generally useful and should be included on any website.
However, for mobile websites in particular, a search box takes space and grabs user’s
attention, potentially derailing it from other tasks. For searchers (that is, for users who are
looking for a particular fact), a search box is exactly what they need. The cost of not having
a search box is really high for searchers: to find an answer to their problem, they will need
to browse through many pages and spend a lot more time in the absence of a search box.
On the other hand, for browsers (that is, for people who do not have a specific goal in
mind), the search box can take the place of more valuable content. Hence, browsers
actually pay a small cost each time the search box is included on the page.
Thus, the issue of whether to include a search box on a mobile site and how salient this
search box should be is a little tricky. The answer should take into account the types of
tasks that are typically done on the site: how many of those are browsing tasks and how
many of them are searching tasks. If the majority of the tasks are search-related, then
include a search box. Otherwise, if most of your tasks are some form of browsing, consider
including a search box and possibly making it less salient. We do not recommend
completely eliminating the search box unless the screen is really small. The reason is that,
even if your users are mostly browsers, if you have a few occasional searchers, they will pay
a really high cost if they won’t be able to use a search box.
75. Include a search box on your mobile website or in your app.
76.If your users are mostly browsers, consider making the search box less
salient by placing it at the bottom of the page.
News sites or apps such as CNN and BBC have mostly browsers among their users.
Thus, on the Web, CNN chose to put their search box at the bottom of the page. BBC
took a more extreme approach (which we do not recommend for phones with larger
screens) and did not have a search box on their site. This approach is begging for users
to turn to Google and leave the site.

(a) m.bbc.co.uk (b) m.cnn.com
Different approaches regarding the search box on browsing sites. (a) BBC did not
have a search box on its website. (b) CNN had a mobile site at the bottom of the
page.

77.Put the search box at the top of your screen unless your users are mostly
browsers.
If a user is in search mode, they need to find the search box fast to be able to input a
search query. One of our users was searching for information about the company
Autodesk on CNN Money’s website; the search box on that site was at the bottom of the
page. This placement is appropriate for that website, since it is primarily a browsing site.
However, for this searcher, it was quite tedious to scroll through an entire page of
articles in order to find the search box (many people may give up if they scroll for a
while and do not find what they want). She was able to find it and use it, but
unfortunately the search did not return a satisfactory result. So she hit the back button
and, in order to modify the search, she had to scroll again through the entire screen to
get to the search box. This example shows the cost that is incurred to the searchers
when the search box is not immediately available.
78.The length of the search box should be the largest possible size that will fit
on the screen.
This guideline replicates the more general one (see 49) for sizing textboxes in forms.
Refer to the discussion for that guideline.
79.Preserve search strings between searches. Use auto-completion and

suggestions.
This guideline is a search version of the more general guideline for typing (44), which
suggest giving users history-based defaults to minimize typing.
80.Do not use several search boxes with different functionalities on the same
page.
We often see mobile users become disoriented and lose sense of context. When there
are multiple search boxes, each of them implementing a different type of search, users
may confuse one with the other. First, they may not even see all the search boxes at a
time, and second, they may not read carefully the descriptions of any of them.
In the example below, CNN Money used two different search boxes with different
functionalities: one box was for searching stock quotes by ticker symbol, another box
was for free-text searching within their articles (see figure below). The multiple search
boxes were confusing for the users. For instance, one of our users was searching for the
trading value of Autodesk, and he entered the company name “Autodesk” in the search-
by-symbol search box. He did not get any result (because the website wanted a symbol
in that search box, rather than a company name, and was very inflexible about it), so he
tried again searching within the search-by-keyword box at the bottom of the page. The
new search resulted in a bunch of articles about Autodesk, which confused the user and
made him skim through text in order to possibly find some indication of the stock value.
Contrast that design with an older variant of Flickr, where people could enter the search
string in the same search box, and then press one of two different buttons to indicate if
they wanted to search within photo tags or within text descriptions.

(a) CNNmoney.mobi (b) m.flickr.com (older)
(a) CNN Money used two different search boxes for different types of search:
one for stocks by company symbol, and one for search within their articles. Users
were confused by the purpose of each of the search boxes. (b) Flickr used a single
search box, but it allowed users to specify whether they wanted to search by tag
or by the text associated to a picture. This solution was less confusing for the
users, assuming that they understood the distinction between the two types of
information 17.
81.If the search returns zero results, offer some alternative searches or a link
to the search results on the full page.
When there are no results for a search, it is often because of a typo in the search query.
Whereas the user needs to be informed of the failure of their search, the website can
save him the cost of revising the search, by offering results to alternative searches that
partially match the initial query. Moreover, if you have reasons to expect that the
search results to the same query be different on your full site, offer a link to the search
results on the full site (sometimes, perhaps the user is looking for one of those features
of your site that you have decided not to support on mobile).
In the CNN Money example that we discussed before, the user had entered the company
name (“Autodesk”) in the search-by-symbol box and obtained zero search results. No
alternatives were offered. Ideally, in that situation, zero search results should have
triggered a search by name.
17
In fact, more recent versions of flickr’s mobile page have eliminated the distinction
between text and tags.

(a) cnnmoney.mobi (b) m.consumerreports.com
(a) Our participant’s search for Autodesk’s stock value returned zero
results on CNN Money (since the website was expecting in its search box a
stock symbol rather than a company name). The site did not offer any
search suggestions or alternatives. (b) Consumer Reports did offer some
(inappropriate) alternatives for a search that returned zero results.
On New York Times’ mobile site, a search for “Amelie” returned zero results. However,
the search was done, by default, over articles from the past 30 days. Expanding that
search to a larger period or linking to the full-site search results would have been a
better solution. (Note that their implementation also contradicts one of our strategy
guidelines about the content that should be included on mobile – see guideline 14).

(a) m.nytimes.com (b) nytimes.com (full site)
(a) The search for “Amelie” on NYT’s mobile site returned zero results in the past
30 days. The site could have linked to results from the past 6 months or to the
results from the full site (b). (b). The full site has one search result to the same
query.
One of our participants was attempting to search for a car using the Edmunds
application. Unfortunately the feature combination that he chose led to no search
results; in spite of his attempts to tweak the features, the search still returned no
results, leading the user to believe that the app was not working.

Edmunds app for Android
Our participant was confused when she could not find any cars repeatedly. The app did
not help her change the search parameters so she would get some results.
LISTS AND SCROLLING
82. On the Web, all the items on a list should go on the same page if they are
text only. (This guideline is valid for apps, too, if the list is generated by
making a request to a server.)
83. List of items that include images should be split into multiple pages (we
recommend between 20-30 items per page).
Text items usually do not require much time to load, so having many items on a page
will not slow down significantly the loading of the page. Users are willing to scroll down a
list as long as they have some sense of how far along they are and how much more
work they have to do. For instance, in a list sorted alphabetically, at any point people
can tell whether the item they are looking for is before or after that point in the list.
Moreover, they can get a rough estimate of how much more they need to scroll in order
to get to the item that they are looking for.
One of our users who was searching for the movie “Slumdog millionaire” was frustrated
with the Fandango movie site because it only listed their top picks, rather than the
entire list of movies:
“If this is going to be a mobile site, I don’t want their top five picks, I want all
the movies instantly because there’s not going to be a lot of connectivity… On

a mobile website why would you just put 5 movies, that’s almost dumb to me
… Like ‘Fandango movie picks’ — I don’t care what Fandango thinks … I’m not
going to this movie site to just ask ‘oh, what movies are out there’, I mean,
some people may be, but I’m personally not … Now I actually have to go and
search for this movie… “
m.Expedia.com
All flights that match a user query were displayed on the same page.
On the other side, in the interest of speed, if list items are big in size and, thus, slow to
download (e.g., images), we recommend splitting the list into pages. The examples
below show Walmart and Flickr split their list of products, respectively photographs into
pages of 30, respectively 20 items. Note that Walmart appended the new products at
the end of the list (rather than on a new page). Splitting the lists into chunks that are
loaded when the user requests them, but are all displayed on a single page is
acceptable, as long as the user is not taken to the beginning of the page for each new
download.

mobile.walmart.com
To avoild long waiting times, only 30 products were loaded at a time. After selecting
View 30 More Products, new products were appended at the end of the list.
m.flickr.com
Search results containing images were split into multiple pages.

84.If a list of items can be sorted according to different criteria, provide the
option to sort that list according to all those criteria.
The example below shows the mobile site of ABC.com. To find a particular show, users
had to scroll down a list of shows ordered alphabetically. Our users were able to easily
find the show “Lost” (which was one of the tasks we designed for one of our usability
studies), by scrolling down the list and looking for the letter “L”. Compare this list with
the one on TVGuide. In this case, our users were looking for a movie that starts at 8pm.
There was no way for them to know which of these listings was a movie, so they had to
scroll down the list (which was ordered according to channel — you could see what was
playing on every channel at a given time) and guess whether any of the particular
entries was a movie. The task was highly frustrating for the users. The reason the
TVGuide list did not work well was because it was not sorted in an order that matched
the user’s task (instead, it was sorted by hour). Note however, that, if the tasks were
different (e.g., find a movie on the ABC website and find what’s on channel 5 at 8pm)
the results could have been reversed, since the order on the ABC website did not
indicate the type of show, and the TV guide was, indeed, sorted by channel.
To do justice to TVGuide, all programs playing on all channels (from 2 to 3954) are
listed on a single page (as they are all text items).
(a) m.abc.com (b) TVGuide app for Android
(a) Alphabetically sorted shows worked well for users looking for the show
“Lost”, but might not work for users looking for shows in a particular
category (e.g., comedy). (b) The TVGuide contained a list of programs
sorted according to channel; this sorting is not natural to a user who is
looking for a particular show, but may work for somebody who wants to
know what’s playing on a given channel.

These examples show that, if there are many ways to sort the same list, for certain
users and tasks, the list will be sorted in the wrong way. That is why it’s really
important to provide the user with the capability to sort the list after different criteria.
One of our users wanted to find out whether a flight from Munich to London was on
time, but she did not have the number of the flight or the exact time. She looked
through the list of arrivals at London Heathrow Airport, but the list was sorted by
scheduled time of arrival rather than by name of the origin airport. Unfortunately, there
was no way to sort the list differently, so she had to go through every flight to find the
city she was interested in.
mobile.lufthansa.com
Lufthansa did not allow sorting the list of arrivals according to the departure
airport.
Sometimes sorting does not solve the problem. Especially when the results are
numerous, it is essential to provide a mechanism for filtering them.
85.If a list contains items that belong to different categories, provide filters to
narrow down the number of elements.
Filtering limits the number of items that users need to inspect to a subset that are
interesting to them.

Our TVGuide users would have benefited if they had been able to filter through the
listings and select the movies. One participant spent about 7 minutes searching for a
movie starting at 8pm so he could watch it with a friend:
“These are, I know, not movies. Since I didn’t see a way to filter it, this is I
guess what I have to do… [go through every listing]. See if I can go through
help. I hope to find some more filtering… [After reading the help] The help
was worthless, so I guess I’ll continue …[He goes through more listings.] This
seems like a real pain … I’m still in the 8th hour. To have to go through all
this, and then to have to hit 9 [hours] and 10 [hours]– I’d just tell her ‘don’t
come’…”
On Schuh’s website (a UK shoe store), it was possible to see a list of products on sale,
but not to filter them by size. Users were frustrated when they clicked through several
pairs of shoes, only to discover that their size was not available.
(a) schuh.mobi (no longer available) (b) Schuh.mobi (no longer available)
(a) Users of Schuh could not filter the shoes on sale by size, although they
could sort them by a variety of criteria. (b) Users had to click to the product
page, and then click on Choose a size, to discover whether their size was in
stock.
A UK user described the problem with the Schuh website:
“I’m going to have to go into each shoe to see if they have my size… It’d be
nicer to filter by size. A lot of other online companies do that. I’d give up…”

A user was trying to find out if the tennis player Amelie Mauresmo had been eliminated
from a tournament. The ESPN website allowed filtering by tournament day, but not by
player:
“What was interesting about that — I think it should have been a search part
where you could have typed in Amelie Mauresmo’s name in there, […] rather
than having to scroll through everything, ‘cause, you see, here where it says
Women’s Singles I actually had to use common sense and go back [through
dates — January] 26, 25, 24, and finally found it; there may have been a
quicker way, but I couldn’t find it at all — there should be a search bar , type
in her name and it will take you directly to this.”
m.espn.com
The user needed to check all tournament dates to find information about a
particular player on ESPN’s website. There was no way to filter by player.
Another participant was searching for a pair of women’s comfort shoes on Zappos’
mobile site. She didn’t have any brand in mind, so she entered the query “women’s
comfort shoes”. She thought she got too many results (and many inappropriate), so she
further refined her query to “women’s comfort shoes size 9 wide”. Unfortunately, the
second query yielded no results. Even if she had noticed the “Sort Your Results” option
at the top of the screen, she would not have been able to get to the shoes available in
her size.

iphone.zappos.com
Although users could sort search results by popularity, name, price, and how
new they were, Zappos did not permit users to filter results by shoe size.
86. Place the sort/filter options before the search results. If extended space
is needed for the sort/filter options, either use an expandable menu or
place them at the bottom of the page, but use jump links from the top of
the page to the bottom.
One of the problems with having a lot of filter and sort options is that they take up
precious screen space: instead of seeing the list items, users see the filtering options. A
solution is to use jump links to a section at the bottom of the page where the filtering
options are displayed.
Amazon implemented exactly this solution on their website 18. Note that the link “Filter
Results” was placed just above the list of results (in a position that is salient, as well as
consistent with the expectations created by the full Web).
18
Interestingly, the Amazon app did not provide a mechanism for filtering, whereas the
website did.

m.amazon.com
Jump links were used to take users to the filtering section, at the bottom of the same
page.
Another solution that saves up space is to use menus for the filtering/sorting options. This
solution is exemplified by Best Buy:

m.bestbuy.com
Filters were hidden in a menu on Best Buy’s website.
J.C. Penney chose to expose filters right away, on top of the search results.
Unfortunately, that was not a good choice, since the filters occupied precious real estate
(whether users needed them or not), taking away space from the results.

J.C. Penney app for Android
Filters took too much space on the results page.
87.When narrowing down results, show facets and number of items in each
category.
Being proactive and telling users how many items are in a given category can help them
decide which category to choose next. On the mobile Web, where every click counts, it’s
especially important to let users know what to expect when selecting a category.
Moreover, if a category contains no items, seeing that can save users an extra click.

(a) m.amazon.com (b) mobile.walmart.com
The number of elements in each facet was shown to users, so they know what to
expect when selecting any given category.
88. When users have narrowed down a list, indicate the selected filter or sort
criteria.
Mobile usage is often interrupted: users need to respond all the time to other stimuli
from the environment. Because of that, it should be easy for people to recover state
when they come back to an app or website after an interruption. In the context of filters
and search, that means showing what selections users have made so far. (This will
benefit people even when there are no interruptions: they won’t have to keep their
selections into their short-term memory any more if they can see them on the screen).
Staples allowed users to filter a list of products according to many criteria. They nicely
indicated the facets and the number of items available in each. But, unfortunately, once
a user selected a category, they did not show it anymore (see example below) – users
had to keep track of the category by themselves.

(a) (b)
m.staples.com
(a) Results for the query “paper”. (b) Results after narrowing down to “laser
paper”. The page does not show what filters were selected.
(a) m.nordstrom.com (b) m.amazon.com
Both Nordstrom (a) and Amazon (b) showed the selected filters. However, note
that on Nordstrom’s page, the “filter” and “nearby” buttons, as well as the many
sorting criteria underneath, took up precious space, pushing the results below the
fold. Amazon’s implementation was much more economical.

89.If the list contains only one item, take the user directly to that item.
When a list contains only one item, spare the user the trouble of clicking on that item
and take him directly to the entry corresponding to that item. In the example below, the
Moviefone website returned a single search result for “Revolutionary road”; the user
could be taken directly to that item. This shortcut is especially useful for mobile devices,
where every extra click means waiting for an extra page to download.
m.aol.com/moviefone
Search returns only one result on the Moviefone site; in that case, to save time
and clicks, the user could be taken directly to the page corresponding to that
result.
90.In a long list organized alphabetically, allow users to easily jump to a

certain letter.
Both the Zappos app and their mobile website contained long lists of brands offered;
both the app and the website let users get to the brands that start with a certain letter.
However, whereas the process was very simple and transparent on the website (users
could just select the corresponding letter), it was much less clear in the app, where they
had to scroll down through a long list or they could use a scroll cursor on the left that
allowed them to move to a letter. Unfortunately, our users missed the significance of the
icon on the left and thought they had to sequentially scroll through all the brands.

(a) m.zappos.com (b) Zappos app for Android
Filtering by initial letter: (a) The mobile website for Zappos had a standard filtering by
letter for brands. (b) Their mobile app allowed users to scroll faster using a special
cursor on the right. When users got to a new letter, the letter was displayed briefly in
the middle of the screen. Both the cursor and the letter disappeared when the user is
not scrolling. Users did not discover the cursor and had to scroll sequentially through
all the brands.
91. Do not use a deck-of-cards model (i.e., one item per page) for lists.
Often, when users interact with lists, their goal is to select one element that matches
their needs. Many of the lists elements can be filtered out without close inspection.
Representing one item per page (besides being completely wasteful for the Web, as it
forces the user to click many times to get only small pieces of information) forces the
user to inspect each item individually, in a fixed order. The items late in the list get
fewer chances to be seen (although they may match users’ needs better), simply
because the users may get tired.
An example of application that inappropriately uses this model is Epicurious. When users
search for a recipe, they never get a chance to see a list with all the results; instead,
they need to go through individual results one by one.

Epicurious app for Android
The list of results for a “cauliflower parmesan” recipe search was spread over 18
pages, with one result per page. Users had to go through all the pages sequentially.
This is a quote from a participant interacting with Epicurious:

“I am not too excited to have to go through every [recipe]… I wish they had a
list that said ‘this and this and this and this’ and then I can hit that… because
I don’t need to see pictures of them and all that, I’d rather read the list […],
because this is 907 recipes. I am not going to go through 907 recipes! So I
don’t know what 907 is, but I’ll never see it. In fact I’ll probably not even see
20.”
NAVIGATION
Many mobile websites have transformed their homepages into navigation hubs; these
homepages are just a set of links to various sections of the website. This approach works
particularly well for sites geared towards searchers (that is, people who look for specific
facts on your website — e.g., to check flight status, to find out shipping cost).
The examples below show examples of mobile homepages designed as navigation hubs:
they contain only a set of navigation links. These links typically correspond to tasks that
users can do on the website. (In the case of e-commerce sites, they may be about different
kinds of products instead of different tasks).

(a) m.sears.com (b) m.thetrainline.com
(c) m.ca.gov (d) mobile.United.com
Homepages as navigation hubs.

In the case of browsing sites, new content needs priority. Thus, these sites typically give
less salience to navigation, favoring information that is likely to satisfy browsers. Many of
these sites settle for a desktop-style top-navigation bar.
(a) m.huffingtonpost.com (b) m.washingtonpost.com
(c) m.sfgate.com (d) m.tmz.com
Top navigation bars on browsing sites.

92. Include navigation on the homepage of your mobile website.
As users come to your website with different goals in mind and access your site from
different sources, it is important that they easily find their way around. Navigation on
the homepage is standard on any full site, and should be the same on mobile. However,
due to the small screen, for the same reasons we have detailed when discussing the
placement of the search box, some extra considerations need to be taken when placing
the navigation options:
93. On homepages of browsing sites, give priority to new content over

navigation links.
When users come to a browsing site, they are likely to look around for new content. If
your homepage only contains a set of navigation options, users will have to do extra
work to get to new content. That is why we recommend that you make the new content
highly salient, and, if space allows, also add navigation options at the top or over the
fold.
Ideally, if space is not an issue, on browsing sites navigation links should be both at the
top and at the bottom of the homepage. From desktop studies, we know that when
people come to a news-like website, their eyes scroll down the page, then they scroll up,
and then, finally, they decide where to click. That kind of pattern works well with
navigation options placed at the top of the page.
On mobile sites, scrolling is often painful. Given that browsers rarely go for the
navigation options before inspecting the page, one idea to minimize the scrolling cost is
to put navigation at the bottom of the page: people would look over new content, scroll
down, and then, when they get at the bottom they could navigate directly, rather than
scrolling back to the top of the page to select a navigation option. Unfortunately, that
approach does not work well with long pages, where users have to scroll a lot: many of
the users in our study never scrolled down to the bottom of the page.
So, although putting navigation at the bottom of the page follows our guideline for
giving priority to new content on a browsing site, we recommend using that option only
if users do not have to scroll a lot (1–2 screens should be ok) to get to the navigation
options.
On the NBA’s webpage, the navigation was at the bottom of the page; on ESPN’s
Blackberry page, navigation was at the top, next to new content. At the bottom of the
ESPN page, a jump link “Back To Top” allowed users to skip the scrolling if they needed
to get to the navigation list.

««
(a) m.NBA.com (b) m.ESPN.com for Blackberry

(older)
(a) Navigation at the bottom of the page; (b) Navigation at the top of the page.
The touch-phone version of ESPN had a navigation menu at the top. However, as we
discussed before when we talked about menus (guideline 52), the danger of using an
expandable menu is that people may ignore the links inside the menu. One of our users
was looking for NBA scores on the iPhone version of ESPN and he paid no attention to
the menu button on the right:
“Ok, where does it say basketball? Usually it says basketball here…

Interesting, ‘cause usually, if you go to ESPN.com, it gives you choices… [He
scrolls down] oh, here it is, NBA…”

m.espn.go.com
ESPN on iPhone: Navigation was hidden under a menu.
m.usatoday.com
USA Today also used a menu for the different news categories. However,
the name of the menu “Sections” was more transparent than the icon used
by ESPN above.

94.Include at a link to navigation on every page of your mobile website.
Users may land on one of your pages via a search engine or they may get there from
another page on your website. In both cases it is useful to give them a way to navigate
away from that page to another section of your website. However, having the navigation
structure of your webpage repeated on every page can be too space-consuming on a
mobile screen, especially if you have many possible navigation options.
A solution is to include a link to your navigation options instead of the full navigation
structure. This link can be the same with the link to your homepage (and, if you have a
clickable logo, it’s enough to include it on every page).
In the examples below, navigation links were included on every page. ABC included
links to the navigation structure on the homepage by having a logo present on every
page, as well as a Home button. On United’s pages, the links at the bottom of the page
were shortcuts to the most frequent tasks; a pointer to the homepage (which contained
all the navigation options) was also present.
(a) m.abc.com (b) mobile.united.com
Navigation included on every page. On ABC’s website, navigation was a link to

Home (containing the full navigation options). On United, the most used
navigation links and a link back to “Home” were present at the bottom of each
page.

The other solution, more appropriate for browsing sites, is to follow the pattern
encountered on full websites and list a navigation bar on every page of the site. A
challenge of this option on touch screens is to make sure that the options in the
navigation bar are big enough and that users can select them reliably.
(a) m.target.com: homepage (b) m.target.com: internal page
On Target’s webpage, the navigation bar at the top was included on every page.
95.Avoid deep hierarchies on mobile.

Whereas deep navigation hierarchies are usually implemented through a succession of
menus on the full Web, on mobile they typically translate in many successive pages
where people have to select among many successive subcategories. Unfortunately, a
deep hierarchy often depletes users’ patience: they have to click again and again (often,
waiting for the page to load between clicks) before they get to real product or item of
interest.
Although the full site hierarchy may be (appropriately) deep, we recommend flattening it
for mobile to avoid too many clicks and wait times.
An older version of Walmart’s mobile site used to suffer from exactly this problem: users
looking for, say, toys had to click approximately 5 times before they could see a picture
of a product: they had to select “Top rated and best sellers”, “Top rated”, “Toys”,
“Outdoor toys”, “Playhouses”. Luckily, Walmart realized that this hierarchy was too
deep and compressed it to only two steps. We show here both the older variant of
Walmart and the newer redesign.

mobile.walmart.com (older)
Walmart used a deep product hierarchy: users had to click many times before seeing a
product.

mobile.walmart.com (newer)
A redesign of Walmart dropped many of the subcategories under “Toys”, getting

users faster to products.
Unfortunately, there are still many e-commerce sites that suffer from an inflation of
mobile information architecture (Target and Walgreens are two examples). We don’t
recommend getting rid of categories: they can still be useful when people try to narrow
down the available selections. However, with clicks so expensive, it’s important to follow
the principle of immediate gratification on mobile: show content (rather than site
navigation) as soon as possible.

m.target.com
Target also required users to navigate through a deep hierarchy to see actual
product listings.
96.Use breadcrumbs on sites with a deep navigation structure (many

navigation branches). Do not use breadcrumbs on sites with shallow
navigation structures.
Breadcrumbs have the disadvantage of occupying expensive space on a small screen;
therefore we recommend not using them unless truly necessary. Sites with a deep
navigation structure (many navigation levels, with many options at each level) can
benefit from breadcrumbs — classical examples are forum hierarchies. For sites with a
shallow navigation structure (few navigation levels with one or two options at each
level), the cost of the breadcrumbs – in terms of the space that they occupy on the
screen – overwhelms their benefit.
Although we don’t recommend using deep hierarchies, sites that do use them – like
Target and Walmart, discussed in the previous example– need to also make sure that
they show the current path that the user has chosen. Note that Target did not have
breadcrumbs, but Walmart did (see the examples discussed under guideline 95).
On the BBC website, the use of breadcrumbs was unwarranted: both BBC Home and
BBC Sport breadcrumbs duplicated logos already existent on the page. There were too
few navigation layers on the BBC website to justify breadcrumbs.

m.BBC.co.uk
Inappropriate use of breadcrumbs: the information tree was not deep enough to
warrant the usage of breadcrumbs, plus the breadcrumbs duplicated
information already existing on the page.
97.Place together links that are related to the same topic.

Users expect that similar links on the Web be grouped together. The kinds of links that
they see give them an idea of what to expect. If in a list they saw “Peppers”,
“Tomatoes”, “Cucumbers”, etc., they would expect other vegetables to be in the same
list, rather than on a completely different page.
My TSA, an app that shows airport-related information, displayed current flight delays at
airports across USA, as well as more general flight statistics for the last year (how many
flights landed on time, etc.). If one needed to find airport delay statistics for an airport,
say Chicago O’Hare, one had to first make that airport their default airport, and then go
under the More tab (on the iPhone app). There, the option On-time performance led the
user to the corresponding statistics.
What was the problem with this task flow? Hiding airport-related content under More
was unexpected. Indeed, all the other options in the tab bar pointed to different kinds of
information that were not related to the current airport, misleading users into believing
that the More tab wouldn’t be associated to it, either. The information about the

current airport was all on the home page, and so it would have been better to have all
those airport statistics on the same page.
MyTSA app for iPhone
The More tab hides items that were contextual. Specifically, Wait Times, Current
Weather, and On-Time Performance all pertain to the airport displayed on the main
page. If users want to see these data for a different airport, they have to go back
on the main page, change the airport, then go to the More tab and find all those
stats.
CONTENT
Even more than on the Web, on mobile devices people rarely read all the text on a page.
Especially if they are in searcher mode (that is, they are searching for specific information),
they only skim through the text, looking for what they need. On mobile devices, it is crucial
to follow the guidelines for content usability for the Web.
98.Use formatting and concise writing for quick reading.

Use bullet points and short sentences in order to allow users to quickly select the
information that is relevant to them.
One user complained about the text next to a checkbox on Interflora’s website:
“These [checkboxes] are annoying because sometimes you read them, and
you have to read it because you don’t know if it’s going to be ‘tick this box if
you don’t want this crap sent to you’ […] [reading] So they’d like to send you
some special offers … ‘if you’d prefer not to receive these offers, tick here’ —
right, I can stop reading it at that point, but I still had to read it… It should
have a title “Would you like to receive offers?” or even “Offers?” and then
underneath the full lengthy blurb …”

m.Interflora.co.uk
The text next to the checkbox was too lengthy and roundabout, and did not
allow users to scan it quickly.
In the example below, the formatting on this Big Oven page was so bad that
it’s hard to imagine someone following this recipe:

(a) Big Oven app for Android (b) Jaime Oliver’s 20 Min Meals for
iPhone
Recipe formatting: (a) The steps in this recipe were hard to read and follow, as
it wasn’t clear where on the page the next step is. (b) The second app showed
much better formatting: the paragraphs were short and the different steps were
easy to locate.
On ABC’s website, a summary for an episode from one of their shows was center-aligned
and hard to read. Center-aligned text causes difficulty on computer screens, as well as
on smartphone screens, because users have to find the beginning of the text each time
they go to a new line. Left-aligned paragraphs are more predictive and pose a smaller
cognitive burden.

m.abc.com
The episode recap is center-aligned, and thus harder to read.
99. Avoid splitting articles in many pages.

In guideline 82 we discuss why long list with textual elements should go on a single
page. Same holds true for long text articles on the mobile Web: it’s better to show them
on a single long page than to split them in many small pages, to minimize the load time
between pages. If the articles contain many images, it’s ok to have the images as a
separate feature (e.g., associated slideshow).
On NBC’s mobile page, an episode recap from “Days of Our Lives” was split into 41
pages. Each page contained a big picture and one paragraph of text. It would have been
better to fit all the text and 1-2 pictures on a single page, and then include a link to
additional pictures.

m.nbc.com
The episode summary wa split into several short pages.
100. If an article spans several pages, use pagination at the bottom. Have a
link to each individual page, rather than just to the previous and the next
ones.
In guideline 99 we recommend showing articles on a single page by default. If, for some
reason, you must absolutely split an article into several pages, make sure you allow
users to access any one of the pages directly. Although most users navigate through an
article sequentially, there are cases when users want to be able to go back quickly to the
beginning of the article (to check author information, for instance), or even to different
points in the article. Allowing them to go only to the previous and next page will slow
the task substantially on a mobile phone, when each page takes seconds to load.
One of our previous examples was that of an NBC article spanning 41 pages.
Unfortunately, if users wanted to go back to the initial page, they had to navigate
through all the pages again — there were no individual links to the pages.

m.nbc.com
At the end of a 41-page story, there was no way to go to the first page unless you
clicked through the previous pages one by one.
101. Stay away from jargon and industry-specific terminology.

This is a guideline that is valid for websites in general, and stays even more valid on
mobile, where people don’t necessarily have the time to investigate unknown words.
My TSA app used big icons with the digits “3”, “1”, “1”, to explain the travelers the 3-1-1
rule referring to what liquids can be brought in a carry-on on board of an airplane (3.4
oz. containers that must fit into a 1-quart plastic bag; a passenger is allowed only one
bag). Most of our participants did not understand what these icons meant and, although
they quickly scanned the explanatory text next to the icons, they never got what the
connection between the digits and the rules was: they simply did not have the time to
make that inference.

My TSA app for iPhone
Our participants never understood what the 3-1-1 rule was and what connection there
was between the big icons and what they were supposed to bring on the plane.
102. Do not use horizontal scrolling on mobile websites.

Horizontal scrolling can be especially annoying during reading, because people need to
move back and forth to the beginning and end of the line, and scroll each time they do
so. Luckily, most mobile websites make the information on the screen fit the screen size.
However, occasionally, we get sites where people have to scroll horizontally in order to
read information. Make sure that the information on the screen can be read comfortably,
without the users needing to zoom in, since, when people zoom in, they end up having
to use horizontal scrolling.
The examples below show two UK websites (TVGuide and The Trainline). The websites
used fonts that were too small for the touch screen. Users had to zoom in and use
horizontal scrolling in order to read all the information on the page.

(a) TVGuide.co.uk/mobile (b) m.thetrainline.com (zoomed in)
Horizontal scrolling. Users needed to use horizontal scrolling to read text on these
two websites – either by (a) design, or (b) because the fonts were too small and
need to be increased for the page to be readable.
Horizontal scrolling can be especially damaging when the user needs to access
information on both sides of the screen at the same time.
103. Use links with good information scent (that is, links which clearly
indicate where they take the users) on your mobile pages.
This guideline is a classic website-design guideline, but it becomes even more important
on mobile devices, where every extra click delays the user significantly. The text of the
links should be transparent and set good expectations about the content of the page.
Meaningless links suck as Next Article or Previous Article on CNN’s website (below) may
be easy to generate automatically, but are too vague — the links should contain a
description of what the story is about.

(a) m.cnn.com (older) (b) m.cnn.com
Links such as Previous Article and Next Article had no information scent.
Instead of using generic links, it’s better to show the titles of the other articles in the
same section, like Time and New York Times did (see below).

mobile.time.com m.nytimes.com
Good information-scent links to other similar articles.
104. Use links to related content to help the user navigate more quickly
between similar topics.
Well-chosen related-content links can be a major way of navigation and of keeping the
user on your website. On mobile, they also can save extra clicks back to a “headline-
only” page: users can directly select another article from the current page.

(a) YouTube app for Android (b) m.bbc.co.uk
Related content suggested for two different types of content: videos and news.
105. On browsing sites, new content should be given priority. Users should
not have to scroll to get to new content.
When the user has clicked on a new story, they expect immediate gratification, and they
shouldn’t have to work to get to new content; rather, they should get it immediately.
Therefore, information should not be repeated from one page to another.
One participant was using the BBC News application for Windows Phone 7. He noted that
one of the things he didn’t like about the app was that, when you clicked on a headline,
it repeated a “brief” that had been already included on the headline page. The user
thought that was “a waste of space.” To read the article, the user had to click one more
link on the “brief” page. Here are some screenshots from the recording of that session:

BBC News app for Windows Phone 7
The headline page contained the article title plus a summary. When clicking on the
article, the same summary was shown once more. Users had to click on Full story at
the top to actually read the article.
On Oprah’s mobile website, a list of favorite books presented each book on a separate page.
Each of these pages started with exactly the same text – an introduction to that article. One
of our users was confused, wondering if it’s the same book over and over again. This is how
the different pages in that article appeared on her Blackberry:

m.oprah.com
Every page of an article featuring book recommendations started with the same
paragraph.
There are many things wrong with this design, contradicting many of our guidelines:
first, a list should not be displayed in a deck-of-cards format (see guideline 91).
Second, the links from one book to the next have no information scent (“Next” and
“Previous” at the bottom of the page – see guideline 103). The pictures are too big and

they don’t fit on a single screen (see guideline 118). Finally, the depiction of the book is
quite bad: the author, number of pages and description are all crowded together in a
single, poorly-formatted paragraph (see guideline 98).
106. Use true article summaries on the headline page. Do not use the first
few sentences of the article.
Many websites that contain news stories or other articles have a headline page that
enumerates the articles. Sometimes this page also includes a short summary for each
article. The summary is highly beneficial to users, as they can get a better
understanding of what the story is about and of whether it’s worthy of their click.
However, sometimes sites cheat, and instead of presenting a true summary of the
article, they show the first few sentences of the article. We recommend against that,
simply because that means repeating information: users will have to look again at those
first sentences when they click on the article link and see the whole article in front of
them.
On Financial Times’ web app for iPhone, each headline had a summary. When users
clicked on the headline, they were taken to the story; the story did not start by
repeating the information in the summary.
Financial Times web app for iPhone (app.ft.com)
Each news story had a “true” summary, rather than just containing the first few
sentences of the article. Users were spared from reading the same thing twice.

Compare the Financial Times web app with USA Today’s app. The latter app showed an
incomplete sentence below each headline; that sentence often was the same as the first
sentence in the article.
USA Today app for Android
The same content was repeated on the headline page and on the article page.
107. Use complete sentences in headlines and summaries.
108. Don’t truncate product information in lists of products.

In the USA Today example above, we’ve seen that the sentences on the headline page
were truncated, presumably in order to entice users to read more of the article.
Unfortunately, that’s rarely the case. Truncated sentences mean impaired information
scent – if the sentence is incomplete, it’s going to be harder to tell what the article is
about. And unfortunately people use information scent to guide themselves on the Web
and decide what they want to read. It’s better to give users an accurate, quick
impression of the topic of the article than to run the risk of having that story ignored.
The same argument equally applies to headlines of articles. Headlines are even more
important than summaries: as people quickly scan a mobile page, they are more likely
to look at the headlines than at the summaries. Thus, it’s even more crucial to have

headlines with strong information scent. That means good choice of words, and also
complete sentences.
News and Weather app for Android
The headlines were incomplete, making it harder to understand what the story is
about.
This type of logic works in general for situations where people must choose among a set
of available links. For instance, if they need to pick a product, it’s important that they
see the full name of the product, rather than a truncated one that may leave out
relevant information.

(a) m.interflora.co.uk (b) IMDb app for Android
(a) The bouquet description was truncated. (b) Movie titles were truncated.
Incomplete descriptions of an item in a list make it harder for users to know what
the item is.
109. For content that changes often (e.g., news headlines), show when it has
been last updated.
You don’t want users to read old data as new. Make sure that people know when your
content has been last updated.
110. Change the date of the last update only after all content has been
completely updated.
An older version of the New York Times app used to change first the date of the last
update, and only after changing the date it started downloading new content.
Unfortunately, that was utterly confusing because users would stare in disbelief at three-
days old news that was listed as today’s news. Luckily, in newer variants The New York
Times has become more conservative with their date updates. In fact, it turned out to be
too conservative: a recent version updated the date on the front page only after
updating the entire content of the app (which, unfortunately, was also misleading).

(a) New York Times app for iPhone (b) New York Times app for iPhone
NYT was too conservative in displaying the date of the last update. The homepage
showed the same date before (a) and after (b) all the articles on the page have
been uploaded. The app was waiting for all sections to update before changing the
date.
111. Show absolute rather than relative time.

“Updated 0 seconds ago” could be an old message or could have changed just recently.
Users can have more confidence in an absolute date and time than in a relative one.

(a) NPR app for iPhone (b) Stocks app for iPhone
(a) NPR’s relative last-update date (“0 minutes ago”) was ambiguous: it could
have been recent or old, depending on when that message was updated. (b)
Stocks gave the absolute date and time for each news story (but no date of
update for the stocks – that must be inferred by looking at the stories).
READABILITY
Because the mobile screen is small and mobile devices are used in a wide range of light
conditions, reading is generally harder. Therefore, you should take every action possible to
make it easier for users to read your content. Our desktop readability guidelines not only
stand on mobile, they also become even more stringent.
112. Use a sans-serif font.

Research shows that users are typically faster when they read sans-serif fonts on a
computer screen than when they read serif fonts. Although no specific research has
been done on this topic on mobile, we have no reason to believe that phone screens
behave any differently, and therefore we recommend using a sans-serif font.

113. If your site contains a lot of text, include tools for changing font size.
114. Use a font-size default that is readable for a large majority of users.
The font-sizing tools ensure that, if the default font is too small for some users, they can
increase it and make it bigger. While we recommend including it on sites that contain a
lot of text, most users don’t change the defaults. Moreover, most of the time the size of
the text can be changed for article text, but not for headlines, buttons, icons, or other
design elements.
That is why it’s really important to start with a good font size throughout your site or
app. Because there is a wide variability in screen sizes and resolutions, we cannot
recommend an absolute font size that will work on all devices. A relative setting of the
font size to “medium” should be a good starting point.
m.nytimes.com
New York Times allowed users to change the font used for displaying articles.
115. Use solid backgrounds.
116. Use high contrast between the font color and the page background.
These are recommendations that stand on the desktop, but are even more important on
mobile.

One of our Windows Phone 7 users complained about the poor readability of the text in
the BBC News app: he noticed that the background was not solid, and it interfered with
his ability to read the text on the page.
BBC News for Windows Phone 7
The background contains a gray map that interferes with the text.
IMAGES, ANIMATION, AND VIDEOS

Images are worth a thousand words and have their place on mobile websites. As one user
put it:
“The thing with websites is that you’re always impatient, you don’t want to
read… I think really picture icons are so much more effective — you want to
just see, and stab, and move quickly, and if you’ve got a good speed, like me
at the moment, scrollbars and reading your way through a scrollbar takes
seconds… “
With images, we encounter the same recurring theme that we’ve seen so far in relation to
search boxes and navigation: we need to counterbalance the benefit that the images bring
to the user with the cost they incur (they take space on the page and they download

slowly). Therefore, each time you consider including an image on your site, we recommend
that you think seriously how much that image contributes to the content that you want to
convey.
117. Include images on your website only if they add meaningful content. Do
not use images for decoration purposes only.
It’s ok not to use images if they do not add extra information. On the New York Times
website, some articles had images and some did not (see below). Moreover, to avoid
slowing down the downloading of the article, although more images were available, the
New York Times only included one (providing, however, a link to supplementary
images). The second article rightly assumed that an image would not bring enough extra
content to be necessary.
(a) m.nytimes.com (b) m.nytimes.com
Images in news stories. (a) New York Times used images appropriately to illustrate
an international news story. (b) Another New York Times article did not contain any
images.
In contrast, on ABC’s website, most of the page for the show “Modern Family” is taken
by a big image that just contains the show’s title.

m.abc.com
The page for the show “Modern family” was filled by a big, logo-like picture
with the name of the show; this picture did not bring any extra information
to the user and it slowed down the loading of the page.
118. Do not use image sizes that are bigger than the screen. The entire image
should be viewable with no scrolling.
If the image is too big and does not fit on the screen properly, the user cannot get the
big picture.
119. For cases where customers are likely to need access to a higher
resolution picture, initially display a screen-size picture and add a separate
link to a higher resolution variant.
Typical instances of these situations are shopping sites and sites for photographers. In
both these cases, details are important. However, they are important only after the user
has established a certain interest level in the picture — that is, they decided that the
product may be worth buying or that the photograph is interesting. The majority of the
users are unlikely to be interested in the details of one particular picture, so for them,
waiting for the high-resolution image to download is a nuisance. Plus, you want to avoid
that your users not see the forest through the trees.
On Flickr.com, a photography site, the default size allowed the picture to fit entirely on
the page; a link at the bottom at the page led to other sizes of the photo.

m.flickr.com
On Flickr.com, the default image size allowed the image to fit the screen.
Other sizes were also available..
On Nordstrom’s website, there was not enough detail accessible for individual products.
Although the image size could be increased by clicking on the image, the maximum
image size is still too small for close inspection. Contrast Nordstrom’s photos with the
images on Marks and Spencers’ website.

m.nordstrom.com
Clicking on the image on the product page did show a larger version of the
picture; unfortunately, that version was still too small.
m.marksandspencer.com
The images on Marks and Spencer were bigger and took better advantage of
the screen space.

120. When you use thumbnails, make sure that users can distinguish what the
picture is about.
For thumbnails, we need to compromise between size (which affects the speed of
loading) and information conveyed (if the picture is too small, people cannot understand
what it is about).
Our users had difficulty on Nordstrom’s website because they were not able to see
wallets well enough in a thumbnail to actually decide if they were interested in the
product. One of our participants noted:
“Images are too small… You can’t see that well”.
(a) m.nordstrom.com (b) m.wholefoods.com
(a) Wallet thumbnails were too small. (b) It was impossible to figure out what
the thumbnails depict on the Whole Foods site.
In contrast, Zappos had really good thumbnails. Users often commented that they love
the quality of images both on Zappos’ mobile website and in their app.

m.zappos.com
Big thumbnails make it easier for users to select a product.
121. Use captions for images that are part of an article if their meaning is not
clear from the context of the article.
Captions are useful when the photographs bring extra information to the article. If your
article is about a TV show, for instance, you probably do not need a caption for a picture
from the show. If an article is about a politician, again a caption may not be necessary,
unless it shows that politician at an event discussed in the article (see the CNN case
below). But if the picture shows an interesting detail about the story (as it did in the
New York Times article below), it is worth a caption.

(a) m.cnn.com (b) m.nytimes.com
Captions for images in news stories: (a) CNN correctly did not waste space on a
caption for the picture of President Obama, in an article about him. (b) A caption under
an image from New York Times explained the image. Without the caption, the image
might have seemed purely decorative, but the caption (and finding out that the objects
in the image were artifacts displayed at a Russian market, when President Obama was
visiting Moscow) showed that the image is connected to an event.
122. Do not shuffle text around as images get loaded.

If a page has many images, the textual elements usually load faster and get displayed.
Some websites use no placeholders for the images that are still loading, and the text
gets quickly displayed, only to be shuffled around once images start becoming available.
This is highly disruptive to the users, because they typically start reading as soon as
content is visible on the page; when the same content is moved around, they have to
find it again on the page in order to continue reading.
The example below is from ABC’s website:

m.abc.com
The left screenshot displayed a show page before the image got loaded. Once the
image was loaded (right), the text was pushed down on the page.
Contrast that with BBC’s website: here, images had their own placeholders where they
appeared when they loaded. None of the text on the page was moved around once the
pictures became available.

BBC News app for Android
The images did not get shuffled around as they loaded.
123. Do not use images of text for navigation links.

When instead of text, sites use images to make their navigation option look fancier, they
expose themselves to the risk that these images be loaded late. Unfortunately, this can
cause problems on slow connections, because users may want to take an action and
click on a navigation link before the entire homepage is loaded.
On Chowhound’s older mobile site, one of our participants was looking for a recipe. She
never got to see the link to recipes, because the page loaded very slowly and the link
was an image. This is how the website looked on her Blackberry:

(a) m.chowhound.com on Blackberry (no longer (b) m.chowhound.com on
available) Android (no longer available)
The navigation links on the Chowhound website took a long time to load on the
Blackberry (a), and the user did not find the link to recipes, which was hidden in an
image. Image (b) shows how the site was supposed to look like when all images were
loaded.
NBC.com exposed itself to similar problems by using images for the link text. Below we
show two screenshots of their mobile website: before and after it was completely loaded.

(a) m.NBC.com (b) m.nbc.com
Menus didn’t download right away on NBC’s site because they were images rather
than text.
124. Do not use moving animation.

Our guidelines about carousels (36) contain a longer discussion about animation. The
bottom line is that animation on a mobile phone is likely not to be noticed, and people
will just be slowed down by the time needed to load different images.
In the example below, NBCs website (which was modeled very much after a full site)
contained a big ad for a show that filled almost the entire first page. Users might scroll
past that ad quickly to get to content, without even noticing the other ads that replaced
the original one.

m.nbc.com
NBC had moving ads; those ads slowed down the page and might stay
unnoticed by users.
125. If you have videos on your site, offer a textual description of what the
video is about.
Videos take a long time to load, so you want to give the user all the information they
need to decide whether it’s worth watching them. We recommend that next to each
video you include a short textual summary.
In the examples below, ABC’s mobile site did not offer any summaries for their videos,
making it hard to pick one.

(a) m.abc.com (b) m.cbs.com
Video summaries. (a) ABC had no summaries for their videos. (b) For episode
fragments, CBS used a one-line description that is hardly explanatory.
126. Clicking on the thumbnail and clicking on the video title should both play
the video.
Ideally, the text around the video (the video description and title) and the video
thumbnail should be clickable and should play the video. In the ABC example above, this
was exactly the case: users could click anywhere next to the video thumbnail and start
the video. Unfortunately, things were different in Crackle: if users wanted to play the
video, they had to click first on the video title and, then tap the “Watch now” button.

Crackle app for iPhone
Users needed to click on the title to get a larger variant of the thumbnail and
“Watch now” button.
127. Indicate video length.

This guideline is valid for video on a mobile device or on a desktop. However, it is
particularly relevant on a mobile device, where a long video can take a lot of time to
download. Users often watch videos on mobiles to pass the time while they are waiting
for something. The length of the video may give the user an idea about whether they
have the time and the connection speed necessary to try watching the video, or it’s best
to postpone the task for another time.
In the example above, Crackle correctly showed how long the video was. So did You
Tube:

YouTube app for Android
YouTube showed the video length next to each video. Unfortunately, it did not specify
the measurement unit.
128. Specify if the video cannot be played on the user’s device.

This guideline is an instance of a more general one (guideline 133) about not making
people download software (or data) that will not work on their mobile device. See that
guideline for a more detailed discussion.
ICONS
129. Use standard icons in standard ways.

This is just one incarnation of a basic usability principle: be consistent. By using familiar
icons in a familiar way, you take advantage of users’ knowledge and make it easy for
them to figure out the interface of your app.

iVerse comics for iPhone
In iVerse comics, the icon that is normally used for sharing changed the page view.
130. Use icons with good information scent.
131. Include labels with your icons.

Users have to figure out what icons hide, and icons need to make it as easy for them as
possible. That means that they should be a good representation of what they stand for.
However, what’s clear for one person may be completely confusing for another. What
should you do in that case?
There are at least three possible solutions:

(a) Include labels with your icons. In that way, your information scent is automatically
increased by the words. (Of course, you must choose good words for the labels).
(b) Use standard icons that everybody else uses for the same functions.
(c) Test your icons. This doesn’t have to be a full-fledged usability test, although having
the right context cannot hurt. But even an online survey where you ask people what
they expect to find under those icons can be indicative of whether your icons are on
the right track.
One of the many iterations of The Weather Channel on Android had some abstract-
looking icons that were quite hard to figure out. The icons did not contain labels,
although if you tapped them, a text appeared. Luckily, in more recent versions, the
designers gave up on the fancy icons and came back to more standard ones,
accompanied by labels.

Locati Right Hourly 36 10 Day Severe Maps Videos On TV Settin
ons Now Hour Alerts gs
The Weather Channel for Android (older version) and the icons in the carousel at
the bottom.
The Weather Channel on Android (newer version)

ERRORS
132. In a form, mark fields that need to be corrected to signal an error.

This is a replica of guideline 61 that we discussed in detail when we talked about forms.
(We include it here only for reference purposes.) Please refer to that section.
133. Do not make users download software or data that do not work on their
phone.
In our testing, we’ve seen many users attempt to download software or content that
clearly could not be used on their phone; examples include browsers (like in the Ohlone
College screenshot below), Flash players, videos, and PDF readers. Users do not know
that their phone will not run that software and spend time downloading it, only to
discover, after waiting (often for a long time), that the software does not work. Detect
whether the user accesses your site from a mobile phone and do not make them
download any software that is inappropriate. Note that this guideline applies to mobile
sites, but also to full sites that may use software typically not available on mobile.
Ohlone College website on Blackberry (older)
Cellphone users were asked to download browsers clearly inappropriate for a

phone. The website should detect that the access is coming from a mobile phone
and instead tell the user that the site is not available for their device.
Hulu did a good job of detecting when a request came from a mobile browser and
informed the users that their videos did not work on that platform.

(a) Hulu.com on Android (b) Hulu.com on iPhone
Hulu reported an error when mobile users tried to play a video.
134. Flash does not work on all phones; do not use it.
Most mobile sites do not use Flash. However, full sites do. If you decided to design a full
site that will work reasonably well on mobile, do not use Flash.
135. Make error messages salient and simple. Tell users (1) what the problem
is, and (2) what they can do to fix it.
We often see error messages that people do not understand or ignore. In order to be
noticed, error messages need to stand out and be presented in a simple language that
tells the user where the error happened (browser, website, application, etc.), what does
not work, and what the user needs to do.
The examples below illustrate some poorly written error messages.

Example of badly written error message. The user is not clearly told what they need to
do and what the problem is.
Redfin app for iPhone (older)
Users were not told how to fix the problem. Where should they go to enable use of
their current location?

In the Redfin example above, users should have been provided with a link to where to
enable the use of the current location. The error message did not specify how they
should fix the problem.
We’ve seen many users read an error message and then simply reload the page. When
we ask them what they think the error means, they usually just raise their shoulders
and say that, when they get such errors, it usually works if they try a second time.
iVerse Comics for iPhone (older)
Hard to read error. A simpler way to put it would be: “We cannot find your
content right now. Try again.”
136. After reporting an error, return to the state before the error.
Always respect the work that the user has put into filling in a form and, if an error is
reported, keep all the information that users have entered and show it to them so that
they can correct it.
One of our participants was trying to review an iPhone app in Apple’s App Store. To do
so, he had to select a username. He picked his name and entered a long review (he
really liked the app). However, after he clicked “Send”, he got an error message, telling
him that the username was already in use. Alas, when he tried to change it, he
discovered that his review was lost and that he was supposed to type it again.

Apple’s App Store
When an app review generated an error, the entire review was lost and the user was
supposed to enter it again.
137. Don’t report an error regarding a feature that is not in use.

Users’ mental model of an app is often very simple and does not match that of a
developer. When users do not use an app feature such as current location or camera
input, any error regarding that feature looks unjustified.
In the example below, the participant denied the use of the current location. The app
ZipRealty reported an error that the participant considered groundless: he was not
interested in searching for houses around the current location, but he rather wanted to
search in a specific town.

Zip Realty app for iPhone
The error reported by the app felt unjustified once the user had denied the use of the
current location.
Redfin ran into a similar problem. A user was trying to find houses for sale in Palo Alto,
so she denied the use of the current location (which was in a different city). However,
throughout the session she kept getting errors reporting the inability to use the current
location. She was puzzled by this error, since she felt that the app should not need her
current location in order to find houses in a completely different one.
MAPS AND LOCATION INFORMATION

Finding your way while you’re on the road is a primary application for mobile Web access,
so it’s worth investing in creating an excellent user experience for this task. Especially
considering that users often look up location information in order to go someplace to spend
money.
138. Whenever you have location information on your website, link it to a

map and include a way of getting directions.
Just giving users an address without a way to find it on a map is not going to be very
useful: users will need directions to get there. People who use mobile devices to find a
location are likely to be on the go and probably do not have access to paper-and-pencil
to write down the address and then input it again into a map application.
In the UK users developed a stratagem to deal with this problem: they would memorize
the post code of a location, and then they would go to the map application and enter the
post code there in order to get directions. They were all using the fact that, in UK, post

codes pretty much identify the address. However, users should not have to memorize
post codes; they should be able to get to the map directly, without inputting any extra
information. The example below shows this problem on an older version of Qype’s
Blackberry website: users could see a map, but could not get directions directly.
m.qype.co.uk on Blackberry (older version)
Users could see the restaurant location on a map, but, to get directions, they had
to memorize the address and enter it into a different application.
139. If your company has one brick-and-mortar location, list it in your app or
mobile website. If the company has multiple locations, include a locator
form in your mobile app or on your mobile website.
140. In a locator, use two possible values for location: automatically-detected

current location and location specified by user.
141. In a locator form, always give priority to the current location.
142. Allow users to easily change location.

Mobile use of the Web is often contextual: users want to find information that is related
to their current context. That context often includes location: finding a gas station
nearby or a good restaurant in a new neighborhood are tasks that are highly local. When
we informally asked participants in one of our study to recall one instance where the
phone was particularly useful, they all mentioned maps and navigation – being able to
find their way around and to get to where they needed to.
That’s why having a locator on your web page or app is essential for most companies
that have physical locations. That locator should be easily accessible – users need to be
able to quickly find it. Because users are often asking location questions relative to
where they are at a time, it’s imperative to detect current location whenever possible to
save users the extra trouble of explicitly entering information about it (see guideline45).
Because current location is so often used on mobile, it should be given priority in any
forms that require users to enter a location, by making it the default or the first option.

That does not mean that users should not be allowed to search for locations in places
other than their current location – on the contrary.
Most apps and websites that we’ve seen do a good job of including locators on their
website. The implementation of those locators is, however, often suboptimal, as the
examples below show it.
The TV Guide app for Android did not make use of the phone’s GPS feature and asks
users to enter their zip code. Macy’s iShop app did allow use the current location
feature, but that option was last on the locator form, before the options to search by zip
code and to search by city and state. When users see fields that need to be filled in,
they often start typing right away, without looking at the other elements on the page.
That’s why it’s better to have the current location at the top, before the other options, to
enable them to quickly take advantage of it, without inadvertently thinking they need to
enter their zip code. The third example (from Fandango) shows a correct locator – it first
lists the current location option, and only then the textbox for the city and state.
(a)TV Guide app for (b)Macy’s iShop app (c)Fandango app

Android for iPhone for Android
Locators: (a) The current location was not an option. (b) The current locator was
an option, but it was listed after two other options (zip code and city/state). (c)
Correct locator design, with the current location listed first, followed by the
specific-location field.
Fandango and Zagat below made the location change really easy: the location was
displayed on the page, and users could easily click on it to change it. It’s a lot more
complicated to change location in the app Now Playing. If you wanted to find movie
theaters in a location other than the current one, you would have to click on the small
“I” icon in the top left corner. Unfortunately, that placement of the locator is hard to
discover.

(a) Fandango app for (b) Zagat app for iPhone (c) Now Playing app for
Android iPhone
Placement of locators: Locators were easy to find in (a) and (b), but hard to discover
under the i icon in (c).
143. Avoid asking repeatedly for permission to use the current location.
Applications or websites that ask users again and again for permission to use the current
location are annoying and disruptive.
In Android and Windows Phone 7 apps, permission is typically given when the user
installs the app (although some apps needlessly do ask again while the app is in use).
On iOS, users often have to allow the use of the current location when they use that app
for the first time. For iOS, it’s better to have an “allow use of current location” checkbox
in the Settings section of an app (like Zagat did, in the example below), instead of
asking for permission repeatedly.

(a) Installing an app in Android (b) Zagat for iPhone
Market
It’s better to ask users to allow the use of current location only once. Include a
setting in the app that allows them to toggle that permission on or off. (a) Android
apps typically ask for permission to use current location at install time. (b) Zagat
has a global setting that lets users control whether the app users their current
location.
144. When displaying location information, show address, distance from

current location, link to map and directions, phone, and opening hours (if
applicable).
All these elements are important for users who search for location. Make sure they are
all conveniently displayed with the location. In the example below from Macy’s iShop
app, some of this information was present: they showed an (incomplete) address and a
store phone number when listing locations. If users clicked on the map icon, they could
see the store location on a map. The second icon under the store address was less clear,
but it pointed to directions to the store (unfortunately, the map zoom level in that case
is inappropriate – see guideline 145). They also had the opening-hours information,
available, however, only if users knew to click on the store. That information should
have been present in the listings, because it may determine what store is selected. In
fact, it would be easy to calculate if the store is open now and display that information in
the listing, together with a link to the complete opening hours. The location listing did
not show how far away the store is from the current location (see guideline 146).

Macy’s iShop app for iPhone
The app showed the (incomplete) address of a store, the phone number, and pointers
to map, directions, and opening hours. Unfortunately, getting to this information is
non-intuitive, and the distance from the current location was missing.

145. When displaying locations on a map, start with a zoom level that enables
the user to see his current location (or the location specified by the user)
and at least one of the locations of interest.
In the Macy’s example above, we saw that the map zoom level was not appropriate – it
does not help the user to see the map of the entire United States, nor would it help to
see just the very close neighborhood around their current location. Users need to see
both the current location and one or more locations of interest. In that way, users can
quickly judge where the store is in relation to themselves. Showing just the locations of
interest on a map will not help either – the user may not be familiar to the area. (Note
that directions usually tell the route between two points, but users may be interested in
other, more subtle questions such as – is this a detour worth making in my route to a
different destination?)
If the location search is based on a specific location (other than the current one), that
location and a location of interest should be shown on the map, instead of the current
location (e.g., if a user in San Francisco searched for restaurants around Times Square
in New York City, he should see Times Square on the map, as well as restaurants around
that point, but the map does not have to include San Francisco).
One of our Australian participants was looking for houses in Melbourne using Property
Finder Australia. After he entered his search query, he was taken to a map, but no
results were displayed on the map. He commented:
“It’s just brought up a map with nothing on it.”
The user had to slide right or left to find the search results because the zoom level was
too high to accommodate any of the returned locations.
Property Finder Australia for Android
The participant searched for houses, but he had to scroll around in order to find them.

146. Allow users to switch between a list view and a map view of locations.
147. If locations have different attributes of interest to the user, provide the
list of locations by default.
148. If locations are all equivalent (except for distance), provide a map view
of locations by default.
When there are multiple locations, it often pays to show them both on a map and in a
list. The two types of visualizations have different advantages: when they are in a list,
it’s easy to see details such as opening hours, or information about the offerings at the
location (e.g., in the case of yelp below, the type of restaurant). However, maps give a
good sense of where the locations of interest are and how far they are from a current
location or from a point of interest. Often users may not be interested in the closest
location, but rather in the location closest to a certain route.
We recommend making the list of locations the default because it often makes it easier
to see relevant details and pick the location of interest. In the case of Yelp below, seeing
the locations in a list lets users distinguish between different kinds of restaurants, and
allows them to pick one to their taste.
The Property Finder Australia app showed all the search results on a map (it did not
have a list view). One of our participants commented:
“I think I would prefer to have a list of properties rather than a map. And
then once you elect them you can go to a map view. It seems random and
haphazard to be dragging around a map, looking for little house icons. It
gives you very limited information: it doesn’t give you the price range, or the
amount of bedrooms, whereas if they had all properties in a list they could
show that information in a fairly concise way.”
On the other hand, if all locations were similar (e.g., all Chevron gas stations), then it’s
ok to use the map view by default.

(a) Yelp app for Android: list view (b)Yelp app for Android: map view
Yelp allowed users to switch between list and map view for locations, and, correctly,
defaulted to the list view.
149. In a list of locations, show how far locations are from the current
location. List locations in the order of distance from current location.
When participants in our studies were using Yelp, they often assumed that the
restaurants were listed in the order of distance from current location, and were surprised
to discover that it was not always the case. That’s one piece of information that needs
to be present in the list view, so users can quickly assess what location is the most
convenient.
We also recommend giving priority to locations closer to the current location (or to the
center of the place where the search was performed, if the user searched in a particular
place different from the current location).

(a) Best Buy app for Android (b) Target app for Android
Both Target and Best Buy showed the distance from their stores to the current location
(and sorted the list view in order of proximity). (a) Best Buy listed store hours,
address, and phone number, but it did not explicitly offer a map view of the locations
(although clicking on any of the stores led to that). (b) Target had list and map views;
unfortunately, the map view (which was shown by default), was hidden under the
target icon on the left. The icons under each store could have been potentially useful,
if users had known what they meant. There was no phone number, complete address,
or hours in the listing, but this information could have been obtained by clicking on a
store.
SHOPPING
150. When you present a list of products, use image thumbnails that are big
enough so that the user can get some information out of them.
This guideline is a variant of guideline 120, discussed in the image section.

151. On a product page, use an image size that fits the screen. Link to a
higher resolution image when the product requires closer inspection.
This guideline is an instance of guidelines 118-119, discussed in the image section as
well.
152. Offer the option to email a product to a friend.

Interestingly, a lot of times people used their phone to email product pictures to friends
or family and get their opinion. In our diary studies, we received diary entries like this
one:
“[I was] shopping for a couch for my mom with my mom… I sent a picture of
a sofa to my sister so she could shop with us from her home.”
Often, users will also email information to self as a way to save. Consider having a link
to email that allows people to easily share product information, either by email or
through other channels. Also, include alternative ways to save that product and return
to it later:
153. Offer the option to save the product in a wish list.

Although many users do not make purchases on mobile devices, several of our
participants mentioned that they do occasional “window shopping” on their mobile
phones. Even if users might not feel comfortable buying on their phone, they should still
be able to come back to products they have discovered during their mobile browsing
when they are at their desktop. Therefore, allow users to save the items that they like,
so that they could go back to them on a larger screen and inspect them more closely.
(See our separate report on wish lists for extensive general guidelines on wish list
design. Available from http://www.nngroup.com/reports/ecommerce/gifts )
154. On an e-commerce site, include salient links on the homepage to the

following information:
— locations and opening hours (if applicable),
— shipping cost,
— phone number,
— order status, and
— occasion-based promotions or products.

Based on our diary studies and on interviews with participants in our usability-testing
studies, checking location information, business hours, and order status are the most
frequent types of activities that people do e-commerce websites from mobile phones
(see also the section What People Do On Mobile Phones).
We heard many users say that they’d rather call than make the purchase on their mobile
phone; moreover, even if the website experience was really bad, users were likely to be
more forgiving if a phone number was salient, because they felt that they could readily
solve their problem. One user had difficulty using a website; he said:

“The good thing is that if I kept having problems I could call them directly
right here [using this phone number][…] I would rate this site lower […] The
one thing I did like is that they did have a phone number handy that I could
call right away.”
Interflora included their mobile phone on every product page, in case the users prefer
calling instead of buying online:
(a) m.interflora.co.uk (b) Zappos app for Android
A phone number was included on every product page (a) or on the homepage (b),
in case users experience technical difficulties or they feel more comfortable to call.
Shipping cost is a piece of information that users often take into consideration when
they check prices. Almost all users in our usability testing sessions had to go through
the entire 8-step purchasing process in order to find out shipping costs at Interflora.
Although the shipping cost was listed on the homepage, it was buried under the fold and
our users did not notice it.

m.interflora.co.uk
A shipping-cost link was listed on the website, but it was not salient enough for
users to notice it.
155. Always include the full catalog of products on the mobile site or the
mobile app.
(See also guideline 14).
Although we recommend streaming down functionality on mobile compared to your full

website, that does not mean presenting only a restricted subset of products.
Unfortunately, it’s very hard to know in advance what kinds of products users may be
searching for on mobile, and the tendency of many sites and apps to exclude part of
their catalog on mobile is, sadly, part of the reason why many people declare that they
still prefer full sites on mobile.
When using the JC Penney app for iPhone, users were surprised when she saw that
under fashion jewelry there were just a few options available. As one of our users put it:
“I’ve been in a JC Penney; I know they have much more stuff…”
Another user was searching for Venus razor blades on the Target’s mobile website. She
got very annoyed when she couldn’t find what she was looking for:

“I know they have them; I’ve seen them yesterday”.
Whether she searched or browsed for Venus razor blades, she wasn’t able to find any
relevant products.
Another participant was disappointed that the Best Buy app for Windows Phone 7 gave
him mostly refurbished models of GPS devices, when he was sure that they had a larger
selection.
Best Buy app for Windows Phone 7
Best Buy showed mostly refurbished items under their Portable GPS section,
leading one of our participants to believe that this was not their entire selection.
156. When presenting a list of products, show the ratings for each one to
enable users to select them more easily.
One of the more significant product attributes that users consider is ratings and/or
reviews. Although space is scarce on mobile, it’s essential to show the ratings of
different products in a list, so that users know quickly whether an item is worth
inspecting.
One of our participants who was using the Best Buy Windows Phone application was
disappointed that the search results page did not show any ratings for the products

displayed (see above). He felt that it would be easier for him to eliminate products with
bad ratings if he saw them right away.
Best Buy app for Windows Phone 7.
The search results did not show the ratings for the different products.
BANKING AND TRANSACTIONS

Transactions are still relatively rarely done on mobile phones, but the number of users who
are engaging in mobile transaction is increases. Many users do not have a clear
understanding of whether cellular networks are secure. Moreover, on mobile phones it is
fairly easy to make errors when entering data or to miss some relevant information, due to
the small screen. Therefore, users are reluctant to make transactions that involve any
significant amount of money.
This is how a user talked about his fears of making errors:
“I was trying to move money from savings to checking… It was like, if I go
the other way and if it doesn’t confirm me, then I’m screwed, because then
I’m going to have less money than I think I do in my checking account. Let’s
not do it, let’s really just do it on my laptop.”
157. Whenever users make a transaction on the phone, email them a

confirmation number for that transaction. Inform them that they will
receive an email and tell them what it will contain.
158. Allow users to “soft print” the transaction confirmation screen by taking
a screen capture.
Another problem related to transactions is that they often involve a confirmation number
that is hard to write down when people are away from their desk. Unless users can be

certain they will have later access to that confirmation number, they may be reluctant to
commit to a transaction whose traces may be hard to recover.
A user tried to accomplish a funds transfer between two bank accounts on his phone,
but stopped short of doing it because he was concerned about losing his confirmation:
“The other thing that happens, at least on my laptop, is that, once I do [the
transfer], it gives me a confirmation number that I could save… I don’t know
what to do about the confirmation that I get here. And it’s important to me
because it’s happened before: I know I transferred something, it didn’t occur
at Bank of America, they charged me saying ‘you don’t have enough funds’. I
kept the record and I emailed the document to them, ‘this is my screenshot of
this confirmation’, and they said, ‘oh, you know, there must have been a
problem on our end, we’re sorry’.”
To prevent worries that the transaction may not go through at the bank’s end,
send users a confirmation email with the transaction information; also let them
know to expect that email.
On the iPhone, another way to help users preserve an accurate level of history is by
taking a screenshot. A screen capture is the mobile phone equivalent of “Print Screen”.
With the iPhone, it is fairly easy: you just hold the Home button and the Sleep/Wake
button at the same time. Unfortunately not all phones support this functionality
(sometimes users need to install special software for that), and even iPhone users are
not aware of this feature.
159. Whenever users need to submit a transaction, show them a one-screen

summary of the transaction.
When the information related to a transaction does not fit on one screen, users cannot
be sure that they haven’t made a mistake. People are particularly wary of carrying out
financial transactions on small devices: not only because they are somewhat unsure of
the security of the medium, but also because it’s so easy to type something wrong or to
overlook an important piece of information.
On the pay-bill page of the mobile site of Bank of America (as well as in older versions of
their app), the information was spread out on two screens. One had to go back and forth
to make sure that the payee, the amount, the delivery date, and the available balance
were all correct. Newer versions of the Bank of America app have already learned their
lesson and nicely present all the relevant information on a single screen, with the “Make
payment” and “Cancel” buttons at the bottom.

(a) m.bankofamerica.com (b) Bank of America app for iPhone
(a) The transaction information was spread over two screens; one had to scroll back
and forth to make sure that all the payment-related information was correct. (b) All
the transaction information was nicely laid on a single screen.

Feature Phones
Most of the guidelines that we discussed before do apply to feature phones, as well. In fact,
some are even more stringent for feature phones.
For instance, since most feature phones have reduced keypads, it’s even more important to
design interfaces that minimize typing. Since feature phone users are often less expert at
using the internet on their phone, it’s imperative to include logos and phone numbers on all
websites intended for these devices to avoid making people feel lost. Asking feature-phone
users to register or log in is probably going to stop them in their tracks.
Because the screen on feature phones is so small – even smaller than that of most
smartphones, new content should always be given priority. That means that fundamental
interface features such as the search box or the navigation have to take the back stage: we
recommend that you include them at the bottom of the page, to leave room for more
important content at the top.
The example below comes from a participant using CNN’s website on a feature phone. She
wanted to read an article about war veterans, so she picked a headline from the headline
page. That page also included a short picture and a sentence fragment about the story.
When the user clicked on the story, she got to a page that repeated the title; she scrolled
down and saw the same image that she had seen before. After even more scrolling, she
could read the same sentence that she had read on the headline page, this time completed.
Unfortunately, especially for a small screen, this approach does not work. And it’s not only
because it makes it harder for users, as they have to interact more with the site. The
ultimate result is that users will leave your site without having achieved their goals: we
have seen users give up on the site, thinking that, since no new information appeared on
the screen, the site must be broken.

««
««
««
(a) Headline page (b) Article page
m.cnn.com on a feature phone
Users had to scroll to get to new information when reading a story on CNN’s
website. The “summary” under the headline consisted of the first few story
lines and the users did not get to see new content on the article page until
after three screens worth of scrolling.
160. On feature phones, do not include a search box if most of your users are
browsers.
161. Put the search box at the bottom of your screen.

Whereas we believe that a search box should be included on any website designed for
phones with larger screens, when the screen is tiny, placing a search box (especially at
the top of the page) would increase the interaction cost for browsers: they would need
to scroll past the search box to get to new content, and possible they would need to deal
with the content being split across multiple pages.
192 INFO@NNGROUP.COM Feature Phones

However, when the screen is small, priority should be given to new content. Google,
whose users are almost only searchers, makes the search box less salient on a search-
result page by putting it at the bottom of the page on the website designed for feature
phones, thus giving priority to new content (that is, to the search results).
««
(a) Google results on a feature (b) Google results on a large-screen

phone touch phone
Position of the search box on the Google search-results page for two different
types of phones. (a) The search box was placed at the bottom for the feature
phone to give priority to new content. (b) The search box was placed at the top
for the bigger-screen phones.

162. On a feature phone screen, place navigation options at the bottom of the
page.
Based on the same argument that priority needs to be given to new content, we
recommend that the navigation options on a page be placed at the bottom.
163. On a feature phone, minimize the number of images per page.

Feature phones are often slow and have trouble dealing with many images on a page.
Although users of feature phone are likely to enjoy images in limited quantities, you
have to strike a balance between satisfying that need and overloading the phone.
m.victoriassecret.com on a feature phone
The images took a long time to load on the feature phone (and they are smaller
in size).
194 INFO@NNGROUP.COM Feature Phones

General Guidelines for Touch Phones
This section of the report discusses issues that are specific to touchscreen devices.
TARGETS: SIZE, PLACEMENT, AFFORDANCE

One of the bigger problems with touch interfaces and with some trackball interfaces for
mobile phones is that it is hard for users to hit the target precisely. Parhi, Karlson &
Bederson (2006) 19 showed that, for touchscreen portable devices operated with one hand,
the optimal target size was a 9.6mm square (approximately 1cm2) for discrete tasks (that
is, tasks that involved an isolated click, as opposed to a series of clicks; a series of clicks is
more representative of typing).
Therefore, all these interfaces must build in some tolerance to error by (1) leaving generous
amounts of space around widgets that need to be clicked (buttons, arrows for dropdown
boxes, links, scrollbars), and by (2) increasing the target size of these widgets. The first
condition ensures that people will not accidentally click on the wrong widget. The second
condition builds in some room for reaching error.
These considerations are contained in the following guidelines:
164. For touch phones, widget target area (i.e., tappable area) should be at
least 1cm X 1cm.
165. For touch phones, do not crowd targets. Leave generous amounts of
space around widgets such as radio buttons, arrows for dropdown boxes,
checkboxes, scrollbars, and links.
Although intuitively everyone agrees that small targets are hard to hit, many designers
persist in creating smaller and smaller targets, in the attempt to fit more functionality on
the small screen. That leads to apps with crowded, hard-to-use interfaces. Below are a
few examples of targets that have just too little space around them.
19
Parhi, P., Karlson, A. K., and Bederson, B. B. 2006. Target size study for one-handed
thumb use on small touchscreen devices. In Proceedings of the 8th Conference on Human-
Computer interaction with Mobile Devices and Services (Helsinki, Finland, September 12–
15, 2006). MobileHCI ‘06, vol. 159. ACM, New York, NY, 203-210. DOI=
http://doi.acm.org/10.1145/1152215.1152260

(a) m.hbo.com (b) mobile.walmart.com
(a) The different shows on HBO’s mobile site were too close to each other: it was
easy to accidentally select the wrong show. (b) The breadcrumbs at the top of
the page are too small to touch (or even see). The widgets at the top right
corner are bigger, but still too small and close to each other. Contrast that with
the buttons at the bottom of the page, which are much easier to reach, but still
too close to each other.
196 INFO@NNGROUP.COM General Guidelines for Touch Phones

(a) m.bananarepublic.com (b)USA Today app for iPhone
(a) The checkboxes on Banana Republic’s site were very small (and also close to each
other). The buttons at the bottom of the page were of a better size. (b) The i icon
in the top left corner of USA Today was too tiny and the sections at the top were
crowded.
One of our usability-testing participants struggled for about 2 minutes to select his state
(California) in a dropdown menu in order to find Nordstrom locations. The states were
just too close together and he kept hitting the wrong one, so he exclaimed:
“At this point I wouldn’t even care [to find locations]… Sometimes with the
keypad it’s actually more handy…”
Indeed, although typing is generally painful, typing two letters to select a state can be
easier than using a badly-designed dropdown menu in a touch interface. Even for non-
touch interfaces, if there are many choices in a dropdown box, the cost of scrolling down
to the right option needs to be weighed against the cost of actually typing the choice or
its first few letters.
When targets are too close to each other, it’s easy to accidentally hit the wrong one. In
the Dictionary example below, the targets were too small, and, although the space
between them was comparable to their size, they were simply too close for adult fingers.
The U-Verse example is an interesting one: users could choose favorite channels by
tapping onto the stars. However, stars were close to the scroll bar on the right, and the

scroll bar was itself a target (users could tap it to move faster in the channel space). If
one hit the scrollbar instead of the star by accident, they would be moved to a
completely new page in the channel space. And then they would have to scroll back to
where they were – a pretty hard task in a list of thousands of items!
(a) Dictionary on Android (b) ATT U-Verse on iPhone
Crowded targets are hard to touch reliably: (a) The top icons in the Dictionary app
were small and close to each other. (b) The stars were close to the scroll bar;
accidentally hitting the scroll bar could take users in a completely different spot in the
channel space.
166. Do not rely on small padded targets.

One solution that many apps use to partially get away with smaller targets is to pad
them. That means that the real tappable size of the target is bigger than the visible area
of the target. If users are slightly imprecise and don’t hit exactly on target, that’s fine –
the tap is still counted as hitting that target.
Padding helps, but it’s not as effective as it might seem. The main problem is that, with
few exceptions that we discuss below, users have no way of knowing which targets are
padded. Because of that, they will still strive to reach the target precisely, taking more
time to do so than if the target was bigger.
To explain this in human-computer interaction terms, Fitts’ law says that the time to
reach a target depends on the finger’s distance to the target, but also on the (perceived)
size of the target. Users’ movement is typically composed of two movements: a rough

one in the direction of the target, and, once the finger has come close to the target, a
slow, refined one, focused on hitting the target accurately. If the target looks small,
users will still take a long time trying to hit it exactly, without knowing that in fact they
have room for error.
In other words, padding is not an excuse for making targets smaller: users are still
going to struggle trying to hit them.
The “i” icon in the USA Today screenshot discussed in guideline 165 was padded: the
target was small, but the app left some room for error. Unfortunately, users didn’t know
it: even if users saw that target, they still would have to program their movement extra-
carefully and slow down to reach that small of a target.
USA Today app for iPhone
The “i” icon was padded, but programing a movement to reach it would still take a lot
of effort on user’s part.
167. Use padding for tabular views.

There are some situations where padding is expected. They usually occur in a tabular
view. When users see items in a table, they presume to be able to hit anywhere in a cell
and get the same result (rather than hit only on the right or only on the left).

Best Buy app for Android
Each cell in this table view was padded: in each row users could tap the icon, the text,
the white space, or on the arrow, with the same effect.
Problems occur when apps and websites compartmentalize the cell space, and assign
different functionalities to different parts (for instance, tapping on the arrow has a different
outcome than tapping on the text or tapping on the icon).
Some examples of these issues come directly from Apple (see the screenshots below).
When users came into our lab, we often asked them to connect to the existing wireless
network. Once they got to the menu where they had to select a Wi-Fi network, some clicked
on the white space and were able to get into the network, but others hit the arrow on the
right and ended up on a confusing-to-them page where they had to deal with IP addresses.
In spite of the fact that the arrow on the right was made to look like a button, users thought
that taping on the white space or taping on the arrow should produce the same result: they
expected padding. And if you looked at how Apple’s tabular view worked just one screen
before, in the Settings app, you would see that they based this expectation on prior
experience. The button-like arrow in the Wi-Fi menu was not a strong enough cue to signal
the lack of padding in that cell.

Tapping here connected
the iPhone to the Wi-Fi Tapping here led
network. to the next
screen.
(a) (b) (c)
Choosing a Wi-Fi network in iOs.
Inconsistent padding: (a) Each cell in the tabular view was padded. Users could click
anywhere within the cell (either on the arrow or on the white space), and be taken to
screen (b). (b) Tapping on the network name or on the white space caused that
network to be selected, but tapping on the button-like arrow led to screen (c).
Other cues don’t work either. In the Bloomberg example below, dragging could be used to
arrange topics in a desired order. Unfortunately, users had to drag the icon on the right –
dragging the text in a cell or the white space did not work. All our participants tried hard to
drag the white space to no avail – only one who was very diligent and willing to spend more
time with the app figured it out.
It’s better to go with the users’ expectation and have the entire cell padded.

Bloomberg app for iPhone
Users had to drag the icon on the right to order the categories in a desired sequence.
However, most of our participants expected to be able to drag the entire row.
168. Create the right touch affordance for targets: make them look tappable.
Sometimes people don’t touch a target because it doesn’t look like one: they don’t think
something will happen if they hit it. It’s important that designers add an extra touch of
3-dimensionality to make sure that users get what they need to do.
Sometimes people can figure out targets right away, even if they don’t have a 3-D look:
simply by placing targets where they are supposed to be, you can build in affordance.
For instance, almost every user will know that the icons in a navigation bar are tappable
because they have seen navigation bars before. They will know that a cell in a table
view (see the discussion before) is tappable because they are familiar with table views.
But whenever your design departs from conventions (as it is the case with the two
examples below), make sure that all the targets have the right visual affordance.

(a) WeightBot for iPhone (b) Convert Units for IPhone
Targets lacking affordance: (a) The big box with a number in it was a target;
tapping it changed the number from the weight change to the BMI. (b) The Mass
grey box was tappable – users could switch to another type of units (e.g., length).
169. When a design element looks like a button, users will expect to touch it.
The reverse of guideline 168 is also valid: if something looks tappable, users are going
to think it’s a target. We’ve seen many people tapping on arrows that looked that had a
little bit more weight. So make sure that you don’t use 3D cues inappropriately in your
app.
170. For iOs, build a back button into your app. For other platform, make sure
that the physical back button works properly within the app and allows
users to return to the previous page.
One of the problems with touch screens is that it’s easy to accidentally touch something
that you didn’t mean to. We’ve seen many users get lost because of an unintended
touch, and then losing all their hard work or being completely disoriented because they
didn’t have a way to go back.
Websites usually don’t suffer from this problem: browsers have back buttons built in and
users know how to use them. Phones running Android and Windows Phone 7 have a
physical back button that (sometimes) saves the day: if properly used by the app, the
back button can take the user back to the previous screen. But the iPhone has no back
button, so the interface must make up for it: most apps should include a soft back
button to allow the user to go back to the previous state.

(a) Amazon app for iPhone (b) Sears app for iPhone
Both apps have a back button that enables users to go back to the previous screen.
Even platforms who have a physical back button, surprisingly, suffer from problems
because it does not work correctly. One of our participants was looking for a moisturizer
using the Walgreens app for Android. She picked one, looked at it, and then decided she
would not buy it. However, there was no way for her to actually go back to the search
results – she had to redo the search. The Walgreens app did not have a back button to
take her back to the search results (and the physical “Back” button on her Android
device just took her back to the home screen).

Back button
Walgreens app on Android
When users select a product in the list of search results, they cannot return back to
the search results: the back button takes them to the homepage.
171. Place destructive buttons far away from the physical device buttons.
The physical device buttons tend to be used a lot. Because of that, you don’t want to
expose yourself to accidental touches that are destructive: people taking some
irreversible action because they meant to touch one of the physical buttons.

(a) Yowza app for iPhone (b) Gmail app for Android
Placement of the delete button: (a) Yowza placed the delete button farthest from
the iPhone’s Home button. (b) Gmail had the delete button immediately above the
physical buttons, making it easy to touch accidentally. (Note, however, that, at
least on some Androids, the physical buttons require a slightly stronger touch than
the screen).
GESTURES
172. Use only the more familiar gestures (tap, drag). Do not rely on users
knowing and remembering more complicated gestures.
173. Avoid assigning different functionalities to similar gestures.
174. Take advantage of the natural affordances for gestures.

Although different platforms support different gestures, users across platforms seem to
be comfortable and aware of only a subset. Most people know of tap, drag, and
horizontal swipe (with the last one being more salient especially in the context of
carousels and book-reader or magazine apps). The pinch-in and pinch-out gestures for
zoomin and out are also relatively well known and well-used. But other gestures such as
shake or swipe to delete (on the iPhone) are unfamiliar to most users.
Thus, even well-seasoned iPhone users are not aware that shake means undo in the Mail
app or in an app such as Weight Bot:

WeightBot on iPhone
The app used an unfamiliar gesture to delete an entry.
The Carrier app on iPhone
The app used two similar gestures for different actions: (1) drag was used to get to
the next page in the novel, and (2) flick (or horizontal swipe) to go quickly through
many pages at once. Drag requires users to keep their finger on the screen as they
move through the pages, while swipe is a much quicker movement, followed by
lifting the finger off the screen.
Another danger with gestures is ambiguity: some gestures are fairly similar, and
assigning different actions to them can create difficulty for the users. For instance, drag

and horizontal swipe (or flick to use iOS terminology)are fairly close. When apps such as
the graphical novel The Carrier use the two gestures to implement different
functionality, confusion can arise. Moreover, in a book-like app there is a fairly strong
affordance of swipe (since it is similar to the gesture we normally use to turn pages in a
regular book); therefore, it is unadvisable to go against users’ intuition and program it
to advance quickly through pages.
Beside swipe, drag around in a circular motion can be also fairly intuitive in a context
where you have to rotate items. Adobe’s app PS Express used gestures successfully to
help users quickly edit pictures: rotate them, change saturation and brightness, crop.
However, PS Express was careful to offer tips when each of these functions was
selected, making the gestures a lot more discoverable. And some of these gestures (like
rotate – discussed above) are similar to what we use in real life when we perform the
same action.
PS Express app for iPhone
Gestures that have good affordance and are made discoverable by tips can be effective
in a productivity app.
175. If you must use less familiar or less discoverable gestures, add some
redundancy in the interface.
Gestures such as shake for undo or swipe for delete are unfamiliar to most users. If you
must use them, we recommend that you also allow users to perform the same actions in
a different way, preferably by using interface buttons.
For instance, in the iOS Mail app, users could delete items either by swiping over each
individual email or by using the edit button at the top of the screen. Similarly, Yowza, a
coupon app, allowed people to delete favorite stores with the same swipe gesture, or
using the interface. The Gmail app on Android lets users delete messages either by

checking individual items or by tapping and holding a message (a gesture that has lower
discoverability).
Mail app for iPhone
The edit button allowed users to delete (or archive) messages, but so did the swipe
gesture over any of the individual messages.

Gmail app for Android
Gmail also used redundancy in the interface for the tap-and-hold gesture to delete
(but not to do other less frequent actions such as read, mark unread, mute, or report
spam).
Horizontal Swipe
The horizontal-swipe gesture is fairly popular with designers of apps on touchscreen
devices. It is often used for deck-of-card navigation and carousels, and, while quite

discoverable in certain contexts, it is less so in others. Apps sometimes abuse it by
assigning it different meanings, depending on where it is done on the page.
176. In most situations, users need cues to figure out that they’re supposed
to use the horizontal swipe gesture.
We mentioned before that users are quite familiar to the real-life book mental model, and
whenever they read a magazine or a book on a phone, they discover that using the swipe
gesture can turn pages. Some users need more time figuring it out, so even there, a quick
tip that tells first-time users how to turn the page can be helpful.
In most other situations, the swipe gesture needs some external cues such as an arrow or
truncated content to the right. Guideline 0 talks about using cues for carousels, so that
users know they are supposed to navigate horizontally. The same kinds of cues apply here.
When we talked about carousels, we said that dots are a weak cue. In spite of being present
in the iOS design of the app home screen, we find that users don’t necessarily notice dots
and may ignore content that is on different pages.
(a) ESPN score Center app on Android (b)The Weather Channel app on
Android
Dots are weak cues for horizontal swipe.

177. Don’t use the horizontal swipe gesture for navigation on a new screen
and for carousel navigation on the same page.
Sometimes we see the horizontal swipe gesture being used more than once on the page:
for instance, to change between different screens in the app and to control a carousel.
This is more frequent in iPad apps, and in our iPad report, we use the term “swipe
ambiguity” to refer to it.
For instance, in The Weather Channel app, users can swipe horizontally to go to the
weather for a different location, and they can also swipe horizontally within the small tab
bar at the bottom of the screen to see more options. Someone trying to see a different
location can easily swipe over the carousel and be surprised to get a different result than
expected. This is because, unfortunately, when users swipe to turn the page, they rarely
think of localizing the gesture on a part of the screen (in real life, it doesn’t matter
where you touch the page in order to turn it). Although they will not expect to swipe
outside the carousel to make the carousel move, they do expect to swipe anywhere on
the page to move to the next location.
The bigger the carousel on the page, the more serious the issues.
The Weather Channel on Android
Swipes on different regions of the screen cause different actions.

178. On touchscreens, users expect to use the swipe to control a carousel.
Once an app has signaled to a user that they have a carousel in front of them (see
guideline 55), many people will intuitively use the horizontal swipe to navigate in the
carousel. When that doesn’t work, there’s potential for great confusion.
On Financial Times’ web app for iPhone, the horizontal swipe was used to navigate
between different sections. However, one of the sections also contained a carousel.
When users tried to swipe through the videos in the carousel, they found themselves on
a completely different page. In fact, to advance the carousel, they should have pressed
one of the two arrows above the carousel. (Note that this design also violates guideline
54, which recommends grouping the carousel control with the carousel.)
Financial Times web app for the iPhone (app.ft.com)
Users expected the carousel to be controlled by a swipe gesture, rather than the
arrow. When they swiped, however, they were taken to a different FT section.
Tapping and Content

The most common gesture on touch screens is, of course, tap. Here we describe two
circumstances where tap is commonly used: (1) tap the margins of a page to turn the page
in an e-reader (or magazine) app; and (2) tap a full-screen image (or video) to show the
interface controls.

179. In content-reader apps, it should be possible to turn pages both by
tapping the page margins and by swiping horizontally.
The first gesture – tapping to turn pages – is almost a contraction of the swipe gesture:
when you swipe again and again, the gesture becomes more economical and essentially
transforms into a tap. Although users are not necessarily aware of it when they first
start using content-reader apps, they eventually discover it.
We talked before about the affordance of swiping for turning pages. Because of the close
relationship with real books, that gesture has better affordance in content readers.
Therefore, we recommend that the two gestures coexist within the same app to support
the same function: turning the page.
180. When displaying images (or video) full screen, allow users to get to
controls by tapping on the image.
181. When displaying images full screen, start by showing the controls, then
fade them away.
Tapping an image to show interface controls is less discoverable. We’ve seen many
people not realizing what they have to do when they are confronted with a picture and
no interface buttons. However, we still think it’s very important to be able to show
pictures (or videos) full screen, to take full advantage of the already-small screen real
estate. The solution is simple: whenever showing an image full screen, display the
controls for a few seconds and then fade them away. In that way, users become aware
of the existence of the controls.
Gilt for iPhone
When the image was first shown full screen, the controls and the caption were
displayed, then faded away to allow users to see the picture as well as possible.

ORIENTATION
Most phone users tend to use their phones in portrait orientation, and naturally switch
orientation when they reach an impasse: the text is too small and may look better in the
other orientation, or a photograph orientation does not match their phone’s orientation.
182. Support both phone orientations (landscape and portrait) whenever

possible.
183. Don’t make users switch between orientations often.

Although we recommend that your app supports both the portrait and the landscape
orientations, we’ve seen apps that forced users to change orientations (because, for
instance, they did not support the portrait orientation) without causing major
discomfort.
iVerse Comics app for iPhone (older)
Comic panels alternated between portrait and landscape, forcing users to turn the
phone back and forth.
What does cause major discomfort, however, is when the app forces users to frequently
change orientations. For instance, a comic-viewer app (iVerse Comics for iPhone)
alternated between portrait panels and landscape panels. Although, technically, the
portrait panels were visible in landscape mode (and vice versa), the text was too small,
and the user could not read it properly unless the panel orientation matched the phone
orientation. She bitterly complained about it:
“One thing I do not like is that I turn it sideways so I can read it, and the
comics keep changing direction. So then I have to [turn it] back and forth so I
can read it”.

184. Most apps should not display different content (or different interface
widgets) in different orientations.
185. Apps that display data can use landscape to fit extra detail.
186. Whenever an app uses landscape for extra information, it should let
users know (e.g., by displaying a tip or a message).
Landscape often can fit more detailed information than portrait. For most apps,
however, we don’t recommend displaying different content in the two orientations – for
at least two reasons. First, users don’t naturally change orientations just to check if the
interface or the content will be different. And second, because most orientation changes
happen when there’s a problem, changing content exactly at the moment when users
want to inspect it better can cause a lot of frustration.
However, we do agree that certain pieces of information, such as graphs and complex
data, can be displayed in more detail in landscape mode. If that is the case, we
recommend to explicitly tell users that they can get more in the landscape view. The
message, however, should be easily noticeable, so that users don’t miss it.
CNBC and Bloomberg all displayed more in depth graphs in landscape orientation. Their
ways of informing the users of this feature are slightly different and vary in their
effectiveness. Thus, an older version of CNBC showed a grey-font message next to the
chart. In our testing, most users paid no attention to it. In a newer version, CNBC
moved the message above the graph, in a more salient position. It was better, but still
not perfect. We like Bloomberg’s solution best: when users tapped on the chart to make
it bigger, the message “Rotate to view full screen” appeared above the chart. Users
noticed it right away, as it was in direct response to their action, and turned the phone.

(a) CNBC app for iPhone (older)
(b) CNBC app for iPhone (c)Bloomberg app for iPhone
Different ways of signaling extra details for charts in landscape orientation. (a) was
the least effective and (c) was the most effective.

187. Do not ascribe different content to the two possible landscape
orientations (physical buttons left or right).
We’ve seen that turning the phone around is not something that people remember to do
– they just do it because they’re told to or because they need to see something better.
WeightBot attaches two different meanings to rotating the phone, depending on whether
it’s done clockwise or counterclockwise. Asking users to memorize what kind of content
different landscape orientations may accommodate is confusing and too demanding.
WeightBot for iPhone
Different content for different landscape orientations. Users cannot easily

remember the meanings assigned to rotating clockwise and rotating
counterclockwise.
INPUT
188. Show a keyboard appropriate for the input that the user is supposed to
type.
Whenever you know exactly what kind of input the user is going to enter, show the
keyboard that contains those kinds of characters. If they have to enter a price, show
them a numerical keypad augmented with a few other symbols (notably, “.”). If they
have to enter a name, show them the usual alphabetic keypad.

(a) RedLaser for (b) Sephora for (c) Grocery IQ for
iPhone iPhone Android
Keypads for entering field values: (a) Users were appropriately shown a numerical
keypad for an UPC code. (b) Users were shown the alphabetical keypad when they
needed to enter a product quantity. Clearly, in this situation a numerical keypad
would have been better. (c) An augmented numerical keypad was correctly shown
for entering price.
189. In long forms, separate edit from selection.

When you have to deal with a complex form, where users need to enter several fields on
the same screen, we recommend that, for each field, the app take users to a separate
screen with just the field being typed and the keypad.
The alternative is to have the keypad appear on the form screen, blocking part of the
fields. That alternative is counterproductive – first, because users can easily get
distracted by the busy background rather than focus on a single field, and second,
because they typically jump from field to field, by touching the boxes available on the
screen. In applications, the extra tap does not cost users any wait time, so the benefits
of seeing the field clearly rather than being distracted by the background overcomes the
cost of the extra tap.
Below are a few examples to illustrate the issue.

Macy’s iShop
Tapping on “last name” showed the keypad on the screen, obscuring the form. Users
could not get rid of the keyboard anymore, but they could scroll in the small space
above the keypad.
While Macy’s (above) obscured their form with the keypad and forced users to work with
half the screen, Skype and Grocery IQ correctly took users to a separate screen to enter
their value for each field.
(a) Skype for iPhone

(b) Grocery IQ for Android
When entering a value, users were taken to a separate screen, where the keypad
did not obscure the information already present on the page.

Guidelines for Apps
IMMERSIVE APPS
Immersive apps are apps that do away with the traditional interface conventions and
attempt to mimic a real-world object with which people are already familiar. The assumption
of an immersive interface is that users bring in their prior experience with the physical
object and thus, simply know how to use the app without any explanation or training.
When immersive apps are successful, they’re often deemed “fun” by the users.
Examples of immersive apps include Compass for iPhone, Zippo for iPhone, Night Recorder
for iPhone, iHandy Level for iPhone, and Ultimate Stopwatch for Android.
(a)Ultimate Stopwatch app for Android (b)iHandy Level app for iPhone
Immersive apps resemble real-world objects.
190. Don’t use an immersive app if you cannot make it completely coherent
with the users’ expectations.
A successful immersive app should be easier to use than a different app with similar
functionality that uses a traditional interface. If the immersive quality of the app makes
any part of the task harder to accomplish, then the task is not a good candidate for an
immersive app.
Let’s take the example of iHandy Level. The app looked fairly intuitive – you were
supposed to use it as regular leveler. Unfortunately, there was one part that has no
correspondence in the real world – namely, calibration. To use the app, users had to
calibrate the leveler. Since they had no prior knowledge on leveler calibration, they had
to figure out how to do it using the existing interface.
222 INFO@NNGROUP.COM Guidelines for Apps

Calibration button
iHandy Leveler for iPhone
To calibrate the leveler, users had to click the i button, find the Help and instructions
link, then study and memorize the instructions, go back to the main page, find the
calibration button, then apply the instructions. A tedious process like this invalidates
the whole purpose of having an immersive app.
Even if people discovered the calibration button, that would not be enough. They would
then have to figure out how to use the button, by getting to a page of instructions,
memorizing the instructions (“To calibrate, hold iPhone against a flat surface and press
Calibrate button. Do this three times for vertical, horizontal, and face-up orientations as
illustrated below.”), and then coming back to the main app page. One of our study

participants went back and forth between the main screen and the instructions several
times until he was able to put the instructions in practice.
The conclusion is to be cautious when designing an immersive app. Make sure that the
task(s) supported by the app have a good mapping onto what people already know from
their interaction with a real-world object. Any clashes between the application mental
model and the users’ mental model can be fatal.
191. Even if the app is not completely immersive, well-selected immersive

elements can make it more enjoyable.
192. Make sure that the immersive elements make the users’ task easier
rather than harder.
Apps like Urban Spoon, Web MD, Motor Trend, or Pizza Hut are not completely
immersive. In fact, the majority of their screens are quite standard. But in their attempt
to make the app more unique, they added some immersive elements. Some of them
were more successful than others.
Thus, selecting a restaurant in Urban Spoon was meant to look like playing on a slot
machine. However, unlike for a slot machine, users selected the values in each of the
spinning columns. They also had to lock the lockets underneath each column. And then
they could either shake or just press one of the two buttons. Their action triggered a
noise similar to the slot machine, and the result was a restaurant.
If you think about this process, you will realize that it’s not quite like a slot machine – it
works more in the opposite way (you get one result, but set three inputs). Most
importantly, the lockets under the columns have no place in the slot-machine mental
model. In fact, almost every time we tested that app, users forgot to lock the lockets.
Even people who said they use the app regularly forgot to do so.
In Web MD, another partially immersive app, in order to diagnose a disease, users had
to select a body part where the disease symptoms are localized. Then, they needed to
choose their symptoms from a list. It turned out that some users did not necessarily
localize their symptoms in the same way as the app (for instance, users localized “fever”
in the head, whereas the app thought it was a general symptom that apparently had no
mapping on the body). Again, just using a regular list interface would probably be more
effective in this situation.
Motor Trend, an app for car-related news, had a unique homepage that fits the profile of
the app – the homepage resembled a dashboard, with different controls corresponding
to different topics. The mapping was quite simple, and, since the only task available to
the user was selecting one of the topics, it worked.
Finally, Pizza Hut allowed users to customize their pizza by dragging toppings on it. It
was very intuitive (all our participants quickly figured it out) and mirrored the real-life
process. Unfortunately, Pizza Hut also had a screen where people were asked to “select
toppings and tilt phone left or right to customize.” None of our participants understood
what they were supposed to do and what the outcome was supposed to be: although
they all tilted their phones, none checked the different toppings to indicate which of
them will slide on half the pizza. One departure from the real-world mental model
caused the app to fail.

(a) Urban Spoon app for (b) Web MD app for (c) Motor Trend app
iPhone iPhone for iPhone
(d) Pizza Hut app for iPhone
Apps with immersive elements.
The Barnes and Noble’s Nook for Android used a page-turning animation, presumably to
follow the real-time image of a turning page and to make the app more similar to a real
book. One participant commented:
“Here you get all that turning of the page, which I guess, esthetically [it’s
pleasing] – but to me, I just want to read, ‘cause you don’t have very much
on the page, so when I want to get to the next page I don’t want to wait for
this [animation].”
That’s what the problem is with many immersive elements: they should make the app
esthetically pleasing AND not get in the way in doing so.

INPUT
193. Use the phone features (camera, GPS, voice recognition, accelerator,
etc.) to let users input text faster.
We’ve already seen that, even on the Web, it is possible to use the GPS to detect the
current location and save users the trouble of typing a city or a zip code (see guideline
45). (Sometimes they may not even know the local zip code – if, for instance, they are
in an unfamiliar location.) Applications have no excuse for requiring users to type in
their location. (However, as explained in our guidelines about locators, users should be
able to also enter a location different from their current one – see guideline 140).
Most phones come with other features that can be used to speed up user input. The
camera can easily be used to take a picture of an object or of a barcode; that picture or
barcode can be decoded and information about it can be quickly displayed. There is a
plethora of apps that use barcode scanners: some, such as RedLaser and Bar Code
Scanner are specifically for reading barcodes and searching prices for the corresponding
products, but many other apps (e.g., Target, Amazon) included a search-by-barcode
feature. Amazon and Best Buy allowed users to search for information about an object
by taking a picture of it. (Unfortunately, that feature can be unreliable. A picture of a
bracelet was recognized as an egg ring by Amazon).
(a) Grocery IQ for iPhone (b) Best Buy for Android
Apps such as Grocery IQ ((a) – a shopping list app) and Best Buy ((b) – an e-
commerce app) used the built-in device camera to recognize barcodes. Best Buy even
allowed users to take a picture of an object and search for it.

We see more and more paper magazines and desktop websites featuring QR codes, and
more and more users taking advantage of them to quickly access a website. A study by
Comscore determined that 6.2% of the total US mobile audience scanned a QR code on
their mobile device during the last month. While a lot of the time the scanned codes
were printed on paper (either in a magazine or on product packaging), 27% of the
people scanned QR codes from a PC website 20.
mgmresorts.com (full site on PC)
QR codes help users find the apps more easily.
We definitely encourage QR codes as a way to deliver information about a topic or a

product with little effort on users’ part. Here’s a quote from one of our participants:
“[I use QR codes] even in magazines – you know, a lot of magazines have it.
Just shopping and seeing something … if I want to get more information than
what I can see on it, I just hit the website and go.”
Voice recognition is well integrated in most Android apps: it’s easy to say a word and
have the phone recognize it. The iPhone is still behind in that respect. Although most of
20
Comscore, Aug 2011.
http://www.comscore.com/Press_Events/Press_Releases/2011/8/14_Million_Americans_Sca
nned_QR_or_Bar_Codes_on_their_Mobile_Phones_in_June_2011

our users declare that they use the voice recognition feature only occasionally, it is still a
fast way of inputting text that can be useful in mobile situations.
(a) Amazon app on Android (b) JC Penney app on Android
Android apps have voice recognition as part of the keyboard. Any app can use this
feature in a text-entry context.
194. Group related controls.
195. Place the Submit button under the form rather than at the top.
One of the principles of Gestalt psychology is the law of proximity, which says that
people tend to perceive elements that are close together as related, or part of the same
whole. Conversely, things that are far apart are perceived as separate or unrelated. In
interface terms, widgets that are far apart will be considered unrelated, whereas those
close together look connected.
Take advantage of this law, and make sure that all the buttons relevant to completing a
task are placed in the same region of the screen, close together. Because the screen is
so small, one might argue that the law of proximity does not count, since everything is
close on a phone screen. Wrong! While it’s true that the problem is even bigger on a
larger tablet screen or on a computer, we’ve witnessed many cases where people had
difficulty finding the right button because it was “out of the way”.
One situation where we’ve seen this confusion arise is in the placement of the Done or
Cancel button (or Submit in forms) in the top right corner of the screen. This is a pattern
that has been started by Apple in some of their apps – for instance, in Mail.

Mail app for iPhone
The Done and Cancel button were ungrouped with the other buttons that are related to
the task (Delete and Move).
In Mail, however, the Cancel and Done buttons are not the most important ones with
respect to the task they support (which is deleting messages). Moreover, one could
argue that, in the case of Mail, the button at the top applied to the entire view
(essentially, it quit the current view), rather than to one individual message, in which
case it was ok to place them at the top.
In the examples below (Quickoffice and Best Buy), the Done and Submit buttons were
essential, because they need to be pressed to complete the task. Moreover, they had a
strong spatial and/or temporal connection to one other area of the screen: they needed
to be pressed after the user has been actively involved in using the widgets at the
bottom of the page.
In the Quickoffice app, the task was to format data. Once users selected their choices in
the work area at the bottom of the screen, they had to press the Done button at the top.
A typical reaction in these circumstances is “What do I do next?”, because people expect
that all the buttons for the same task to be grouped together.
In the Best Buy examples, users who filled in their information needed to press the
Create button at the top in order to get their form submitted. Unfortunately, that
placement is against the natural flow of filling in the form: when they were done with all
the fields of the form, users were at the bottom of the page and they’re left with nothing
to do next. Looking for and finding the Create button required some unnecessary extra-

effort that could have been spared if that button had been placed at the bottom of the
page, under the last field, as it is customary on most forms on the desktop.
(a) Quickoffice for iPhone (b) Best Buy for iPhone
The working area was disconnected from the buttons that submitted the form, which
were placed at the top of the screen.
196. Do not use spin wheels for items that don’t have a natural order.
In a spin wheel, values in a list are projected on a circle: the first element follows the
last one. For digits from 0-9, users can easily see that they’ve got through all the
options if they reach small numbers after big numbers. In other words, there’s a natural
order that helps them figure out with practically zero effort that they’ve exhausted all
the values in a list. However, if, instead of digits, the values are “previous orders”,
“most popular”, “pizza”, “pasta”, “wings”, “sides and desserts”, “drinks”, “specials”,
users must remember them in order to check whether they’ve seen them before and
have gotten to the end of the list.
It’s a lot easier to use a tabular view for lists like that: the end of the page is the same
with the end of the list.

Pizza Hut for iPhone
The spin wheel was not appropriate for a list of items with no natural order.
197. Do not use sliders for inputting precise values. Only use sliders when the
exact value is not important.
Sliders are good in situations where an exact value is not important, but they are hard
to use when you need to indicate a precise value: users have to go back and forth to
make sure they get the exact value that they need. They’re also not recommended if the
range of values is very big: (a) because the app will often need to compress the slider
(as in the case of Zillow, below) to span the entire range, making it harder for users to
hit an exact value; and (b) because, even if the app doesn’t compress the range (as is
the case with the Libra app below), there needs to be a lot of scrolling to reach the right
value on the slider.
Zillow asked users to enter a max value for their home price by using a slider. House
prices are definitely a domain where the exact value does matter: there’s a difference
between looking for a house of $1 million versus one of $900K. It would have been more
appropriate to just ask the user to enter their price, instead of having them fiddle with
the slider.
Libra allowed users to track their weight; in order to enter their weight on any given
they, users needed to move around a slider that showed increments of 0.1 pounds. By
default, the slider was positioned at 161 lbs. Imagine how much one would have needed
to slide if their weight had been 130lbs or 200lbs!
In contrast, Kayak appropriately used a slider for entering flight departure times in a
flight search engine: most users don’t care for the exact time, but for a range (late
morning, early evening, etc.). With the slider, they can indicate that quite easily. In this
situation, it’s ok to use a slider for time, but if the context were entering an appointment
in a calendar app, a slider would not be appropriate (because there the exact time to the
minute is precisely what matters).

(a) Zillow for Android (b) Libra app for Android
Inappropriate use of sliders: (a) Max house prices in a real estate app. (b) Weight
in a weight-tracking app.
Kayak for iPhone
Appropriate use of sliders: the flight departure time doesn’t need to be precisely
indicated when users search for a flight.

MODAL DIALOGS AND ALERTS
198. Include a Cancel button in a modal dialog.

A modal dialog is a dialog that must be addressed before users can interact with any
other interface elements outside that dialog.
Although on phones with a physical back button, that button typically dismisses the
modal dialog, unfortunately that is not always the case (For instance, in an older variant
of CardioTrainer app, users were prompted to download a game; the only way to get out
of the download was to press the physical search button). Moreover, when there’s no
alternative in front of them, users have to problem-solve and think what they should do
next.
(a) CardioTrainer for Android (older) (b) Astrid for Android
Modal dialogs on Android. (a) The lack of a Cancel button was confusing: users had
to figure out what to do to dismiss the dialog. (b) Users who accidentally pressed
the color-theme setting could close the dialog by pressing Cancel.

REGISTRATION AND LOG IN
199. Within apps, do not ask people to register to save information (e.g.,
favorites).
In an app, it’s easy to store favorites on the phone. Users should be allowed to sign in or
register in case they want the information on the phone to be synced with a desktop
site, but they should always be explained this benefit of registering and allowed to opt
out if they don’t want it. As discussed before, registration and login are painful on
mobile, and users shouldn’t have to go through any of them.
In the examples below, both apps showed users content without having them log in.
However, while All Recipes let users save their recipes on the phone without registering,
Livestrong required sign up in order to store users’ data: that should not be necessary!
(a) Livestrong app for iPhone (b) All Recipes app for iPhone
(a) Livestrong required users to log in to store their data. (b) All Recipes allowed users
to save favorites without login.
One of our Hong Kong participants was using Open Rice – an app similar to Yelp that offers
restaurant information. He wanted to save a restaurant in his list of favorites, but,
unfortunately, the app required him to have an account to do so. He tried to create an
account, but he discovered that there was an account associated to his email, so he had to

recover his password and log in, after spending a lot of time trying to register again. Here is
a screenshot from his session:
Open Rice app for iPhone
In order to add a restaurant to his favorites, users had to have an account.
200. Place both the Sign In and Register buttons under the login form, one
next to each other on the same line.
This guideline derives directly from the law of proximity and from guideline 167. We’ve
seen countless users clicking the wrong button when they needed to sign in or register.
Invariably, users who don’t have an account end up signing in and, vice versa, users
who have an account end up registering. The problem is typically that the two main
options (register and sign in) are not given the same priority, and users just pick the
one that is more salient.
When presented with a sign-in form, most users don’t think of whether they already
have an account – they just put in an email and password and click Sign In. To quote
one of our users:
“I always forget creating an account.”
A participant was using an older version of FedEx that looked as in the screenshot
below. He created an account the first time he used the app, but then, when he tried to
log in with his new account, he kept clicking the Register button and being taken back to
the registration process. The register button was under the login form, while the login
button was farther away, in the top left corner.

(a)FedEx app for iPhone (older) (b)FedEx app for iPhone (newer)
In an older version (a), FedEx placed the Login button at the top, and the Register
button under the form fields. Because the Login button was far away, customers with
an account would not notice it and press the Register button, and be asked to register
again. The newer version (b) solved some of the problems. The Login button was still
at the top, but, by default, the action associated with the form is log in (rather than
register, as in the older variant). Thus, the Send button on the keyboard automatically
submitted the form, without users having to press the Login button at the top. And the
New customer link under the form was highly salient, (although it did not look
clickable).
Redfin below directed users automatically to the sign in form. The option to join was
presented as a tab at the top. This design suffered from the same problems as the older
variant of FedEx, but it hurt first-time users rather than account holders.

Redfin app for Android
Participants using this app ignored the tabs at the top and signed in even though
they did not have an account.
The correct solution in this situation should give equal priority to both sign in and
register.
Unfortunately, just putting the Register button under the Login button (like Best Buy did
in the example below) doesn’t always cut it: users tend to press the button right under
the login form, without bothering to notice that there are more options below. The
design used by Big Oven is the preferred one, where the register and login options are
placed next to each other.

(a) Best Buy on Android (b) Big Oven on (c) Big Oven for iPhone
Android
(a) Placing the Register button under the Login one makes it less salient and is not a
good strategy for minimizing user errors. (b)-(c) Big Oven placed both buttons next
to each other, making it easier for users to pick the right choice.
NOTIFICATIONS
201. Do not ask people to accept push notifications the first time they launch
an app.
When users have just downloaded an app, they are unlikely to know what the app can
offer and what kind of notifications they can receive from the app. It’s wrong to have
them decide if they want notifications – at that time they have not enough information
to take a decision. In fact, most of the users we’ve seen denied that request.

(a) Groupon app for iPhone (b) Groupon app for Android
(a) Groupon asked users to allow push notifications before they got a chance to use he
app. (b) By default, sound notifications were turned on.
202. Avoid turning on sound notifications unless people explicitly turn them
on.
If users allow push notifications as in the Groupon example above, make sure you don’t
turn on sounds, too. Enable sound notifications only when users explicitly agree to that
(i.e., they say they want sound notifications, not just “push notifications” in general).
Most users don’t realize that by accepting push notifications they may have turned on
sound notifications as well and may not appreciate being waken up in the middle of the
night by a new news story or by a new offer.
203. Make sure that people can easily turn notifications on or off.
204. (iOS) Do not ask users to go to the iPhone Settings to turn on

notifications. Allow them to turn notifications on within the app.
Users should not be stuck with receiving notifications from an app if they no longer need
them, nor should they have to be denied forever the opportunity of receiving
notifications if they said “no” one time. The best place for opting in or out notifications is
the settings section of your app. Don’t make users go to a global notification setting to
turn notifications on or off – most users are not aware of that feature of the phone and
expect to be able to turn on notifications within the app.

(a) Global Settings app (b) The Carrier app for (c) MLB At Bat app for
on iPhone iPhone iPhone
(a) On the iPhone, it is possible to control all the notifications sent by different apps in
the Settings app. (b) The Carrier allowed users to enable notifications within the
app. (c) MLB At Bat instructed users to go to the Settings app and enable
notifications. Unfortunately, users had to understand and memorize those
instructions, and then execute them. Instead, the app should have let them directly
turn the notifications on or off.
TAB BARS AND TOOL BARS

Tab bars are normally used for navigation. Tool bars contain buttons that act upon the data
on the page.
On the iPhone, the tab bars and the tool bars are traditionally placed at the bottom of the
page. On Android, a clear convention has still to arise: we noticed that some apps follow the
iPhone standard and put them at the bottom, whereas other apps locate them at the top.
Over time, we noticed a tendency for Android apps to look more like iPhone apps – possibly
because companies unify the high-level design of the apps across different platforms. If that
is the case, we expect that locating tab bars and tool bars at the bottom of the page will
become the standard on Android, as well.

(a) Amazon app for iPhone: tab bar (b) Mail app for iPhone: tool bar
(c) Fidelity app for Android: tab bar at (d) J.C. Penney app for Android: tab
the top bar at the bottom
Tab bars and tool bars.

205. Do not have more than 5 items in the tab bar/tool bar.
This guideline has a very simple explanation: once you crowd more than 5 items, they
become too small and they are harder to touch (see also guideline 164).
206. Only functions less essential to your app should be under the More tab.
207. Do not hide search under the More tab.

When using a tab bar, the standard solution for dealing with more than 5 navigation
options is to use a More tab, where all other options are buried. When we talked about
menus (guideline 52), we said that the risk of using them is low discoverability of
options under the menus. The More tab is, in fact, a menu. Unlike some other menus, it
does a good job of signaling the users that it is a menu, because people know there is
something underneath. (That being said, the label More is not very distinctive – almost
everything can hide there. Well labeled menus can have better information scent.)
However, as in the case of menus, the options hidden under More have low
discoverability: users must think to explore that section of the app.
Because of that, do not put functions central to your app under the More tab. Search, for
instance, should not be there. One of our users was looking for a cleaner in an older
version of Target’s iPhone app. In that version of the app, search was under More; she
never found the search box and had to use the category structure to find the cleaner,
putting herself through the ordeal of guessing under which category the cleaner could
hide. Since then, Target has fixed their app several times and has given search a more
prominent place. But other apps (e.g., Crackle) make the same mistake.
(a) Target app for (b) Target app for (c) Target app for
iPhone (version 1) iPhone (version 2) iPhone (version 3)
Three versions of Target. (a) Initially, the search was hidden under the tab More.
(b) Next, search was visible in the tab bar, but the store locator was under More.
(c) Finally, the tab bar was replaced by a pull-up menu with lower discoverability,
but the search box was prominent on the screen.

Crackle for iPhone
Search was hidden under the More tab.
208. When you have many navigation options, consider using a list or a grid
instead of a tab bar.
Instead of trying to be creative and fit more items in a tab bar either by using a pull-up
menu (like Target) or a carousel (like The Weather Channel), sometimes it’s better to
just fit all the navigation options on the screen, in a tabular or grid format.

(a) Banana Republic (b) Redfin for iPhone (c) Sephora for iPhone
for iPhone
Tabular displays (a)-(b) or grid displays (c) work well for multiple navigation
options.
TASK FLOW
209. Make the task flow as simple as possible. Include only the actions that
are essential for accomplishing the task.
Most of the time when users are on mobile, they don’t have time to deliberate complex
decisions: they want to achieve their goal as fast and with as little thinking as possible.
All the actions that are not vital for the task should be optional (or even left out).
Moleskine lets users take notes on their phone. To create a new file, one had to first
name the file, select a category for the file, attach a color to the category, attach a
visual label to the category, select a pen type, and finally type. That is a lot of work –
and most of it is extraneous to the task of taking a note. Whereas classifying notes and
color coding them may be useful on the desktop, it is less likely to be so on the phone,
where many people may not actually take so many notes as to need fine classification.
All these actions should be optional, or even better, nonexistent, and the users should
not have to deal with them before adding information to the file. These actions get in the
way of the users’ accomplishing their goal.
(We did not test this app on the phone, but we tested the same design on the iPad.
None of the users who tried this app on the iPad were able to figure out how to create a
new file and add content to it.)

Moleskine app for iPhone
The task flow for creating a new file and adding content: users had to create a new
category, choose a label and a color, and choose the text attributes, before they got to
actually type.
PROGRESS INDICATORS
210. Whenever your app is downloading content, show a progress indicator.
211. Prefer progress bars to spinning gears or other indicators that don’t
show real-time progression.
212. For larger downloads (e.g., videos, magazines), give users an estimate of
how long the download it’s going to take.
The main job of progress indicators is to tell users that something’s going on and that
the app is working. When users don’t see a progress indicator, they have no way of
knowing whether the app is stuck, whether there’s a network or a phone problem (and
they’d be better off postponing the task), or whether the app is making progress.
We definitely recommend progress bars over spinning gears or other indicators that
don’t show some measure of how much work has been done and how much is left. Users
also often express their preference for progress bar.
Some apps use progress bars only for tasks that they expect will take longer. The
problem is that, if the app gets stuck, a task that was supposed to take 2 seconds may
take forever, and users may have no idea that there is a problem with the app.

(a) New York Times app for iPhone (b) Netflix app for Android
(a) NYTimes showed a progress bar, allowing users to estimate how much content
is left to download. (b) Netflix showed a spinning gear, leaving users little
indication of how much work is left or whether the app is stuck.
Ideally, the progress indicator should tell users how much time has elapsed and, most
importantly, how much time they still have to wait. Even an estimation of those amounts
can be useful, since it can let users know whether they have the time to wait or not.
INSTRUCTIONS AND HELP
213. User manuals are not useful, nor should they be necessary on mobile.
214. Users cannot read the help and use the app at the same time.
215. If you decide you absolutely need a user manual, make sure that it’s
easy to read.
Whenever you are seriously thinking to provide interface “tutorials” about people should
use your mobile app, think again! When users are asked if they want to read user
manuals, they always say “no” (and often laugh). If you app needs a user manual, it’s
probably too complex for mobile.
Users may seek out help when they are confused and really motivated to use your app.
The last condition is rarer in the real-life than in a user-testing lab: in usability studies,

we sometimes push people to finish a task that they would have given up in real life. So
they are slightly more likely to seek out help. But even then, we don’t see users doing it
very often.
Part of the problem with help on mobile is the single window issue that we’ve
encountered before in the iHandy Level app (see discussion under guideline 163): users
cannot study instructions and apply them at the same time, as they could do on a
desktop. Because of that, they have to memorize the instructions and then use them,
which puts quite a load on their working memory. If the instructions are also poorly
written or formatted (like it was the case with Sit or Squat – see below -, which used
tiny commented screenshots for their “tutorial”), their task is even bigger.
That’s why user manuals are pretty much useless on mobile: they contain a lot of
information that users must memorize. At most, user manuals can be entertaining (like
the one put together by Marvel Comics), but users cannot be expected to remember
more than one or two things from them at best. Contextual tips (that are presented
ideally exactly when the user needs them) can be much more effective.
Sit or Squat app for iPhone
Sit or Squat invited users to read their “tutorial”, which was an explanation of the
different interface widgets in a hard-to-read format.

Marvel Comics for iPhone
The user manual was itself a comic; however, even this “fun” format cannot ensure
great memorability of the material.
216. Meaningful, contextual tips can be helpful.
217. Do not flood users with tips.
218. Present tips when the app is launched or when data is loading.
219. Allow users to disable tips.

In user testing, we noticed that, overall, tips are more effective than user manuals.
Some users don’t read tips, but some do – our observations suggest that tips are more
likely to be read if (a) they are related to the task that users are attempting at the time,
or (b) they appear at a time when the user is waiting for a download or some other
event.
Tips that are too obvious or too general hold little interest for people, and make them
more likely to distrust and ignore further tips. Also, tips that occur too often tend to be
annoying, so users may start dismissing them more quickly.

(a) Stanza for iPhone (b) Aldiko for Android
Tips. The tip in Stanza (a) was less useful than the one in Aldiko (b).
(a) PS Express for iPhone (b) Stanza for iPhone
Contextual tips. (a) When users selected the “Saturate” menu item, a tip
appeared, telling them how to do it. (b) When users started a new book, a tip
appeared, telling them where to tap.

For those power users who have learned the interface too well, there should always be a
way to opt out of tips. That’s why it’s good practice to show users the option “Hide tips”
whenever a new tip is presented.
In the example below, Macy’s used a pull-up frame to offer help; unfortunately, the
information presented had no relation with the current screen.
Macy’s iShop app for iPhone
The information presented in the pull-up frame was not relevant to the current
screen.
INITIAL EXPERIENCE
220. Keep launching time to a minimum.
221. If users must wait for more than 20 seconds, give them something to do
while waiting.
On mobile, users have little patience for long downloads. We noticed that, in the lab,
they are willing to wait at most 20 seconds for a piece of content that they know is big
(e.g., a magazine issue). If you keep them waiting for more than that, they become
impatient and are very likely to leave the app.
In that situation, progress indicators that keep users informed of the state of the
download are a must (see guidelines 182-185). Moreover, showing users a preview of
the content that is loading or even some tips can keep them engaged with the app and
can make them feel that they’re not waiting for such a long time.

222. Don’t use a launch screen if possible.
223. If you must use a launch screen, make it similar to the first screen of the
app.
On mobile, it is important for users to get to what they’re trying to do as soon as
possible. Launch screens are just unnecessary obstacles – users don’t care for them,
and, as they use the app more and more, having to sit through a few seconds where
they cannot use the app is simply annoying.
That’s why we recommend that you avoid launch screens whenever possible. If your app
needs some time to load, we recommend showing a launch screen that’s as similar as
possible to the first functional screen of the app (for instance, that could mean showing
the interface with no content, like BBC did in the example below). This minimizes the
cognitive effort for the users: they don’t have to process a new screen once the content
has loaded, and can use the extra launching time to familiarize themselves with the
interface.
Target app for Android Epicurious app for Android
Launch screens do not bring any value to the user and they can give the feeling
that they slow the app down.

(a)BBC News app for (b) BBC News app for (c) Best Buy for
Android: Launch screen Android: first screen Android: Launch
for BBC News screen
Launch screens that are similar to the first screen make the experience seamless
and give users time to get used to the app.
224. Don’t start with a video or a sound effect.

Users don’t expect sounds when starting a new app – they’re often startled by the
sounds, at best, and annoyed and disturbed, at worst. (Mobile usage can happen
anywhere, and apps should be particularly cautious with noises – think about a sudden
noise in the middle of a meeting or late at night, when everybody else in the house is
asleep).
My TSA makes a noise once the app is launched. One of our users was surprised and
wondered what the noise was. Al Gore’s Our Choice starts with a video of Al Gore the
first time the app is launched; on subsequent sessions, it plays music while downloading
the data.
225. Preload data for the first launch.

When users have just downloaded your app, you have to entice them and convince them
that your app is worth keeping and using. Don’t make them work by asking them to
download content or to register – show them how great your app is by having them
check some preloaded content. Book-reader apps such as Stanza and Aldiko come with
1-2 preloaded books that give users a chance to try the app and see if they like.

(a) Stanza for iPhone (b) Aldiko for Android
When people used these apps for the first time, content was already preloaded so
they could see how they like the app without having to work to download it.
226. Update data for the users.
227. Don’t ask users to delete an app and install it again.

This is an instance of a basic usability principle: do as much work for the users as you
can. Asking users to delete a book and then download it again requires them to put in
too much effort – they’ll have to find the book in the store again, possibly enter their
credentials, and wait for the content to download. It’s so much easier if the app allows
them to skip at least some of the steps and does the update for them.
It’s even worse to ask users to circumvent the regular application update process and
delete the app, then install it again. Unless users deeply care about your app, they are
very unlikely to do so.

(a) iVerse Comics for iPhone (older) (b) Fluent News for iPhone
Do the work for the users: don’t ask them to delete a book or an app, and then re-
load it.
228. Save state: if users come back to an app, continue the session from
where they left.
Interruptions occur often on mobile: something may happen in the environment and the
user may be required to switch attention from the app, or another app may demand
user’s attention. Because of that, your app should be prepared to offer the illusion of
continuity by saving state and allowing users to come back to where they left last time
when they used the app.
Sometimes users make accidental touches that cause them to leave the app. For
instance, on the iPhone, many users sometimes touch the physical home button without
meaning to leave the app. On Android, they sometimes hit the back button and, if not
correctly implemented, that can take them outside the app. All these touches are
unintended, but they still happen. If that’s the case, you want users to be able to go
back to the app and start where they left.
Best Buy started a new session each time the app was launched. This is highly
unproductive – all the work that may have been recently put into the app is lost if a
phone call happens to occur in the middle of the session.
One of our users was trying to make a restaurant reservation using Open Table for
iPhone. He got to the restaurant page, and accidentally hit the home button. He then

started the app again, but, unfortunately, he discovered that he had lost his restaurant
page and had to find it again.
HYBRID APPS
Some apps occasionally send the user to their website – they are called hybrid apps.
229. Do not send users to a full website from an app.

Often the first reactions of users who are sent to the browser by an app is a sigh. Users
consistently say that they prefer apps to websites and they use them more, and part of
the reason is that the websites are much more inconsistent in terms of user-experience
quality: many of the sites visited on mobile are designed for the desktop, and, hence,
they are hard to use. Even the mobile sites are sometimes lacking essential content.
Therefore, users expect to be disappointed when they have to go to the Web.
Because of that, it’s important to make the transition from app to browser seamless. In
some well-designed cases, users didn’t even realize they were taken to a website.
(a)Page Once for iPhone (older) (b) Page Once for iPhone (newer)
An older version of Page Once explained their data security policy by taking the
users to a full website. (b) The newer version showed users a mobile-formatted
page.

ESPN Score Center for iPhone
Clicking on a news story led to the webpage for the article source. Some of the
pages were formatted for mobile (upper right), but some were not (lower right).

230. If the app takes the user to an in-app browser, don’t present an ad for
the same app again.
One of our users was trying to shop for a moisturizer using the Walgreens app for
Android. The Shop link in the app took the user to the Walgreens mobile website.
Unfortunately, when the user clicked the link Home to get back to the app’s homepage,
she was sent to the mobile homepage. The first link on the mobile homepage was an ad
for the Android mobile app. Our user was utterly confused by the ad for the app within
the app.
Walgreens app for Android
Because the Walgreens app deferred users to the website for the “Shop” section, when
users clicked on “Home”, they got to the mobile homepage for Walgreens, which
advertised the Walgreens app. Our users were confused by the ad for the app that was
apparently present within the app.

PHYSICAL BUTTONS ON PLATFORMS OTHER THAN IOS
iPhones have a single physical button: the home button. Other platforms, however, have
the benefit of other physical buttons (besides home) available to them. Android phones
have a back button, a search button, and also a menu button. Windows Phone 7 phones
have a back button and a search button.
In theory, these buttons save precious screen space: applications can take advantage of
them and hide interface widgets under these buttons. For instance, the application search
box could be hidden under the search button. The navigation choices could be hidden under
the Menu button on Android. And so on so forth.
Unfortunately, in practice, the buttons are a blessing and a curse at the same time. It turns
out that there is no good consistency among apps regarding the use of these buttons. Some
apps ignore them completely and follow an iPhone design (sometimes, it is literally an
iPhone design, because companies didn’t want to spend any extra cycles figuring out a
design specific for these other, newer platforms). Some apps use them, but each defines
their own usage.
All these reasons plus the lower discoverability of these buttons (they are not part of the
screen, so users must remember to use them) make at least some of them less used in real
life.
Because of that, apps are forced to replicate some of the functionality of these buttons on
the screen. If search is central to your app, we recommend placing a search box on the
screen, so users can easily find it. Main navigation options are also better off on the screen,
rather than under the menu button on Android: users will find them more quickly. Keep the
menu button for things such as settings and other features that are less central to your app.
Although part of the original intent of this buttons might have been to make them
contextual (i.e., to assign to them different functions, depending on the app context in
which they were pressed), we don’t advise using them that way. The truth is that human
memory needs practice and is susceptible to interference, and, by changing how these
buttons work within the app, we deny users opportunities of learning what these buttons do.
Instead of just remembering what they do across the app, users must now remember the
pair (action, context) associated to each button. If there are several possible contexts, the
potential for interference is created.
231. Always make sure that the back button works as supposed to: (a)
dismisses dialogs; (b) moves back to the previous page within the app (or
to the previous app if the current page is the first visited during the current
session).
From the three buttons, the back button is used the most. Even that button is
unfortunately not used consistently across apps. Plus, the back button has at least two
meanings: dismiss a menu, and go back to the previous page. The context of use also
plays a role: for instance, in the browser, the back button takes you back to the
previous app rather than to the previous website that you may have visited in an
anterior session. Moreover, sometimes users have to dismiss a menu using a back
button, but sometimes just touching elsewhere on the screen performs the same action.
Guideline 170 gives an example of improper use of the back button.

232. (Android) Avoid migrating toolbars and tab bars under the menu button.
233. (Android) Avoid changing menu button functionality within the app.
234. (Android) Consider putting only non-essential options under the menu
button.
We talked before why hiding important features under the menu button makes those
features less discoverable. While less crucial features may migrate under the Menu
button, anything that is vital to the completion of the main app task should be visible on
the screen.
Changing what the menu button does within the app is confusing. Some users may not
realize that the menu button behaves differently in different circumstances, and not
press it, thinking that the functions that were discovered on a different page are
irrelevant on the current page. And, as mentioned above, even if they pressed and
discovered a different set of functions, keeping track of that functionality may be too
hard.
Astrid app for Android
Astrid used a contextual menu button: the button brought up different options
depending on where in the app it was pressed.

Amazon app on Android Edmunds on Android
Main navigation options were hidden under the menu button.
USA Today app for Android BBC News app for Android
Only less important (or redundant) options were hidden under the menu button.

235. Whenever search is central to an app, include a visible search box on the
screen.
Using the same argument as before – out of sight is out of mind. Apps where people are
most likely to perform a search should include a visible search box on the screen.
We witnessed several participants who did not think of using the search button in the
Windows Phone 7 Market, and were trying to find a specific app just by browsing.
Target for Android Ebay on Android
Both apps include a visible search box on the screen.

Windows Phone 7 Marketplace
Users had a hard time discovering that they had to press the physical “Search”
button in order to search for an app.
236. Use the search button to search within the app rather than the Web.
Although users might not think right away of using the search button, there’s one
instance when they do expect contextual behavior from it: when they press it within an
app, they expect to be able to search within the app, rather than to search the Web.
Apps that don’t have any functionality attached to the search button should take
advantage of it.
The search button is especially a godsend for browsing apps: these apps don’t need the
search box to be visible, because most users don’t use it. However, having the search
box under the search button can help users who may need to find a specific piece of
information, without encumbering other users.

(a) New York Times app on Android (b)Amazon app on Android
(a) NYT did not take advantage of the search button. Users could not search within
the app – the search button initiates a Web search. (b) Amazon correctly
programmed the search button to search within the app (and they also showed
the search box on their homepage).
237. Don’t make the search button contextual. The scope of the search should
be the same across the app.
Making search apply only to the information or to the set of data referenced on a given
page is very dangerous, as users may not realize that what they are searching through.
One of our users was working with an older version of Aldiko. The homepage on Aldiko
showed the user’s library, so he pressed the search button to search for a new book:
“The Adventures of Sherlock Holmes”. The app returned zero results, to this user’s
surprise. It turns out that the search on that page was actually done on the items that
were in the library, so it was no surprise that he got no results. Had the user gone to the
store, he would have gotten several books with the words “Sherlock Holmes” in the title.
In newer versions, Aldiko fixed this problem: the search button properly searched both
the library and the store, and showed the results neatly grouped by category.

search
Aldiko on Android (newer version)
The search button was no longer contextual in newer versions of Aldiko; instead it
produced the same results throughout the app.

Methodology
The guidelines discussed in this report are based on several studies using three different
methods: diary, traditional usability-testing, and design reviews. Next we discuss each of
these types of studies individually.
DIARY STUDIES
Overview
The purpose of the diary studies was to understand the range of activities that people
perform on their phones. We carried out two separate diary studies: one international and
one in the US. The international diary study involved people from six different countries in
Europe, Asia, Australia, and America, who owned different types of phones (feature phones
and smartphones, including touchscreen phones). For the second diary study, we focused
on iPhone owners in the US.
For the first diary study, we were less interested in usability problems; therefore, we
recruited participants with relatively advanced technical skills and did not impose any of the
typical occupational restrictions that are used when recruiting for traditional usability testing
(e.g., no IT-related occupation). For the second study, we recruited users who did not work
in marketing or any IT-related occupation.
Participants recorded every activity that they did on their mobile phone (except for talking
or text messaging) for one to two weeks. At the end of each day, they completed a
questionnaire that detailed the context of each of the mobile activities that they had
performed during the day. Users commented on:
• Where and when they had done the activity
• What they were trying to accomplish and whether they were successful
• What kind of websites or applications they had used to accomplish the activity
• Whether they had encountered any problems or had any comments about their
experience
At the end of their participation in the diary study, we conducted a short interview with the
participants over the phone. In the second study, instead of the phone interview,
participants came to the lab for a regular usability-testing session.
Participants
The first diary study involved 14 different participants from 6 countries (Australia,
Netherlands, Romania, Singapore, UK, and USA). The second study involved 13 participants
from USA. The table below shows the country and occupation of each participant, as well as
the number of days they participated in the study.
DAYS OF
COUNTRY OCCUPATION PARTICIPATION
First study
Australia Business administration 6
Australia Market research 4
Australia Director of community innovation 7
Netherlands Self-employed 10
266 INFO@NNGROUP.COM Methodology

Netherlands Student 7
Romania Business administration 6
Romania Director 6
Singapore Engineer 6
Singapore Bank executive 7
UK TV producer 3
USA Bookkeeper 6
USA Director 5
USA System administration 8
USA Sales 6
Second study
USA Sales manager 7
USA Controller 7
USA Administrative assistant 7
USA Clinical specialist 7
USA Football coach 7
USA Reading Instructor 5
USA Public safety officer 7
USA Elementary teacher 7
USA Probation officer 7
USA Homemaker 7
USA Operations support 7
USA Student 3
USA Classroom tech specialist 7
Method
We instructed participants to create an account on twitter.com (henceforth called Twitter).
Twitter is a microblogging service that allows each user to post short messages; the
messages are further broadcasted to all other Twitter users who opted to receive updates
from that particular user (i.e., to “follow” that user).
We followed each of the diary-study participants on Twitter. We instructed the participants
to send a tweet each time they used their mobile phone for a nonvoice or nontexting
activity. At the end of each day, participants completed a questionnaire that targeted the
context of the mobile activities that they had done during the day. These are the questions
used in the questionnaire:
1. Date and time of activity (include AM or PM)
2. Where were you at the time?
3. What were you doing at the time?

4. What did you do (visit a website, send an email) and what were you trying to
accomplish? Please be specific.
5. What website or application did you use? For a website: how did you get there: did
you use bookmarks/favorites, search, typed in the URL, clicked on a link, or some
other method (specify)?
6. Have you used that phone application or website before (on your phone)?
7. If applicable, why did you go to this particular site/app versus another similar
site/app? Please be specific.
8. Did you accomplish what you wanted to do at the time? Why or why not?
9. What did you like about the site/phone application? We are interested in anything that
made it easy for you to accomplish your task. List and briefly explain each thing that
was easy to use or that you liked.
10. What did you dislike about the site/phone application? Think of anything that made it
hard for you to accomplish your task. List and briefly explain each thing that was hard
to use, confusing, or that you did not like.
11. Any other comments?
In the first study, participants emailed the responses to the questionnaire. In the second
study, we used Google Spreadsheets to generate a form that was filled in by the
participants each day.
USABILITY TESTING
Overview
We carried out eight separate usability-testing studies over three years. Five of the studies
took place in the US; the other three were done in Australia, Hong Kong, and the UK. All of
these were traditional usability studies using the think aloud methodology. The purpose of
these studies was to understand the typical usability issues that people encounter when
doing Web-related tasks on a variety of mobile phones (feature phones, smartphones,
smartphones with touch screens). The first two studies involved all types of phones
(feature phones, smartphones, and touch phones). Further studies involved touch phones
only or a combination of smartphones and touch phones. Where applicable, we asked
participants to show us the apps that they had installed on their phones, and then we gave
them tasks to complete involving either mobile apps or the Web. For all the tasks, they used
their own phone.
A moderator sat next to the participant, and observed, listened, and took notes. Users
commented on:
• What they were looking for or reading
• What they liked or did not like about the site
• What made it easy or difficult for them to accomplish the task
Some of the tasks involved specific websites or apps; others were open-ended. We
observed users as they worked and encouraged them to think aloud. As part of the
sessions, we also interviewed participants about their common mobile practices and asked
them to demonstrate some of their favorite sites and applications.
For 7 out of 8 studies, the participants’ interaction with the phone was recorded using a
document camera (Elmo TT-02s). For one study we used the Ovo mobile device camera

mounted on the phone. Both the document camera and the mobile device camera allowed
the participants to hold the phone in their hand.
Each session lasted between 60 and 90 minutes.
Participants and Devices

A total of 105 people participated in these studies, out of which 84 were from the US and 21
from other countries. The studied phone distribution was as follows:
TOUCH PHONES
FEATURE
WINDOWS SMARTPHONES
IPHONE ANDROID OTHER PHONES
PHONE 7
35 19 3 7 27 14
53 participants were males and 52 females. The age demographics was as follows:
20–29 30–39 40–49 50+

35 31 26 13
All participants used their mobile phone several times per week for activities other than
texting or talking. We screened out for technical experts and people who worked in
usability or marketing, since they were not the target users for the sites we tested and tend
to exhibit atypical behaviors due to their expertise.
Following is a sample of participants’ occupations:
• Accountant
• Business development manager
• Business Owner
• Consultant
• Criminal investigator
• Event planner
• Fashion consultant
• Patent Lawyer
• Programme Leader
• Property data analyst
• Real-estate agent
• Recruitment adviser
• Sales engineer
• School counselor
• Staffing manager
• Student
• Television producer
• Travel agent

Method
Each session was divided in three parts:
1. The participant showed the moderator which applications or bookmarks he or she was
using on a regular basis on the mobile device.
2. The participant demonstrated applications or websites that he or she used more
frequently. (The facilitator chose the applications or websites, based on the
information given by the participant at the beginning of the session.)
3. The facilitator gave the participant one task at a time and asked them to carry out
each task as far as they would if they were on their own. The participant was
encouraged to think aloud while performing the task.
4. Some tasks were specific to an app or website; others were general information-
finding tasks (e.g., “Find where the word dollar comes from”).
Each participant saw a subset of the available tasks. The tasks were balanced across
participants so that each task would be performed by participants with all types of phones
(feature, smartphones, or touchscreen smartphones). The order of the tasks was
randomized for each participant.
Materials
The following tables show a sample of tasks that we used for these studies.
GENERAL TASKS (NO SPECIFIC APP OR WEBSITE)

Find the symptoms of swine flu and what you should do to avoid getting sick.
Check the local weather forecast for tonight.

Find out what is on BBC 1 TV tonight at 8 p.m.
It’s 6pm and you need to get from West Kensington to Tufnell Park. You decide to go by
tube. Find out the best way to get there, changing as few tube lines as possible.
Find out which is the tallest building in the world.

You just found the Panasonic digital cordless phone model KXTG1102 in store for GBP 35.
Find out if you can find a better price online.
Find some reviews of the same phone (Panasonic digital cordless phone model KXTG1102).
You are traveling to Berkeley, CA and want to make a reservation at the restaurant Chez
Panisse. Find out what their menu for the week is.
You are playing Monopoly and having an argument with your friend over how many turns
you may stay in jail before you need to pay $50 to get out. Use the internet to find out the
correct answer.
You and your friend are having an argument about the origin of the word “dollar.” Find out
where it comes from.
Use the Web to find out what “carotid stenosis” means.

You are traveling to San Francisco and want to eat out at a restaurant called “Jardiniere”,
close to the San Francisco Opera. Find some trusty reviews of the restaurant.
Find out the most recent NBA (basketball) scores.

Find which movie got the Golden Globe award for best picture this year.
Your friend’s 6-year old daughter has never heard of Tom and Jerry. Find a Tom and Jerry
video cartoon to show her.
You and your friend want to watch the movie “Slumdog Millionaire”. Find a movie trailer for
that movie.
Your friend wants to watch a movie on TV tonight after 8pm. Find a listing of tonight’s TV
program and identify a movie that she may want to watch.
You and your vegetarian friend want to find a good Indian restaurant nearby. Use the Web
to locate one that you may want to go to and that serves vegetarian food.
Find out how to get to the Indian restaurant that you just found.
You are in Chicago, Il and need to call a cab for a ride to the airport. Find a phone number
for a taxi company that operates in Chicago, Il.
How many calories are there typically in a slice of thin-crust cheese pizza? Find out how that
compares with a slice of regular cheese pizza.
WEBSITE-SPECIFIC TASKS
URL TASK
m.lufthansa.com You are planning a business meeting next week in

Frankfurt, Germany. See if you can catch a flight
back to London after 6pm.
Find an Italian restaurant in Soho that has good
qype.co.uk/mobile
reviews.
(or i.qype.co.uk)
Find where the restaurant is and how you can get
there from your current location.
pda.skysports.com Find out the score in the latest football match played
by Newcastle in the Premier League.
Find out the delivery rates for a bouquet of roses
that need to be delivered the same day.
m.interflora.co.uk
Order a bouquet of flowers under GBP 40 for your
friend’s birthday; she should get them tomorrow by
noon (complete all steps before actually making the
purchase).
mobile.bloomberg.com Find the current stock price of Renault (UK).
Homedepot.com Where is the closest Home Depot from your current

location? Find out directions to that store using

homedepot.com.
Use HomeDepot.com to find out how to install a new
faucet.
Where is the closest Nordstrom from your current
Nordstrom.com location? Find out directions to that store and
opening hours using Nordstrom.com.
You want to see the movie “Revolutionary Road”.
Use fandango.com to find out if and at what time it’s
mobile.fandango.com (or playing tonight at a theater close to your house.
fandango.com)
Find some movie critic reviews of the movie
“Revolutionary Road” at Fandango.com.
mobile.wikipedia.org (or Find out where the word “spa” comes from, using the
Wikipedia.org) site mobile.wikipedia.org.
A friend is a fan of the ABC TV show “Lost”. Use

Abc.com abc.com to find out if there are any episodes in Lost
Season 5 that can be watched for free.
You are planning to leave for Paris, France next
mobile.weather.com (or
weekend. Find out what the weather is going to be
weather.com)
like using weather.com.
Use yelp.com to find reviews of the San Francisco
restaurant “Absinthe”.
mobile.yelp.com (or yelp.com) Use mobile.yelp.com to find out a good Mexican
restaurant in Fremont CA.17c. Find directions to the
Mexican restaurant that you just found on yelp.com.
Use espn.go.com to find out if there are any NBA
basketball games that you could watch tonight on
mobile.espn.go.com (or the ESPN TV channel.
espn.go.com)
Use mobile.esp.com to find the latest scores from the
Australian Open (tennis).
You are in an electronics store and consider buying a
Canon PowerShot SD1100IS as a present. The
Adorama.com camera costs $220.25 in the store. Check
adorama.com to see if you can get a better price
online.
You and your friend are celebrating his birthday at

an expensive restaurant. He has chosen duck leg
with duck confit for the main course and wants to
select a Cabernet Sauvignon to go with the dish.
mobile.WineSpectator.com Here is the restaurant’s selection of Cabernet
Sauvignons. Please use mobile.WineSpectator.com to
recommend a wine to your friend .
Look up this bottle of wine in WineSpectator.com.

PLATFORM APP TASK
iOS Find a movie that you may want to watch for next
Friday. Buy tickets to a theater near you (stop short of
Fandango actually buying the tickets).
iOS You have $50 dollars to spend on a piece of clothing

JC Penney for yourself. Find something that you might like.
iOS
Android Find a car navigator for a friend. Figure out if you
Windows Best Buy could buy it online or pick it up in a nearby store.
iOS You have a flight into Chicago’s O’Hare airport. Find

out how many flights arrive on time and how many
departures are delayed at that airport. Can you find
My TSA statistics for last year?
iOS Buy a bouquet of white roses for your friend. (Stop

Android 1800flowers short of actually completing the purchase).
iOS Your friend asked you to buy a Method-brand kitchen

Android cleaner for her. Find out if they have it at your nearest
Target Target.
iOS Check the latest entertainment news. Email a story to

Windows Huffington Post yourself. Can you find any picture-based articles?
iOS
Android Zappos Find a pair of comfortable shoes for yourself.
iOS Find a moisturizer with SPF 30 or above that is

Android Walgreens suitable for your skin.
iOS app.ft.com
(Financial Times Check the latest world news. Read an article that is of
Web App) interest and email it to yourself.
iOS You are in the market for a new car. You want a 4-
Android door car with 5 seats (or more) and a high mileage per
Edmunds gallon. Figure out what options you have.
Android Build an exercise schedule: Mon 30 min running at

8pm, Tue 45 min cardio; Wed break; Thu 45 min
Cardio Trainer weights; Fri break; Sat 30 min running.
Android News and

Weather Check the latest news in technology.
Windows Find a birthday gift for yourself.

Amazon
Android ESPN Score

Windows Center Find the latest baseball scores and news.

Windows Find a movie that you may want to watch for next
Friday. Buy tickets to a theater near you (stop short of
Movies by Flixter actually buying the tickets).
Android You have zuchinni and tomatoes in your refridgerator.

Windows Find a dish that involves both and that you could cook
170,000 recipes tonight. Save the recipe so you could come back to it
big oven easily.
Windows
USA Today Find the latest news-related photos.
Windows
CNN Money Check the latest financial news.
iOS You want to watch "Black Swan" next Saturday. Find a

Android HK Movie(s) movie theater where you can watch it after 7pm.
iOS Buy a pizza of your choice (stop short of actually

Pizza Hut buying it).
iOS Find the current stock value of China Mobile. How did
Android AA stocks the stock change during the past month?
iOS See if you can find any interesting pictures related to

Android China Daily today’s news.
iOS It’s your friend’s birthday and you want to buy her a
nice bracelet under $100. Complete all the steps and
Myer stop just before actually buying the bracelet.
iOS You want to buy some pasta, diced tomatoes and ice
Coles cream. Create a list that contains all those items.
iOS Figure out what the range of prices is for a 3 bedroom

2 bathroom appartment in Melbourne. How about for
realestate.com.au an apartment in this neighborhood?
Android
Australia news Check the latest sport news.
For many tasks, we did not specify where users should go. Thus, the first part of their task
was to find one or more appropriate websites. Some of the website-specific tasks had URLs
associated with mobile sites; others did not. For some websites, we tested both the mobile
and the full (desktop) website on the mobile device. We sometimes gave participants the
URL of the site without indicating the mobile variant, in order to test whether the site will
recognize access from a mobile phone and will redirect the user to a mobile Web page. In
cases where this redirection did not happen, we still found it valuable to see what users
experience when they are not aware of the Web address for the mobile site.
In the case of app-specific tasks, users were asked to download the app first and then use it
to complete the task.

DESIGN REVIEWS
The last source of information for our guidelines came from expert reviews. Over the course
of three years we reviewed many apps and mobile websites on a variety of platforms.
The following table contains a subset of the sites and applications included in the review:
m.cnnmoney.com Financial news from CNN
m.TVGuide.com TV schedule
Freshdirect.com Grocery store in NY
mobile.movietickets.com
Movie schedules and movie tickets
(iphone.movietickets.com)
mobile.VictoriasSecret.com Clothing and lingerie store
Wsj.com Wall Street Journal
m.Yahoo.com Yahoo! portal
m.Flickr.com Image repository
mobile.Zillow.com Real estate
realestate.com/mobile Real estate
m.ebay.com Online auctions
mobile.southwest.com Airline
craigslist.org Classifieds
mobile.CNet.com IT News
m.Facebook.com and Facebook
Social Networking
applications for iPhone and Blackberry
1800flowers.mobi Flower shop
Sears2go.com Sears online store
m.cnn.com News
bbc.co.uk/mobile News
ShopSavvy for iOS/Android Price comparison
Netflix Entertainment
The Weather Channel for iOS/Android Weather
ATT U-Verse for iOS DVR app for subscribers of ATT U-verse
Sears for iOS Shopping
REI Snow Report for iOS Weather (ski resort information)
British Museum for iOS Museum app
Moleskine for iOS Note taking
Bank of America for iOS Banking
AP Mobile for iOS/Android News

Astrid Tasks for Android To do app
CNBC for iOS/Android News and stocks

List of Guidelines
Mobile Strategy Guidelines.......................................................... 23
Should You Go Mobile?............................................................................ 23
1. If your budget allows for a mobile platform (website or app), build

one: your users will do better with it. ...................................... 23
2. Use site analytics to determine how many full-site accesses come

from mobile devices and to decide whether it’s worth building a
mobile platform. ................................................................... 23
3. Build a mobile platform if people use your site to communicate with

each other. ........................................................................... 24
4. Build a mobile platform if people come to your site to kill time and
browse................................................................................. 24
5. If your site has content that changes often (e.g., once a day, or
several times a day), create a mobile platform.......................... 24
6. Build a mobile platform if people do small, quick transactions on your

site under time pressure. ....................................................... 24
7. Build a mobile site if you provide content that is likely to be needed

when people are away from home. .......................................... 24
Application Versus Mobile Website ............................................................ 27
What to Include On Mobile ...................................................................... 31
8. Tasks that have a deadline are more likely to be done on mobile

devices. ............................................................................... 32
9. Tasks that involve rapidly changing information are more likely to be

done on mobile devices. ......................................................... 32
10. Tasks that require privacy are more likely to be done on a mobile
device. ................................................................................. 32
11. Finding information about businesses is a task likely to be done on a

mobile device. ...................................................................... 33
12. Finding directions and public transportation information, as well as

information needed in an emergency are tasks likely to be done on a
mobile device. ...................................................................... 33
13. Tasks that require communication with others are likely to be done
on mobile phones. ................................................................. 33
14. The response to a user question on mobile and on desktop should be

the same.............................................................................. 34

15. It is ok if some questions have answers only on desktop. ........... 34
Mobile Sites ........................................................................................... 34
16. Build a different mobile website for every major type of phone
(feature, smartphone, touch). ................................................. 37
17. If you must build only one mobile site, build a site for the high-end
phones (touch phones and smartphones). ................................ 37
18. Detect if users are coming to your site on a mobile phone and direct
them to your mobile site. ....................................................... 38
19. Don’t ask users if they want to go to the full site or to the mobile site
on a separate page. ............................................................... 39
20. Include a link to your mobile site on your full site. ..................... 39
21. The link labeled “Mobile” on your full site should not point to
information about your mobile site. ......................................... 39
22. Use the word “mobile” in the title of your mobile site. ................ 42
23. Use SEO to increase the visibility of your mobile site. ................ 42
24. Standard domain names and URLs (m.site.com, mobile.site.com,

site.mobi, www.site.com/mobile) should all point to your mobile site.
If you can afford only one of these domains, use m.site.com. ..... 42
25. When designing a mobile site, minimize the number of clicks required
to complete a task................................................................. 43
Mobile Apps ........................................................................................... 43
26. Choose app names that are unique, recognizable, and memorable.45
27. Choose an application icon that is descriptive and easy to recognize.

........................................................................................... 45
28. Your app description should clearly explain what the purpose of the
app is and if it has any special features compared to other apps (and
especially, to the free or paid version of the same app). ............ 45
29. Your app description should not be too long. ............................ 45
30. Advertise the app on your mobile website. Make sure that you
promote the right platform on the right device. ......................... 46
31. Advertise the app as a link on your homepage rather than on a

separate page. ...................................................................... 46
32. Find a core function and design around it. ................................ 47
278 INFO@NNGROUP.COM List of Guidelines

33. Keep the app functionality simple. ........................................... 47
34. Don’t add features that are unrelated to your core function. ....... 47
35. Do not implement your full desktop app on mobile. ................... 49
36. For the phone variant of your desktop app, choose only a small
subset of features that revolve primarily around consuming rather
than producing content. ......................................................... 49
37. Design for a continuous experience. ........................................ 50
Principles of Mobile Usability ...................................................... 52
General Guidelines for Mobile Websites and Apps ....................... 54
Homepage ............................................................................................. 54
38. On websites, include the company logo or name in a salient location

at the top of the mobile homepage. ......................................... 54
39. On websites, include the logo on every page of your site and make it
link to the homepage. ............................................................ 54
40. Include a link to the full site on the mobile homepage................ 55
41. A search tool and navigation should be present on the homepage.57
Typing .................................................................................................. 57
42. Use auto-complete and suggestions whenever users fill in a textbox.

........................................................................................... 57
43. Allow for typos and abbreviations. ........................................... 57
44. Use personalization and history to provide good defaults for text that
needs to be input. ................................................................. 58
45. Use GPS information to detect location automatically and allow the
use of current location. .......................................................... 58
46. Allow users to easily delete default field values. ........................ 60
47. Where possible, compute field values rather than asking the users to
enter them. .......................................................................... 62
48. Do not make people memorize information from one page to another.
........................................................................................... 63
49. Make textboxes long enough so that users don’t have to scroll within.
........................................................................................... 65
50. Allow users to paste information into an input field. ................... 67

51. Allow users to copy any content that you may present to them. .. 67
Dropdown Boxes, Menus, Carousels.......................................................... 69
52. Make sure that your menus look expandable. Use menu labels that
clearly indicate that they expand to a set of options. ................. 69
53. Do not use animated carousels. Use carousels that can be controlled
by users. .............................................................................. 71
54. Do not separate the carousel controls from the carousel. ........... 72
55. Use cues to show users that they can see more items in a carousel.
........................................................................................... 74
56. Do not use dropdowns (or pickers) if you have many items and users
need to scroll a lot to read all of them. ..................................... 76
57. Make sure that all the text of each option in a dropdown or popover
is visible............................................................................... 78
Forms ................................................................................................... 78
58. In a form, put the field description above the textbox. Use the colon
“:” to indicate that the description refers to the textbox below. ... 78
59. Make sure that all the fields in the form are aligned. .................. 79
60. To signal an input error in a form, mark the textbox that needs to be
changed. .............................................................................. 80
61. The error message in a form should be next to the error (and not at
the top of the form). .............................................................. 80
62. Don’t use alerts or fading popups to signal an error. .................. 80
63. On a website, minimize the number of submissions (and clicks) that

the user needs to go through in order to input information on your
site...................................................................................... 83
Logging in and Registering ...................................................................... 86
64. Do not ask users to log in unless absolutely necessary for security
reasons. ............................................................................... 86
65. When logging in must be done, consider letting users define a

numerical pin........................................................................ 86
66. When logging in must be done, have an option that allows the user to
see the password in clear. ...................................................... 87

67. When users need to create a password, tell them if the password has
to satisfy any constraints (e.g., number of letters in the password).
........................................................................................... 87
68. Do not require people to register or sign in on a mobile phone. ... 89
69. Always have a guest checkout option. ...................................... 89
70. The guest checkout/skip registration option should always be the first
option displayed on the checkout page..................................... 89
71. Don’t ask users to log in or register (or enter extensive information)
before delivering any value to them......................................... 90
72. Whenever registration is an option on mobile, require only the

minimum information to create an account. Let users add extra
information at later times. ...................................................... 92
73. Don’t ask users to confirm their registration through email. ........ 95
74. Be upfront about the benefits that registration brings to the users.96
Search .................................................................................................. 98
75. Include a search box on your mobile website or in your app. ...... 98
76. If your users are mostly browsers, consider making the search box
less salient by placing it at the bottom of the page. ................... 98
77. Put the search box at the top of your screen unless your users are
mostly browsers. ................................................................. 100
78. The length of the search box should be the largest possible size that
will fit on the screen. ........................................................... 100
79. Preserve search strings between searches. Use auto-completion and

suggestions. ....................................................................... 100
80. Do not use several search boxes with different functionalities on the
same page. ........................................................................ 100
81. If the search returns zero results, offer some alternative searches or
a link to the search results on the full page. ........................... 101
Lists and Scrolling ................................................................................ 104
82. On the Web, all the items on a list should go on the same page if
they are text only. (This guideline is valid for apps, too, if the list is
generated by making a request to a server.) .......................... 104
83. List of items that include images should be split into multiple pages
(we recommend between 20-30 items per page)..................... 104

84. If a list of items can be sorted according to different criteria, provide
the option to sort that list according to all those criteria. .......... 107
85. If a list contains items that belong to different categories, provide

filters to narrow down the number of elements. ...................... 108
86. Place the sort/filter options before the search results. If extended
space is needed for the sort/filter options, either use an expandable
menu or place them at the bottom of the page, but use jump links
from the top of the page to the bottom. ................................. 111
87. When narrowing down results, show facets and number of items in
each category. .................................................................... 114
88. When users have narrowed down a list, indicate the selected filter or
sort criteria. ....................................................................... 115
89. If the list contains only one item, take the user directly to that item.
......................................................................................... 117
90. In a long list organized alphabetically, allow users to easily jump to a

certain letter....................................................................... 117
91. Do not use a deck-of-cards model (i.e., one item per page) for lists.
......................................................................................... 118
Navigation ........................................................................................... 119
92. Include navigation on the homepage of your mobile website..... 122
93. On homepages of browsing sites, give priority to new content over

navigation links. .................................................................. 122
94. Include at a link to navigation on every page of your mobile website.

......................................................................................... 125
95. Avoid deep hierarchies on mobile. ......................................... 126
96. Use breadcrumbs on sites with a deep navigation structure (many

navigation branches). Do not use breadcrumbs on sites with shallow
navigation structures. .......................................................... 129
97. Place together links that are related to the same topic. ............ 130
Content............................................................................................... 131
98. Use formatting and concise writing for quick reading. .............. 131
99. Avoid splitting articles in many pages. ................................... 134
100. If an article spans several pages, use pagination at the bottom. Have
a link to each individual page, rather than just to the previous and
the next ones. .................................................................... 135

101. Stay away from jargon and industry-specific terminology. ........ 136
102. Do not use horizontal scrolling on mobile websites. ................. 137
103. Use links with good information scent (that is, links which clearly
indicate where they take the users) on your mobile pages. ....... 138
104. Use links to related content to help the user navigate more quickly
between similar topics. ........................................................ 140
105. On browsing sites, new content should be given priority. Users should
not have to scroll to get to new content. ................................ 141
106. Use true article summaries on the headline page. Do not use the first
few sentences of the article. ................................................. 144
107. Use complete sentences in headlines and summaries. .............. 145
108. Don’t truncate product information in lists of products. ............ 145
109. For content that changes often (e.g., news headlines), show when it
has been last updated.......................................................... 147
110. Change the date of the last update only after all content has been
completely updated. ............................................................ 147
111. Show absolute rather than relative time. ................................ 148
Readability .......................................................................................... 149
112. Use a sans-serif font. ........................................................... 149
113. If your site contains a lot of text, include tools for changing font size.
......................................................................................... 150
114. Use a font-size default that is readable for a large majority of users.
......................................................................................... 150
115. Use solid backgrounds. ........................................................ 150
116. Use high contrast between the font color and the page background.
......................................................................................... 150
Images, Animation, and Videos .............................................................. 151
117. Include images on your website only if they add meaningful content.
Do not use images for decoration purposes only. .................... 152
118. Do not use image sizes that are bigger than the screen. The entire
image should be viewable with no scrolling............................. 153

119. For cases where customers are likely to need access to a higher
resolution picture, initially display a screen-size picture and add a
separate link to a higher resolution variant. ............................ 153
120. When you use thumbnails, make sure that users can distinguish what
the picture is about. ............................................................ 156
121. Use captions for images that are part of an article if their meaning is
not clear from the context of the article. ................................ 157
122. Do not shuffle text around as images get loaded. .................... 158
123. Do not use images of text for navigation links. ........................ 160
124. Do not use moving animation. .............................................. 162
125. If you have videos on your site, offer a textual description of what
the video is about. .............................................................. 163
126. Clicking on the thumbnail and clicking on the video title should both
play the video. .................................................................... 164
127. Indicate video length. .......................................................... 165
128. Specify if the video cannot be played on the user’s device. ....... 166
Icons .................................................................................................. 166
129. Use standard icons in standard ways. .................................... 166
130. Use icons with good information scent. .................................. 167
131. Include labels with your icons. .............................................. 167
Errors ................................................................................................. 169
132. In a form, mark fields that need to be corrected to signal an error.

......................................................................................... 169
133. Do not make users download software or data that do not work on
their phone. ....................................................................... 169
134. Flash does not work on all phones; do not use it. .................... 170
135. Make error messages salient and simple. Tell users (1) what the
problem is, and (2) what they can do to fix it. ........................ 170
136. After reporting an error, return to the state before the error. .... 172
137. Don’t report an error regarding a feature that is not in use. ...... 173
Maps and Location Information .............................................................. 174

138. Whenever you have location information on your website, link it to a
map and include a way of getting directions. .......................... 174
139. If your company has one brick-and-mortar location, list it in your app
or mobile website. If the company has multiple locations, include a
locator form in your mobile app or on your mobile website. ...... 175
140. In a locator, use two possible values for location: automatically-

detected current location and location specified by user. .......... 175
141. In a locator form, always give priority to the current location.... 175
142. Allow users to easily change location. .................................... 175
143. Avoid asking repeatedly for permission to use the current location.
......................................................................................... 177
144. When displaying location information, show address, distance from

current location, link to map and directions, phone, and opening
hours (if applicable)............................................................. 178
145. When displaying locations on a map, start with a zoom level that
enables the user to see his current location (or the location specified
by the user) and at least one of the locations of interest. ......... 180
146. Allow users to switch between a list view and a map view of
locations. ........................................................................... 181
147. If locations have different attributes of interest to the user, provide

the list of locations by default. .............................................. 181
148. If locations are all equivalent (except for distance), provide a map
view of locations by default. ................................................. 181
149. In a list of locations, show how far locations are from the current
location. List locations in the order of distance from current location.
......................................................................................... 182
Shopping ............................................................................................ 183
150. When you present a list of products, use image thumbnails that are
big enough so that the user can get some information out of them.
......................................................................................... 183
151. On a product page, use an image size that fits the screen. Link to a
higher resolution image when the product requires closer inspection.
......................................................................................... 184
152. Offer the option to email a product to a friend. ....................... 184
153. Offer the option to save the product in a wish list. ................... 184

154. On an e-commerce site, include salient links on the homepage to the
following information: .......................................................... 184
— locations and opening hours (if applicable), .................................. 184
— shipping cost, ........................................................................... 184
— phone number, ......................................................................... 184
— order status, and ....................................................................... 184
— occasion-based promotions or products. ....................................... 184
155. Always include the full catalog of products on the mobile site or the
mobile app. ........................................................................ 186
156. When presenting a list of products, show the ratings for each one to
enable users to select them more easily. ................................ 187
Banking and Transactions...................................................................... 188
157. Whenever users make a transaction on the phone, email them a

confirmation number for that transaction. Inform them that they will
receive an email and tell them what it will contain. .................. 188
158. Allow users to “soft print” the transaction confirmation screen by

taking a screen capture........................................................ 188
159. Whenever users need to submit a transaction, show them a one-

screen summary of the transaction. ....................................... 189
Feature Phones ......................................................................... 191
160. On feature phones, do not include a search box if most of your users
are browsers. ..................................................................... 192
161. Put the search box at the bottom of your screen. .................... 192
162. On a feature phone screen, place navigation options at the bottom of

the page. ........................................................................... 194
163. On a feature phone, minimize the number of images per page. . 194
General Guidelines for Touch Phones ........................................ 195
Targets: Size, Placement, Affordance ...................................................... 195
164. For touch phones, widget target area (i.e., tappable area) should be
at least 1cm X 1cm. ............................................................ 195
165. For touch phones, do not crowd targets. Leave generous amounts of
space around widgets such as radio buttons, arrows for dropdown
boxes, checkboxes, scrollbars, and links. ............................... 195

166. Do not rely on small padded targets. ..................................... 198
167. Use padding for tabular views. .............................................. 199
168. Create the right touch affordance for targets: make them look
tappable. ........................................................................... 202
169. When a design element looks like a button, users will expect to touch
it. ...................................................................................... 203
170. For iOs, build a back button into your app. For other platform, make
sure that the physical back button works properly within the app and
allows users to return to the previous page. ........................... 203
171. Place destructive buttons far away from the physical device buttons.
......................................................................................... 205
Gestures ............................................................................................. 206
172. Use only the more familiar gestures (tap, drag). Do not rely on users
knowing and remembering more complicated gestures. ........... 206
173. Avoid assigning different functionalities to similar gestures. ...... 206
174. Take advantage of the natural affordances for gestures. .......... 206
175. If you must use less familiar or less discoverable gestures, add some
redundancy in the interface. ................................................. 208
176. In most situations, users need cues to figure out that they’re
supposed to use the horizontal swipe gesture. ........................ 211
177. Don’t use the horizontal swipe gesture for navigation on a new
screen and for carousel navigation on the same page. ............. 212
178. On touchscreens, users expect to use the swipe to control a carousel.

......................................................................................... 213
179. In content-reader apps, it should be possible to turn pages both by

tapping the page margins and by swiping horizontally. ............ 214
180. When displaying images (or video) full screen, allow users to get to
controls by tapping on the image. ......................................... 214
181. When displaying images full screen, start by showing the controls,
then fade them away. .......................................................... 214
Orientation .......................................................................................... 215
182. Support both phone orientations (landscape and portrait) whenever

possible. ............................................................................ 215
183. Don’t make users switch between orientations often. ............... 215

184. Most apps should not display different content (or different interface
widgets) in different orientations. .......................................... 216
185. Apps that display data can use landscape to fit extra detail. ..... 216
186. Whenever an app uses landscape for extra information, it should let
users know (e.g., by displaying a tip or a message). ............... 216
187. Do not ascribe different content to the two possible landscape

orientations (physical buttons left or right). ............................ 218
Input .................................................................................................. 218
188. Show a keyboard appropriate for the input that the user is supposed
to type. .............................................................................. 218
189. In long forms, separate edit from selection. ............................ 219
Guidelines for Apps ................................................................... 222
Immersive Apps ................................................................................... 222
190. Don’t use an immersive app if you cannot make it completely

coherent with the users’ expectations. ................................... 222
191. Even if the app is not completely immersive, well-selected immersive

elements can make it more enjoyable. ................................... 224
192. Make sure that the immersive elements make the users’ task easier
rather than harder............................................................... 224
Input .................................................................................................. 226
193. Use the phone features (camera, GPS, voice recognition, accelerator,
etc.) to let users input text faster. ......................................... 226
194. Group related controls. ........................................................ 228
195. Place the Submit button under the form rather than at the top. 228
196. Do not use spin wheels for items that don’t have a natural order.230
197. Do not use sliders for inputting precise values. Only use sliders when
the exact value is not important. ........................................... 231
Modal Dialogs and Alerts ....................................................................... 233
198. Include a Cancel button in a modal dialog. ............................. 233
Registration and Log In ......................................................................... 234
199. Within apps, do not ask people to register to save information (e.g.,
favorites). .......................................................................... 234

200. Place both the Sign In and Register buttons under the login form, one
next to each other on the same line. ..................................... 235
Notifications ........................................................................................ 238
201. Do not ask people to accept push notifications the first time they
launch an app. .................................................................... 238
202. Avoid turning on sound notifications unless people explicitly turn

them on. ............................................................................ 239
203. Make sure that people can easily turn notifications on or off. .... 239
204. (iOS) Do not ask users to go to the iPhone Settings to turn on

notifications. Allow them to turn notifications on within the app. 239
Tab Bars and Tool Bars ......................................................................... 240
205. Do not have more than 5 items in the tab bar/tool bar. ............ 242
206. Only functions less essential to your app should be under the More
tab. ................................................................................... 242
207. Do not hide search under the More tab. ................................. 242
208. When you have many navigation options, consider using a list or a
grid instead of a tab bar. ...................................................... 243
Task Flow ............................................................................................ 244
209. Make the task flow as simple as possible. Include only the actions
that are essential for accomplishing the task. ......................... 244
Progress Indicators ............................................................................... 246
210. Whenever your app is downloading content, show a progress

indicator. ........................................................................... 246
211. Prefer progress bars to spinning gears or other indicators that don’t
show real-time progression. ................................................. 246
212. For larger downloads (e.g., videos, magazines), give users an

estimate of how long the download it’s going to take. .............. 246
Instructions and Help............................................................................ 247
213. User manuals are not useful, nor should they be necessary on
mobile. .............................................................................. 247
214. Users cannot read the help and use the app at the same time. . 247
215. If you decide you absolutely need a user manual, make sure that it’s
easy to read. ...................................................................... 247

216. Meaningful, contextual tips can be helpful. ............................. 249
217. Do not flood users with tips. ................................................. 249
218. Present tips when the app is launched or when data is loading. . 249
219. Allow users to disable tips. ................................................... 249
Initial Experience ................................................................................. 251
220. Keep launching time to a minimum. ...................................... 251
221. If users must wait for more than 20 seconds, give them something to
do while waiting. ................................................................. 251
222. Don’t use a launch screen if possible. .................................... 252
223. If you must use a launch screen, make it similar to the first screen of
the app. ............................................................................. 252
224. Don’t start with a video or a sound effect. .............................. 253
225. Preload data for the first launch. ........................................... 253
226. Update data for the users. .................................................... 254
227. Don’t ask users to delete an app and install it again. ............... 254
228. Save state: if users come back to an app, continue the session from
where they left. .................................................................. 255
Hybrid Apps ......................................................................................... 256
229. Do not send users to a full website from an app. ..................... 256
230. If the app takes the user to an in-app browser, don’t present an ad
for the same app again. ....................................................... 258
Physical Buttons on Platforms Other than iOS ......................................... 259
231. Always make sure that the back button works as supposed to: (a)
dismisses dialogs; (b) moves back to the previous page within the
app (or to the previous app if the current page is the first visited
during the current session). .................................................. 259
232. (Android) Avoid migrating toolbars and tab bars under the menu
button. .............................................................................. 260
233. (Android) Avoid changing menu button functionality within the app.
......................................................................................... 260
234. (Android) Consider putting only non-essential options under the

menu button....................................................................... 260

235. Whenever search is central to an app, include a visible search box on
the screen. ......................................................................... 262
236. Use the search button to search within the app rather than the Web.
......................................................................................... 263
237. Don’t make the search button contextual. The scope of the search
should be the same across the app. ....................................... 264
Methodology ............................................................................. 266
Diary Studies ....................................................................................... 266
Usability Testing .................................................................................. 268
Design Reviews .................................................................................... 275
List of Guidelines ...................................................................... 277
Acknowledgments ..................................................................... 292
About the Authors ..................................................................... 293

Acknowledgments
We thank several people for helping us gather the data for this research:
• Our participants for delivering all the data on which this report is based.
• Janelle Estes for providing success rates and participant information for one of the
studies.
• Hannah Kain, Julia Toy, and Brandon Marugg for offering us the space and the
assistance necessary to run our user testing sessions.
• Mihai Budiu for lending us his Windows Phone 7 to plan our mobile testing with
Windows Phone 7 users.
• Susan Pernice for helping us with the recruitment of participants in Australia.
• Eric Chow and Luice Hwang for helping us recruit participants in Hong Kong.
292 INFO@NNGROUP.COM Acknowledgments

About the Authors
Raluca Budiu, Ph.D. is a User Experience Specialist with Nielsen Norman Group. At NN/g
she consults for clients from a variety of industries and presents tutorials on mobile
usability, usability of touch devices, cognitive psychology for designers, and principles of
human computer interaction. She coauthored the NN/g reports on mobile usability, iPad
usability, and the usability of children’s websites. Budiu previously worked at Xerox PARC,
doing research in human-computer interaction. At PARC, she built computational models of
how people search for information in visualizations of large data structures. She also
explored new ways of measuring information scent and conducted research on interfaces for
social bookmarking systems and on the cognitive benefits of tagging. Budiu was also a user
researcher at Microsoft Corporation, where she explored future directions and made
strategic recommendations for incorporating user-generated content and social web
features into MSN. Budiu has authored more than 20 articles and conference presentations
on human-computer interaction, psychology, and cognitive science. She holds a Ph.D. from
Carnegie Mellon University.
Jakob Nielsen, Ph.D. is principal of Nielsen Norman Group. He is the founder of the
“discount usability engineering” movement, which emphasizes fast and efficient methods for
improving the quality of user interfaces. Nielsen, noted as “the world’s leading expert on
Web usability” by U.S. News and World Report and “the next best thing to a true time
machine” by USA Today, is the author of the best-selling book Designing Web Usability: The
Practice of Simplicity (2000), which has sold more than a quarter of a million copies in 22
languages. His other books include: Hypertext and Hypermedia (1990), Usability
Engineering (1993), Usability Inspection Methods (1994), International User Interfaces
(1996), Homepage Usability: 50 Websites Deconstructed (2001), Prioritizing Web Usability
(2006), and Eyetracking Web Usability (2010). Nielsen’s Alertbox column on Web usability
has been published on the Internet since 1995 and currently has about 200,000 readers.
From 1994 to 1998, Nielsen was a Sun Microsystems Distinguished Engineer. His previous
affiliations include Bell Communications Research, the Technical University of Denmark, and
the IBM User Interface Institute.

About Nielsen Norman Group
Nielsen Norman Group (NN/g) is a consulting and research company that is solely
focused on user experience. We are not a Web design shop—we will tell you what
your customers want and how to vastly increase the business value of your site or
intranet, but we won’t build the new site for you. We are independent of technology
vendors and design agencies, so we can report the unvarnished truth about what
works and what doesn’t.
For a full list of services and current prices, please see www.nngroup.com/services
CONSULTING
• Independent expert review of the user experience of most designs, such as
a website or intranet: $38,000. (Lower prices for small focused reviews, like a
mobile app.)
• User testing: typically $25,000 to test a website or intranet; $45,000 for a
competitive study. Less for a mobile app or other small UI.
TRAINING
We produce an annual conference series where world-class experts teach the latest
findings about the usability of websites, intranets, mobile sites/apps, and email
newsletters. We also teach user research methodology so that you can hone your
skills and conduct your own usability projects with more success than if you use
weaker methods.
NN/g is the only company that presents high-end usability training events bringing
the same courses to the United States, Europe, and Australia. For the current
conference program, see http://www.nngroup.com/events
IN-HOUSE PRESENTATIONS
Most of our conference seminars are available for in-house delivery at your location.
Special training events are optimized for leveraging your own design questions:
• 3-day Learning-by-Doing Usability Testing ($23,000). We take you
through a user test of your own design, teaching usability principles with your
own project as the case study.
• Intranet Usability ($23,000). Combines a full-day tutorial with the lessons
from our testing of 27 intranets and a full-day workshop about your own
intranet’s usability, based on our review of your design.
• Application Usability ($16,000). Two days intensive course on everything from
screen design (buttons, field labels, widgets) to feature and workflow design.
• Writing for the Web ($9,000). A writing workshop using your own sample
content for the rewrite exercises.
• Fundamental Guidelines for Web Usability ($9,000). What everybody should
know about users’ online behavior and how to design better sites.
• User Experience (UX) Basic Training ($9,000). Bring your team up to speed
on all the most important concepts and methods of the field.
PRICES
Prices are stated in U.S. dollars and were valid when this report was published. Travel
expenses are extra for all training seminars and for many other services; prices are
higher outside the United States. Prices are subject to change without notice: for
current prices, please see http://www.nngroup.com/services
NEWSLETTER
Free e-mail newsletter published every two weeks with summaries of our newest
research and thinking. To subscribe: http://www.useit.com/alertbox/subscribe.html
TWITTER
Follow us at @NNgroup (highly abbreviated feed; missing much newsletter info).
Reports by Nielsen Norman Group
For a full list and to download reports, please see http://www.nngroup.com/reports
WEB USABILITY
• E-commerce user experience: series of 13 reports
• Corporate Image: presenting company information in a site’s “About Us” area
• PR section of corporate sites: supporting journalists
• Investor Relations area of corporate website: supporting investors
• Site map usability FREE
• B2B: guidelines for converting business users into leads and customers
INTRANET USABILITY
• Intranet usability guidelines: 10 reports based on user testing of 27 intranets
• Intranet information architecture (IA)
• Intranet design annual: published every year about that year’s 10 best intranets
• Sector-specific intranets: financial services, manufacturing, technology, retail,
knowledge-intensive, and government agencies
• Intranet portals: report from the trenches
• Social networking and collaboration features on intranets
MOBILE DEVICES
• Mobile websites and apps
• iPad usability FREE
• WAP phones — field study findings FREE
E-MAIL USABILITY
• Email newsletters
• Transactional email and confirmation messages
APPLICATION USABILITY
• Application design showcase: case studies of award-winning app UIs
• Customization usability
• Flash and Rich Internet Applications (RIA) FREE
SPECIAL USER SEGMENTS
• Usability of websites for children (age 3–12)
• Teenagers on the Web (age 13–17)
• College students (age 18–24)
• Web usability for senior citizens (age 65+)
• Beyond ALT text: improving usability for users with disabilities FREE
USER-CENTERED DESIGN METHODOLOGY

• Agile usability: Best practices for user experience on Agile development projects
• Return on investment (ROI) for usability
• Paper prototyping: a how-to video (40 minutes on DVD or Blu-ray)
• 230 tips to improve the way you run user tests
• Recruiting test participants for user testing FREE
• Testing users with disabilities
• How to conduct eyetracking studies FREE
OTHER
• Social media postings FREE
• Non-profit and charity websites: attracting donations and volunteers
The Usability Week 2012 Conference Who Will You Meet
at the Conference?
Many conferences offer cavernous exhibit halls, brief seminars on second-hand
Companies that sent the most
discoveries, and a sense of anonymity that can be truly alienating. people in 2010 and 2011:
Usability Week takes a different approach.
Accenture
ADP
Knowledge, Directly from the Source American Express
In place of scattered, shallow talks, Usability Week offers 5 or 6 days of deep Apple
AQA (Assessment and
learning as international experts lead full-day training courses on topics such as:
Qualifications Alliance)
• UX Basic Training AT&T
• Fundamental guidelines for Web usability Autodesk
• Information architecture (IA) principles BMC Software
• Writing for the Web Canada Post
CBC
• Application design
Channing Bete Company
• Designing usable social features Chevron
• The human mind (how your users think) Church of Jesus Christ of Latter Day
• Mobile websites and touchscreen/gesture apps Saints
Cisco Systems
The College Board
Course levels range from introductory to advanced; you can sign up for as few Cox Communications
as 1 or 2 days or as many as 6. Deloitte
Deutsche Lufthansa AG
Many sessions include hands-on training exercises that let you apply what you Discover Financial Services
eBay
learn immediately; all ensure that you’ll learn tools you can use to improve your Ericsson
website, intranet, or application as soon as you get home. Euro RSCG Life MetaMax
Fidelity Investments
Gap Inc Direct
Networking Opportunities GE
Because you’ll spend each day in a group with in-depth focus on a single topic, Google
you can discuss problems, share solutions, and make lasting connections with Herbalife International
your peers. Hewlett-Packard
ING
Intel
Pay only for the days you need. The more days you attend, the deeper the Intuit
discount. Early bird rates save even more, so sign up early! Itaú Unibanco
John Lewis
Kaiser Permanente
Venues LexisNexis
The conference visits several of the world’s great cities, providing ample Los Angeles Times
incentive to continue networking offsite at world-class restaurants, clubs, and Manulife Financial
attractions. McGraw-Hill Companies
McKesson
McMaster Carr Supply Company
Choose your city at http://www.nngroup.com/events for agendas, location, Microsoft
pricing, and registration information: National Marrow Donor Program
Organisation for Economic Co-
operation & Development
• Amsterdam: April 23-27, 2012 (OECD)
• Washington D.C.: May 14-18, 2012 Overstock.com
• Chicago: June 25-29, 2012 Pearson
• Toronto: July 23-27, 2012 Precision Nutrition
• Sydney: August 12-17, 2012 Qualcomm
RBS Royal Bank of Scotland
• San Francisco: September 23-28, 2012
Research In Motion (RIM)
Rockwell Automation
We Can Come to You Royal Bank of Canada
Sage Software
You can book most of our training courses for in-house presentation at your
Samsung Electronics
company or organization. If you have a large team this is cheaper than sending Sandia National Laboratories
them all to the conference. See http://www.nngroup.com/services/workshops SAP
Sapient
Scotiabank
Sony
State Library of Victoria
Symantec
T. Rowe Price
TD Ameritrade
TFO (Télévision Francophone en
Ontario)
Thomson Reuters
Totaljobs Group
Towers Watson
U.S. Office of Personnel
Management
Vanguard
Verizon
VMware
WebMD
Wells Fargo
Mobile User Experience 1: Usability of Websites and Apps on
Mobile Devices
• Amsterdam: Monday, April 23

• Washington D.C.: Monday, May 14
• Chicago: Monday, June 25
• Toronto: Monday, July 23
• Sydney: Thursday, August 16
• San Francisco: Monday, September 24
Raluca Budiu and Amy Schade

Full-Day Training Course
How do we create a satisfactory user experience when limited to a small device?
This seminar is based on expert reviews, as well as international studies with participants
ranging from students to early technology adopters and business people using websites on a
variety of mobile devices. We also report on the latest findings from articles published in
prestigious journals and conferences.
Our user research included smartphones, touchphones, as well as feature phones from several
different vendors. The seminar will discuss the issues in designing for this range of devices, with
a focus on smartphones and touchphones, since research indicates that these are the primary
devices used for mobile Internet access.
In this seminar we target basic mobile usability principles that go beyond any specific phone
model.
What You’ll Learn
• What behaviors users engage in when using mobile devices

• Mobile app versus mobile website: which is better
• Guidelines and best practices about how to make your website mobile-friendly, with
emphasis on:
o Features that make mobile sites usable
o Easy navigation on mobile devices
o Writing and producing content for mobile device
Course Outline
Mobile user behaviors:
• What kinds of activities people do on mobile devices

o Differences between apps and websites
• Browsing for news, entertainment, sports
• Finding specific information (weather, movie times, etc.)
• Transactions (such as online banking and other financial operations)
• Shopping: what do users shop for on mobile
• Designing to support user behaviors
Design strategy considerations:
• Creating a dedicated mobile site vs. having mobile users access your regular website
• Designing for high-end models vs. the lowest common denominator
o Direct manipulation UI for touchphones (e.g., iPhone, BlackBerry Storm)
o Indirect manipulation for low-end devices
• Creating a mobile application vs. a mobile website; when to use what
o Differences in designing an app versus a mobile website
Basic usability guidelines for mobile sites and apps:
• Basic interaction
o Typing
o Dropdown Boxes, Buttons, and Links
o Lists and Scrolling
o Menus
o Carousels
• Forms
• Logging In and Registering
• Search
• Navigation and information architecture (IA)
• Errors
• Page layout
• Search
• Homepages
• Images, Animation, and Videos
• Content usability
o How users read on mobile devices
o Writing for mobile use
o Presenting text: legibility and readability
• Designing for feature phones: differences from smartphones and touchphones
• How to perform usability testing with mobile devices
Format
This full-day tutorial includes lectures, video highlights from user testing, and some exercises.
Handouts
Copies of the presentation slides
Who Should Attend

Anybody who designs websites, intranets, or online services that have mobile users. People in
charge of mobile strategy, including the question of whether to develop dedicated mobile
services.
What is NOT Covered:

This seminar is solely focused on the user experience and does not cover programming. Although
we do discuss nonconventional app interfaces, this seminar is not intended for game developers.
See Also:
This seminar is about the basic usability principles that are valid for both mobile websites and
apps and for the full range of mobile devices. A companion seminar, Mobile User Experience 2
focuses on issues specific to designing applications for touchscreen devices.
Instructors
Raluca Budiu is a User Experience Specialist with Nielsen Norman Group. At

NN/g she consults for clients from a variety of industries and presents
tutorials on mobile usability, usability of touch devices, cognitive psychology
for designers, and principles of human computer interaction. She coauthored
the NN/g reports on mobile usability, iPad usability, and the usability of
children’s websites. Budiu previously worked at Xerox PARC, doing research in
human-computer interaction. At PARC, she built computational models of how
people search for information in visualizations of large data structures. She
also explored new ways of measuring information scent and conducted
research on interfaces for social bookmarking systems and on the cognitive
benefits of tagging. Budiu was also a user researcher at Microsoft Corporation, where she
explored future directions and made strategic recommendations for incorporating user-generated
content and social web features into MSN. Budiu has authored more than 20 articles and
conference presentations on human-computer interaction, psychology, and cognitive science.
She holds a Ph.D. from Carnegie Mellon University.
Amy Schade is a Director based in Nielsen Norman Group’s East Coast office.
Schade works with clients internationally in telecommunications, e-commerce,
government, travel, automotive, publishing, banking, non-profit and
education, including extensive work on corporate intranets. She has
conducted user research and performed reviews on a wide variety of websites
in the United States, Canada, Europe, Asia and Australia. She presents
tutorials on user testing, intranet usability, writing for the Web, email
newsletter usability and mobile usability. She authored the NN/g reports on
intranet usability, intranet information architecture, email newsletters, and
site map usability, as well as the 2010 and 2011 Intranet Design Annuals, and
conducted many user test sessions for reports on accessibility and usability for senior citizens.
Before joining NN/g, Schade was an information architect at Arc eConsultancy, where she
created and revised architectures for sites ranging from a family-related content site to a
transaction-based sponsorship marketplace. Schade has also held various positions in web
production and advertising. She has a Master's degree from New York University’s Interactive
Telecommunications Program and a B.A. in Communications from the University of Pennsylvania.
Mobile User Experience 2: Touchscreen Application Usability
• Amsterdam: Tuesday, April 24

• Washington D.C.: Tuesday, May 15
• Chicago: Tuesday, June 26
• Toronto: Tuesday, July 24
• Sydney: Friday, August 17
• San Francisco: Tuesday, September 25
Raluca Budiu and Amy Schade

What makes a good application? A new, cool interface? Ease of use? Responding to users’ needs?
Why do some applications become part of the everyday life of their users, while others are
downloaded and never used?
This seminar addresses these questions. In discussing the secrets of a successful iPhone, iPad, or
Android app, we use data from our own ethnographic and user-research studies, and from expert
reviews. This seminar complements our seminar Mobile User Experience 1, which is focused on
basic mobile usability principles that are valid on all platforms. In this seminar we will use
examples from existing iPhone, iPad, and Android apps and will focus on the challenges that are
specific to designing native apps for touchscreen devices. Although we do discuss
nonconventional app interfaces, this seminar is not intended for game developers.
What You’ll Learn

In this session, you’ll learn:
• How touchscreen users think and what they expect from an application
• Differences between iPhone, iPad, and Android users
• What types of mobile applications people use repeatedly, and which are one-time
wonders
• Patterns of application usage
• Design guidelines and best practices for making your application useful and usable
• How to avoid usability pitfalls in mobile user interfaces, including design mistakes made
by some pretty famous apps
Course Outline
• Types of applications: immersive, productivity, utility applications
• Using the device hardware to your advantage:
o How to design for the touch screen
o Using the gestures and multi-touch in your application
o Accelerometer
o Sound and voice recognition
o User’s location
• Consistency with other applications designed for the same device and conventions
o How to handle borderline cases
o When can you depart from conventions
• Design primitives
o Menus and lists
o Form fields
o Buttons and controls
• Design guidelines for common tasks
o Startup screen
o Logging in
o Configuration and settings
o Data input and form-filling guidelines
o Content: text, images, graphics, animation
o Error messages and help
o Saving state and “printing”
o Editing
o Search
o Displaying ads
• Alerts and notifications; online versus offline mode; push versus pull
• Customization and Personalization
o History
o Preserving state
• Moving from a computer application to a mobile application
Format
This full-day tutorial includes lectures, video highlights from user testing, and some exercises.
Handouts
Who Should Attend

Anybody who designs or considers designing iPhone/iPad or Android applications. A secondary
audience would be people who target other high-end mobile devices and want their apps to equal
the usability of the best iPhone or Android apps. This seminar is solely focused on the user
experience and does not cover programming.
What is NOT Covered

This seminar is solely focused on the user experience and does not cover programming. Although
we do discuss nonconventional app interfaces, this seminar is not intended for game developers.
See Also:
The companion seminar Mobile User Experience 1 covers basic mobile usability principles,
applicable to all mobile devices.
Separate seminars that focus on application design in general
• Application Usability 1: Page-Level Building Blocks for Feature Design

• Application Usability 2: Dialogue and Workflow Design
• Designing Complex Applications and Websites (note: complex apps will rarely be suited
for mobile use)
Instructors
Raluca Budiu is a User Experience Specialist with Nielsen Norman Group. At

NN/g she consults for clients from a variety of industries and presents
tutorials on mobile usability, usability of touch devices, cognitive psychology
for designers, and principles of human computer interaction. She coauthored
the NN/g reports on mobile usability, iPad usability, and the usability of
children’s websites. Budiu previously worked at Xerox PARC, doing research in
human-computer interaction. At PARC, she built computational models of how
people search for information in visualizations of large data structures. She
also explored new ways of measuring information scent and conducted
research on interfaces for social bookmarking systems and on the cognitive
benefits of tagging. Budiu was also a user researcher at Microsoft Corporation, where she
explored future directions and made strategic recommendations for incorporating user-generated
content and social web features into MSN. Budiu has authored more than 20 articles and
conference presentations on human-computer interaction, psychology, and cognitive science.
She holds a Ph.D. from Carnegie Mellon University.
Amy Schade is a Director based in Nielsen Norman Group’s East Coast office.
Schade works with clients internationally in telecommunications, e-commerce,
government, travel, automotive, publishing, banking, non-profit and
education, including extensive work on corporate intranets. She has
conducted user research and performed reviews on a wide variety of websites
in the United States, Canada, Europe, Asia and Australia. She presents
tutorials on user testing, intranet usability, writing for the Web, email
newsletter usability and mobile usability. She authored the NN/g reports on
intranet usability, intranet information architecture, email newsletters, and
site map usability, as well as the 2010 and 2011 Intranet Design Annuals, and
conducted many user test sessions for reports on accessibility and usability for senior citizens.
Before joining NN/g, Schade was an information architect at Arc eConsultancy, where she
created and revised architectures for sites ranging from a family-related content site to a
transaction-based sponsorship marketplace. Schade has also held various positions in web
production and advertising. She has a Master's degree from New York University’s Interactive
Telecommunications Program and a B.A. in Communications from the University of Pennsylvania.
Visual Design for Devices and Tablet 1
• Amsterdam: Thursday, April 26

• Washington D.C.: Thursday, May 17
• Chicago: Wednesday, June 27
• Toronto: Wednesday, July 25
• Sydney: Monday, August 13
• San Francisco: Wednesday, September 26
Kara McCain
The visual design for a mobile device — be it a phone or tablet — can alter a person’s perception
of the usefulness and usability of your app or website. There are unique challenges to designing
for mobile and this course focuses on the nuances creating both beautiful and usable interfaces
for your users.
What You’ll Learn

As a companion to our seminars Mobile User Experience 1 & 2, this seminar focuses solely on the
important roles aesthetics and interaction play in the success for a mobile experience.
Course Outline
This course focuses on three main categories:
The visual anatomy of mobile design
• Icons–design and usage

o Icons within apps and sites
o The icon that represents an app on the phone/tablet's main screens
• Images
• Forms
• Transitions
• UI feedback, alerts & notifications, and Heads Up Displays (HUD)
• User mental models and designing physicality/realism
• Designing for gestures/discoverability
UI Patterns and Components
• Links & labels

• Buttons
• Sorts & filters
• The navigation bar
• Tabs
• Sliders
• Toggles
• Carousels
Cross-Device Design
• Achieving a recognizable style across big and small screens: unifying websites, apps,
etc., even if they can't all have the same features
• Device orientation: landscape vs. portrait
What is NOT Covered

This is not a programming/development course. We do not cover coding for iOS, Android,
HTML5, CSS, etc. This seminar focuses purely on the user experience (what is shown to users),
not about the engineering required to implement a design.
Format
This full-day tutorial includes lectures, exercises, videos and plenty of inspiring screenshots that
we deconstruct to show why they work–or where they fail.
Handouts
Who Should Attend

This seminar is intended for anyone beginning to work on or manage the user experience of a
mobile application or website, including visual designers, interaction designers, information
architects and usability specialists. Even if you’re not personally creating the design, it’s highly
useful to know the process required to design a successful mobile experience. This seminar does
not have any prerequisites, other than a general knowledge of mobile devices.
See Also:
A companion seminar, Visual Design for Mobile & Tablet 2 focuses on issues specific to designing
applications for touchscreen devices.
Instructor
Kara McCain is a User Experience Specialist with Nielsen Norman Group. For
more than 14 years, she has been creating innovative brand and user
experiences in the search, social media, luxury, hotel, travel, jewelry,
telecommunications, professional sports, e-commerce, government, and food-
service industries. Her expertise has allowed her to develop and implement
highly successful Web and print design strategies for Fortune 500 companies.
Before joining Nielsen Norman Group, McCain was a senior visual and
interaction designer for Yahoo!'s Search and Social Media division, working on
Yahoo! Answers, Local search, and defining the way people integrate social
media into search. Prior to Yahoo!, she also led the Web design effort for
clients such as Verizon, Pizza Hut, The Ritz-Carlton hotels, the Dallas Stars, Radio City
Entertainment and the Zale Diamond Corporation.
Visual Design for Mobile and Tablet 2
• Amsterdam: Friday, April 27

• Washington D.C.: Friday, May 18
• Chicago: Thursday, June 28
• Toronto: Thursday, July 26
• Sydney: Tuesday, August 14
• San Francisco: Thursday, September 27
Kara McCain
The visual design for a mobile device — be it a phone or tablet — can alter a person’s perception
of the usefulness and usability of your app or website. There are unique challenges to designing
for mobile and this course takes a deeper dive into the visual details of creating both beautiful
and usable interfaces for your users.
What You’ll Learn

As a companion to Visual Design for Mobile & Tablet 1 (and our seminars Mobile User Experience
1 & 2), this seminar focuses solely on the details and nuances of aesthetics and interaction and
the roles they play in the success for a mobile experience.
Course Outline
This course dives deeper into design techniques for:
• Launcher screens
• My account/user profiles
• Educational walk-throughs/instructions
• Customizing nav/tab bars
• Contextual navigation/footers
• Overlays, gradients, transparency, drop shadows, textures/patterns
• Popovers & modals
• Animation and cartoon physics: how to make animations that
o strengthen usability instead of confusing or annoying users
o remain enjoyable after repeated viewing
o follow the rules of the virtual world and not the physical world
• Notification design
• Check-in screens
• Activity feeds
• Comments/comment detail
• User ratings
• Search & empty data sets/404 pages
• Lists & table views
o How to display and manage larger amounts of data than you'd thought possible
on a small screen
• Maps
• Responsive design
o How well can we adapt the same content for the transmedia environment,
encompassing desktop, tablet, and phones
• Advertising
o Balance between having ads be noticed and retaining the aesthetic integrity of the
main design
o Approaches to advertising that leverage mobile use cases instead of fighting
against them
What is NOT Covered

This is not a programming/development course. We do not cover coding for iOS, Android,
HTML5, CSS, etc. This seminar focuses purely on the user experience (what is shown to users),
not about the engineering required to implement a design.
Format
This full-day tutorial includes lectures, exercises, videos and plenty of inspiring screenshots that
we deconstruct to show why they work–or where they fail.
Handouts
Who Should Attend

This seminar is intended for anyone with experience working on or managing the user experience
of a mobile application or website, including visual designers, interaction designers, information
architects and usability specialists. Even if you’re not personally creating the design, it’s highly
useful to know the process required to design a successful mobile experience. This seminar is the
advanced companion to Visual Design for Mobile & Tablet 1 and it's a prerequisite for this second
course to have either attended the first course or have equivalent practical experience.
Instructor
Kara McCain is a User Experience Specialist with Nielsen Norman Group. For
more than 14 years, she has been creating innovative brand and user
experiences in the search, social media, luxury, hotel, travel, jewelry,
telecommunications, professional sports, e-commerce, government, and food-
service industries. Her expertise has allowed her to develop and implement
highly successful Web and print design strategies for Fortune 500 companies.
Before joining Nielsen Norman Group, McCain was a senior visual and
interaction designer for Yahoo!'s Search and Social Media division, working on
Yahoo! Answers, Local search, and defining the way people integrate social
media into search. Prior to Yahoo!, she also led the Web design effort for
clients such as Verizon, Pizza Hut, The Ritz-Carlton hotels, the Dallas Stars, Radio City
Entertainment and the Zale Diamond Corporation.

Mobile Usability 2nd Edition

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Mobile Usability 2nd Edition

Hochgeladen von

Copyright:

Verfügbare Formate

Usability of Mobile Websites and

by Raluca Budiu and Jakob Nielsen

WWW.NNGROUP.COM 48105 WARM SPRINGS BLVD., FREMONT CA 94539–7498 USA

COPYRIGHT © NIELSEN NORMAN GROUP, ALL RIGHTS RESERVED.

2 INFO@NNGROUP.COM Executive Summary

Executive Summary ...................................................................... 7

User Research ......................................................................................... 7

Mobile User Experience Improving Slowly .................................................... 8

Apps Beat Sites........................................................................................ 9

Most Usability Guidelines Confirmed ........................................................... 9

Mobile Design = Small and Targeted ........................................................... 9

What’s New in the Second Edition ............................................... 11

Research Overview ..................................................................... 12

What People Do On Mobile Phones .............................................. 14

Mobile Information Needs ........................................................................ 14

Mobile Activities ..................................................................................... 16

Success Rates on Mobile Devices ................................................ 18

Success Rates: Does the Phone Matter? .................................................... 19

Success rates: Historical Comparison ........................................................ 21

Mobile Strategy Guidelines.......................................................... 23

Should You Go Mobile?............................................................................ 23

Application Versus Mobile Website ............................................................ 27

What to Include On Mobile ...................................................................... 31

Who Your Users Are .......................................................................................... 31

Content that Should Be Included on Mobile .......................................................... 34

Mobile Sites ........................................................................................... 34

Do Users Prefer Full Sites or Mobile Websites? ..................................................... 34

Mobile Site, But Which Device? .......................................................................... 35

© NIELSEN NORMAN GROUP WWW.NNGROUP.COM 3

Designing a Mobile Site ..................................................................................... 43

Mobile Apps ........................................................................................... 43

Differences Between Mobile Platforms for Apps .................................................... 43

Making Your App Findable.................................................................................. 44

What to Include in a Mobile App ......................................................................... 47

From Desktop to Phone ..................................................................................... 49

Principles of Mobile Usability ...................................................... 52

General Guidelines for Mobile Websites and Apps ....................... 54

Dropdown Boxes, Menus, Carousels.......................................................... 69

Logging in and Registering ...................................................................... 86

Lists and Scrolling ................................................................................ 104

Navigation ........................................................................................... 119

Readability .......................................................................................... 149

Images, Animation, and Videos .............................................................. 151

Icons .................................................................................................. 166

Errors ................................................................................................. 169

Maps and Location Information .............................................................. 174

Shopping ............................................................................................ 183

Banking and Transactions...................................................................... 188

Feature Phones ......................................................................... 191

General Guidelines for Touch Phones ........................................ 195

4 INFO@NNGROUP.COM Executive Summary

Gestures ............................................................................................. 206

Horizontal Swipe ............................................................................................ 210

Tapping and Content....................................................................................... 213

Orientation .......................................................................................... 215

Input .................................................................................................. 218

Guidelines for Apps ................................................................... 222

Immersive Apps ................................................................................... 222

Input .................................................................................................. 226

Modal Dialogs and Alerts ....................................................................... 233

Registration and Log In ......................................................................... 234

Notifications ........................................................................................ 238

Tab Bars and Tool Bars ......................................................................... 240