Even long-term users of a computer system usually know and use only a tiny fraction of its available commands and features. If the design has good usability, people learn a core set of features fairly easily during their early days of system use. And then they stagnate and don't get much better. Decades can pass with even frequent system users barely learning one or two new things per year.
Stagnating user expertise is not limited to any particular design category. It's been documented for all classes of user interfaces across decades of research.
Old Examples
One early research effort was Steve Draper's study of Unix experts, published in 1984. Not only did Draper find that it took at least 7 years to become a skilled Unix system administrator, but also that different Unix experts had different areas of knowledge. These power geeks didn't know everything: each Unix expert had gone down a different path of knowledge acquisition, while remaining much less skilled in other areas.
More recently, in Microsoft’s early usability research on the software release that would become Office 2007, the UX team asked customers to nominate new features that they would like to see added to the package. The vast majority of "new" feature requests were for things that had been in Office for years. As a result, the design team decided to emphasize discoverability in the new user interface and thus Microsoft introduced the ribbon. Ensuring that people understood the old features was more important than adding new ones.
Indeed, the Office 2007 redesign worked well, and people now use more of the package's functionality. Even so, most people still use only a small percentage of the available features.
New Examples
We recently conducted a bunch of usability studies of current mobile applications to update our courses on mobile & tablet app design. It was striking how often users were unaware of basic features of the apps they frequently used. iPhone, Android, or Windows Phone — didn’t matter; the finding was the same across all the platforms we tested.
One component of this new research was a bit different than our typical usability studies: we included a "show and tell" segment in which we asked users to show us the apps on their phone and tell us how they used them. Sometimes, we also asked participants to use a feature that they hadn't told us about. In all cases, the common reaction was: "Wow, I didn't know that this app could do that. Thanks for showing me."
(We didn't actually show users a feature they hadn’t mentioned — we asked them to perform a task that required them to find the feature on their own. Still, to the extent that we pointed people toward something they wouldn’t have looked for otherwise, we deviated from approved testing protocols. In this case, doing so was fine because we were running our umpteenth usability study of mobile apps, so we had already discovered all the basic findings. But if you're testing something for the first time, definitely take a less directive approach to avoid biasing users in even the smallest way.)
Following are a few examples of basic mobile app features that users hadn't discovered, despite being frequent users:
Bank of America (iPhone): One person used this app regularly for checking balances and making sure that checks had cleared, but was unaware of the check deposit feature. She did find it easily when we asked; in real life, however, the feature might as well not have existed because the user wasn't looking for it.
MyFitnessPal (Windows Phone): Our test participant used this app daily for dieting. She mentioned that she hadn't discovered many features until her friends told her about them (e.g., she didn’t know she could track her weight). In our tests, she didn’t know how to access information from a previous day, and she often forgot that she could swipe horizontally to see more features. This lack of feature visibility is a common problem with Windows Phone, as shown in this screenshot:
Wag (iPhone): One person used this app often to order items for her dog. She didn't know how to save an item and didn't discover the menu with this command on the homepage. Unfortunately, this menu appears only on the homepage; it disappears on other pages, making the feature even less discoverable.
Left: Wag application homepage with the menu expanded.
Right: Product page without access to the menu (unless you return to the top screen).
Zappos (Android): The user didn't know how to add an item to a favorites list.
Weave (newsreader, Windows Phone): One test user read news everyday with this app, but he didn’t realize he could add another publication that was not included in the default list of sources.
iMuscle (iPhone): One person used this app often for browsing and looking at exercises. Even so, he didn't know how to create a workout routine targeting a set of muscles. Also, when we asked, he couldn’t find exercises that require no special equipment.
Hulu Plus (Android): A user typically found and watched shows in Hulu, but didn't know how to add shows to his queue for later viewing.
In all of these cases (and many others we tested), users didn't know about features that were just a smidgen outside the minimalist use case. Read the news, yes. Find other news sources, no.
Because many of the apps had sufficiently good usability, users could find the features once prompted. In the real world, however, there's no kindly study facilitator to continuously push users to find new functionality. Outside the lab, these rather basic features would most likely have remained undiscovered for several more years of use.
Why Expertise Stagnates
People can use computer systems for years without knowing about features that would be very useful to them. This is true even for productivity applications that people rely on for their livelihood, such as email, word processing, and spreadsheets. In testing intranets, we frequently find that employees are unaware of key enterprise features.
This seems like a paradox, because users would gain substantial benefits — potentially accrued over several years — if only they bothered to spend a few moments looking around the user interface. The ROI seems clear.
However, while users might have a mathematically true ROI from learning more about user interfaces, the ROI might not be so clear from a behavioral standpoint. The problem is that the investment occurs immediately: users must suffer the interaction cost of navigating through obscure parts of the user interface. In contrast, the benefit is deferred: users realize it only in small increments in some undefined future moments when they might use newly discovered features.
Standard economics tells us how to compute the NPV (net present value) of a stream of future benefits: you add them up, while discounting each benefit by an appropriate interest rate that increases the further into the future something happens.
Humans are probably wired to assume a stupendously large discount on those future small benefits. In the ancestral environment, you'd be dead before some uncertain future event could benefit you enough to matter.
Whatever the underlying biology, it's an empirical fact — based on 3 decades of research — that users are narrowly focused on the present. What's in front of them is all they know. What they're doing right now is all that matters.
People don't read manuals. People don't go exploring all over the user interface in search of neat features. People don't investigate whether there's a better way of doing something once they’ve learned an approach that works. (Maybe you do these things, but you’re not an average user.)
Learning is hard work, and users don't want to do it. That's why they learn as little as possible about your design and then stay at a low level of expertise for years. The learning curve flattens quickly and barely moves thereafter.
Can You Encourage User Learning?
Most important, accept that users are reluctant to learn. You might think that your website or application is particularly important and useful. But to users, it's one of hundreds they have to deal with. Yours is unlikely to be the first user interface for which all users become sophisticated experts and learn all the features.
Although you can never solve the problem of stagnating user expertise, there are some strategies to alleviate it:
- Fewer features. Every extra feature makes the other features harder to discover and harder to learn. Paradoxically, by offering fewer features, you might find that people use more of them.
- Visible features. Don't make people search for key features. Sure, you can use progressive disclosure to hide advanced features, but you must offer users a visible way to unhide them.
- Visible signifiers. The perceived affordances must clearly indicate what people can do and how they should do it. The guidelines for visualizing links on web pages are a good example. Resist overly flat design in which all items look the same and nothing looks clickable.
- Just-in-time learning. Although users won't read manuals, they sometimes read small tips that are shown in context.
- Exploit teachable moments. Error messages can guide users toward better ways to solve their problems.
- Forgiveness. Exploration is more likely when users can easily get themselves out of any situation. Undo (including the Back button) and clear navigation are essential. Conversely, if people try a new feature and get hurt, you can bet that they won’t be exploring your UI again.
- Low-commitment previews. Even more forgiving is letting users see what will happen before they actually do it. Examples include the item counts for choosing various options in faceted navigation and the way a document temporarily reformats while hovering over styles in Microsoft Word.
- Plain usability. The easier something is, the more likely users will have the cognitive surplus to learn it instead of spending their brainpower struggling with simply operating the UI.
Follow these guidelines, and users will eventually know and use more of your features. They’ll thus get better results from using your design, and they'll like it better. Everybody benefits.
Reference
Stephen W. Draper (1984): "The nature of expertise in UNIX" in B. Shackel (ed.) Human-Computer Interaction — Proceedings of the INTERACT '84 Conference (North-Holland: Amsterdam), pp. 465–471.
