One of usability's main laws is that "designers are not users." This insight is about as important as "vice presidents are not users" and "users are not designers" (so don't listen to them; watch them).
The usability discipline exists because systematic methods can overcome the gap between the design team and its target audience. You don't have to rely on your best guesses: you can find out how actual customers behave and what you can do to make them buy more.
There are 3 different degrees of difference between designers and their users, from a small fissure to a gaping gulf. The strategy for bridging the gap depends on how severe it is.
Level 1: The Designer Is the User
Sometimes this is literally true: you're designing something that only you will use. If you're making a spreadsheet to track your butterfly collection, feel free to use any obscure abbreviations you please. If no one else needs to understand the design, you can safely toss the usability book out the window.
More commonly, designers at this level are core members of the larger target audience. Open software often falls into this category: designed by geeks, for geeks. That's why Linux, Apache, Perl, and many similar products have been so successful — at least as long as the audience remains a group of technology-obsessed users. Of course, these same products don't stand a chance of growing their user base to include ordinary humans.
This level is our best-case scenario. But, even when designers are representative of the target audience, a crucial difference remains: designers know far more about the product simply because they built it.
So, even here, you need usability studies both to find out how your target users think about the product and to optimize it accordingly.
Level 2: The Designer Understands the Product
Say you're designing a mobile phone. You use one yourself. You use voice mail a bit. And, from talking with your mother over dinner this last holiday, you even have some insights into how non-geeks use their phones. Bravo! You have your core persona nailed ("Mom"), you know what features are the most useful, and you know what buttons are annoying to push. You're ready to design the next killer phone — no doubt about it.
Uh, not so fast. It's true, you do use a phone. But you don't necessarily know the features people need to do their jobs (which are likely completely different than yours). And you don't know what UI most people will find easy or difficult to use.
As with the cell phone, so, too, with a whole range of other designs, such as workhorse consumer websites, news sites, photo sharing sites, intranet employee directories, or project management applications. Simply because you use these yourself, you assume you know what other users need.
In fact, there's a big gap between designers and the majority of users. Last month, for example, we tested Banana Republic's website and several male participants had trouble buying a suit there. This wasn't because the site designers didn't know about suits. It was because the navigation and product pages confused people who didn't understand how the company thinks about its products:
- Click Men in the top navigation, followed by Suits in the left nav.
- Get a category page with thumbnails of guys in various suits.
- Click a photo of a suit you like.
- Get a product page with a bigger photo of a guy wearing the suit.
- Click Add to Bag if you like the suit, and complete the checkout process.
- A few days later, you receive a package from Banana Republic. Surprise: You got only the jacket, not the complete suit.
Turns out that, to buy a suit, you have to buy both the jacket and the pants as separate SKUs. Given the interaction sequence I just outlined, how would you know? Well, if you read everything closely, you would realize that the product page under step 4 was the page for the jacket, not the suit. But the product page shows the guy wearing the suit, and we know that users don't read every last word on every Web page.
A Banana Republic product page reached by clicking through from the "suits" category page.
The initial view (left); the view after users selected an alternate photo (right).
Once you have a strong conceptual model of this process (and remember: users don't — their mental model starts out spotty), it's clear from the initial photo that it only represents the jacket. However, if you expect to see a suit based on your interaction history, you might easily believe that this photo shows a suit, even though it's showing only the suit's upper part. Furthermore, the thumbnails under the hero shot give users alternate views. This is a correct implementation of usability guidelines for product pages. Unfortunately, the last alternate photo shows the guy wearing the full suit .
So, you click Suits in the navigation, you click a product from the list of suits, and you click the Buy button on a page showing a guy wearing a full suit. Any wonder that you expect to get a suit?
I wonder how many angry customer-support calls Banana Republic has to field, and how many costly returns they have to process — all because the designers knew how the site worked and didn't expect users to have trouble with something as simple as buying a suit.
Design Team ≠ Typical Users
Generally, if you're a member of a design team, you are not representative of the target audience. I don't care if you're the interaction designer, the graphics artist, the information architect, the writer, the programmer, or the marketer. All of these people:
- know too much about the product (be it a website, intranet, application, phone, whatever);
- are too skilled in using computers and the Web in general; and
- care too much about their own baby (so they can't imagine visitors bouncing after scanning the homepage for 30 seconds — but that's what outside users do).
Finally, you're almost certainly the wrong age compared to large segments of the target audience. True, you might remember being a teenager, but that doesn't mean that you know how teens use the Web or what problems they'll have navigating your design. For sure, you have no idea about the troubles senior citizens will have using your site.
Getting to Google is Hard
How difficult is it to perform a search on Google?
I'm not talking about the challenge of formulating a good query, interpreting the results, or revising your search strategy to reap better results. Those are all very complicated research skills, and few people excel at them.
I'm talking only about the very first step in searching the Web: Getting to your favorite search engine so that you can run a search there.
Would you say this is easy or difficult? Think a bit before reading on.
**** pause ****
If you thought it's easy to get to Google, think again. In our current round of usability research, only 76% of users who expressed a desire to run a Google search were successful. In other words, 1/4 of users who wanted to use Google couldn't do so. (Instead, they either completely failed to get to any search engine or ended up running their query on a different search engine — usually whatever type-in field happened to be at hand.)
On the one hand, 76% is a high success rate. On the other hand, getting to Google is a very simple task. It's not even a true task — that is, it's not something users want to accomplish for its own sake or something we'd pose as an assignment in user testing. Getting a Google search box is the first step in searching the Web, which is only the first step in doing something real (such as, in one of our test tasks, to find "a strong vacuum cleaner that is easy to use, can pick up pet hair, and costs under $300" ).
Also, for this round of research we're deliberately recruiting above-average users, so the success rate across all Internet users is probably lower than our finding. (Our goal is to discover usability guidelines for the sites people visit after they click through from the SERP, not to document search engine market shares. As a result, we're not concerned with measuring this precisely.)
I doubt that any Web designer would be incapable of running a Google search. So, the fact that 1/4 of users can't do it is a striking demonstration that you can't rely on your own experience if you want to reach a broader audience.
Level 3: Designing for a Foreign Domain
The vast majority of high-value interaction design projects fall into this last category: mission-critical applications or B2B websites targeted at highly specialized users who perform narrow tasks that depend on expert domain knowledge within a context you can't even envision.
A few examples:
- Oil company geophysicists integrating drilling data and seismological data to determine the best place to drill for oil.
- Telephone company planners deciding when to order additional switches for a central office (buy too early and you waste millions; buy too late and you run out of lines and can't provision new subscribers). I did some studies of these applications back when I worked in the Bell System: very complicated screens.
- Gastroenterologists analyzing esophageal motility recordings for their patients.
- Insurance company claims adjusters working on customer cases, from car crashes to earthquake damage.
A website example: to beef up our forthcoming course on Fundamental Guidelines of Web Usability, we tested a number of specialized sites targeting skilled users. One set of studies involved dentists using B2B sites that promoted diagnostic dental clinic equipment. All I know about dentistry comes from being on the wrong end of the drill, so I have no clue about what dentists look for when they're deciding whether to acquire an innovative product. But I don't need to get a DDS degree to find out. We recruit real dentists and learn from them what the site should do.
If you're working on domain-specific user interfaces you have no choice: you need up-front user research (such as field studies) to discover how the experts do their work. You should also collect additional usability data at each step in the design process, beginning with testing simple paper prototypes of early feature ideas.
Bridging Gaps = Get the Data
The wider the gap between your situation and the users, their tasks, and their context, the more you need a systematic usability process to inform and adjust your design.
In most design projects, the gap is wide indeed and you usually need more usability activities than you suspect. Even when you're a member of the target audience, the design should reach wider than just your corner of the group. To achieve that, you still need usability. Just not as much.
