Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability

by Krug Steve

A tagline is a pithy phrase that characterizes the whole enterprise, summing up what it is and what makes it great. Taglines have been around for a long time in advertising, entertainment, and publishing: “Thousands of cars at impossibly low prices,” “More stars than there are in the heavens,”1 and “All the News That’s Fit to Print,”2 for example.

Good taglines convey differentiation and a clear benefit. Jakob Nielsen has suggested that a really good tagline is one that no one else in the world could use except you, and I think it’s an excellent way to look at it.

When I enter a new site, after a quick look around the Home page I should be able to say with confidence: Here’s where to start if I want to search. Here’s where to start if I want to browse. Here’s where to start if I want to sample their best stuff.

Unfortunately, the need to promote everything (or at least everything that supports this week’s business model) sometimes obscures these entry points. It can be hard to find them when the page is full of promos yelling “Start here!” and “No, click me first!”

I usually call these endless discussions “religious debates,” because they have a lot in common with most discussions of religion and politics: They consist largely of people expressing strongly held personal beliefs about things that can’t be proven—supposedly in the interest of agreeing on the best way to do something important (whether it’s attaining eternal peace, governing effectively, or just designing Web pages). And, like most religious debates, they rarely result in anyone involved changing his or her point of view. Besides wasting time, these arguments create tension and erode respect among team members and can often prevent the team from making critical decisions. Unfortunately, there are several forces at work in most Web teams that make these debates almost inevitable. In this chapter, I’ll describe these forces and explain what I think is the best antidote.

Farmers vs. cowmen

While the hype culture (upper management, marketing, and business development) is focused on making whatever promises are necessary to attract venture capital, revenue-generating deals, and users to the site, the burden of delivering on those promises lands on the shoulders of the craft culture artisans like the designers and developers.

The belief that most Web users are like us is enough to produce gridlock in the average Web design meeting. But behind that belief lies another one, even more insidious: the belief that most Web users are like anything.

The problem is there are no simple “right” answers for most Web design questions (at least not for the important ones). What works is good, integrated design that fills a need—carefully thought out, well executed, and tested.

The point is, it’s not productive to ask questions like “Do most people like pull-down menus?” The right kind of question to ask is “Does this pull-down, with these items and this wording in this context on this page create a good experience for most people who are likely to use this site?”

And there’s really only one way to answer that kind of question: testing. You have to use the collective skill, experience, creativity, and common sense of the team to build some version of the thing (even a crude version), then watch some people carefully as they try to figure out what it is and how to use it. There’s no substitute for it.

As soon as I’d hear “launching in two weeks” (or even “two months”) and “usability testing” in the same sentence, I’d start to get that old fireman-headed-into-the-burning-chemical-factory feeling, because I had a pretty good idea of what was going on.

People often test to decide which color drapes are best, only to learn that they forgot to put windows in the room.

Here’s the difference in a nutshell: In a focus group, a small group of people (usually 5 to 10) sit around a table and talk about things, like their opinions about products, their past experiences with them, or their reactions to new concepts. Focus groups are good for quickly getting a sampling of users’ feelings and opinions about things. Usability tests are about watching one person at a time try to use something (whether it’s a Web site, a prototype, or some sketches of a new design) to do typical tasks so you can detect and fix the things that confuse or frustrate them.

The kinds of things you learn from focus groups—like whether you’re building the right product—are things you should know before you begin designing or building anything, so focus groups are best used in the planning stages of a project. Usability tests, on the other hand, should be used through the entire process.

It keeps it simple so you’ll keep doing it. A morning a month is about as much time as most teams can afford to spend doing testing. If it’s too complicated or time-consuming, it’s much more likely that you won’t make time for it when things get busy.

To conduct the test, you need a quiet space where you won’t be interrupted (usually either an office or a conference room) with a table or desk and two chairs. And you’ll need a computer with Internet access, a mouse, a keyboard, and a microphone.

The person who sits with the participant and leads them through the test is called the facilitator. Almost anyone can facilitate a usability test; all it really takes is the courage to try it, and with a little practice, most people can get quite good at it.

Choose enough tasks to fill the available time (about 35 minutes in a one-hour test), keeping in mind that some people will finish them faster than you expect. Then word each task carefully, so the participants will understand exactly what you want them to do. Include any information that they’ll need but won’t have, like login information if you’re having them use a demo account.

You can download the script that I use for testing Web sites (or the slightly different version for testing apps) at rocketsurgerymadeeasy.com. I recommend that you read your “lines” exactly as written, since the wording has been carefully chosen.

As it turns out, she’s mistaken. Fixed-price (in this case) means services available for a fixed hourly rate, while an RFP (or Request for Proposal) is actually the choice that will get her the kind of quote she’s looking for. This is the kind of misunderstanding that often surprises the people who built the site.

Just go to rocketsurgerymadeeasy.com and click on “Demo test video.”

Here are some of the types of problems you’re going to see most often: Users are unclear on the concept. They just don’t get it. They look at the site or a page and either they don’t know what to make of it or they think they do but they’re wrong. The words they’re looking for aren’t there. This usually means that either you failed to anticipate what they’d be looking for or the words you’re using to describe things aren’t the words they’d use. There’s too much going on. Sometimes what they’re looking for is right there on the page, but they’re just not seeing it. In this case, you need to either reduce the overall noise on the page or turn up the volume on the things they need to see so they “pop” out of the visual hierarchy more.

Keep a separate list of low-hanging fruit. You can also keep a list of things that aren’t serious problems but are very easy to fix. And by very easy, I mean things that one person can fix in less than an hour, without getting permission from anyone who isn’t at the debriefing. Resist the impulse to add things. When it’s obvious in testing that users aren’t getting something, the team’s first reaction is usually to add something, like an explanation or some instructions. But very often the right solution is to take something (or some things) away that are obscuring the meaning, rather than adding yet another distraction.

Unmoderated remote testing. Services like UserTesting.com provide people who will record themselves doing a usability test. You simply send in your tasks and a link to your site, prototype, or mobile app. Within an hour (on average), you can watch a video of someone doing your tasks while thinking aloud.5 You don’t get to interact with the participant in real time, but it’s relatively inexpensive and requires almost no effort (especially recruiting) on your part. All you have to do is watch the video.

And think about the fact that for most people in emerging countries, in the same way they bypassed landlines and went straight to cellphones, the smartphone is their first—and only—computer.

One way to look at design—any kind of design—is that it’s essentially about constraints (things you have to do and things you can’t do) and tradeoffs (the less-than-ideal choices you make to live within the constraints).

And it’s true that constraints are often helpful. If a sofa has to fit in this space and match this color scheme, it’s sometimes easier to find one than if you just go shopping for any sofa. Having something pinned down can have a focusing effect, where a blank canvas with its unlimited options—while it sounds liberating—can have a paralyzing effect.

One approach was Mobile First. Instead of designing a full-featured (and perhaps bloated) version of your Web site first and then paring it down to create the mobile version, you design the mobile version first based on the features and content that are most important to your users. Then you add on more features and content to create the desktop/full version. It was a great idea. For one thing, Mobile First meant that you would work hard to determine what was really essential, what people needed most. Always a good thing to do. But some people interpreted it to mean that you should choose what to include based on what people want to do when they’re mobile. This assumed that when people accessed the mobile version they were “on the move,” not sitting at their desk, so they’d only need the kinds of features you’d use on the move. For example, you might want to check your bank balances while out shopping, but you wouldn’t be likely to reconcile your checkbook or set up a new account.

Of course, it turned out this was wrong. People are just as likely to be using their mobile devices while sitting on the couch at home, and they want (and expect) to be able to do everything. Or at least, everybody wants to do some things, and if you add them all up it amounts to everything.

As a result, many useful interface features that depended on hover are no longer available, like tool tips, buttons that change shape or color to indicate that they’re clickable, and menus that drop down to reveal their contents without forcing you to make a choice. As a designer, you need to be aware that these elements don’t exist for mobile users and try to find ways to replace them.

A person of average (or even below average) ability and experience can figure out how to use the thing [i.e., it’s learnable] to accomplish something [effective] without it being more trouble than it’s worth [efficient].

Attaching a camera to the device creates a very easy-to-follow view. The observers get a stable view of the screen even if the participant is waving it around.

No matter what the real reason was, they did an outstanding job of depleting my goodwill towards both the airline and their Web site. Their brand—which they spend hundreds of millions of dollars a year polishing—had definitely lost some of its luster for me.

But there’s another important component to usability: doing the right thing—being considerate of the user. Besides “Is my site clear?” you also need to be asking, “Does my site behave like a mensch?”

Things that diminish goodwill

I should never have to think about formatting data: whether or not to put dashes in my Social Security number, spaces in my credit card number, or parentheses in my phone number. Many sites perversely insist on no spaces in credit card numbers, when the spaces actually make it much easier to type the number correctly. Don’t make me jump through hoops just because you don’t want to write a little bit of code.

Know the main things that people want to do on your site and make them obvious and easy. It’s usually not hard to figure out what people want to do on a given Web site. I find that even people who disagree about everything else about their organization’s site almost always give me the same answer when I ask them, “What are the three main things your users want to do?” The problem is, making those things easy doesn’t always become the top priority it should be. (If most people are coming to your site to apply for a mortgage, nothing should get in the way of making it dead easy to apply for a mortgage.)

Provide me with creature comforts like printer-friendly pages. Some people love being able to print stories that span multiple pages with a single click, and CSS makes it relatively easy to create printer-friendly pages with little additional effort. Drop the ads (the possibility of a banner ad having any impact other than being annoying is even greater when it’s just taking up space on paper), but don’t drop the illustrations, photos, and figures. Make it easy to recover from errors. If you actually do enough user testing, you’ll be able to spare me from many errors before they happen. But where the potential for errors is unavoidable, always provide a graceful, obvious way for me to recover. When in doubt, apologize. Sometimes you can’t help it: You just don’t have the ability or resources to do what the user wants (for instance, your university’s library system requires separate passwords for each of your catalog databases, so you can’t give users the single login they’d like). If you can’t do what they want, at least let them know that you know you’re inconveniencing them.

One of the things that I find annoying about the Tang argument (“making sites accessible makes them more usable for everyone”) is that it obscures the fact that the reverse actually is true: Making sites more usable for “the rest of us” is one of the most effective ways to make them more effective for people with disabilities. If something confuses most people who use your site, it’s almost certain to confuse users who have accessibility issues. (After all, people don’t suddenly become remarkably smarter just because they have a disability.) And it’s very likely that they’re going to have a harder time recovering from their confusion. For instance, think of the last time you had trouble using a Web site (running into a confusing error message when you submitted a form, for example). Now imagine trying to solve that problem without being able to see the page. The single best thing you can do to improve your site’s accessibility is to test it often, and continually smooth out the parts that confuse everyone. In fact, if you don’t do this first, no matter how rigorously you apply accessibility guidelines, people with disabilities still won’t be able to use your site.

As I hope you’ve seen by now, the best way to learn how to make anything more usable is to watch people actually try to use it. But most of us have no experience at using adaptive technology, let alone watching other people use it. If you have the time and the motivation, I’d highly recommend locating one or two blind Web users and spending a few hours with them observing how they actually use their screen reader software. Fortunately, someone has done the heavy lifting for you. Mary Theofanos and Janice (Ginny) Redish watched 16 blind users using screen readers to do a number of tasks on a variety of sites and reported what they observed in an article titled “Guidelines for Accessible and Usable Web Sites: Observing Users Who Work with Screen Readers.”6 6 Published in the ACM magazine Interactions (November-December 2003). With permission from ACM, Ginny has made it available for personal use at redish.net/images/stories/PDF/InteractionsPaperAuthorsVer.pdf. Yes, it’s ten years old, but it’s still relevant.

A Web for Everyone: Designing Accessible User Experiences by Sarah Horton and Whitney Quesenbery. (Their approach: “Good UX equals good accessibility. Here’s how to do both.”) Web Accessibility: Web Standards and Regulatory Compliance by Jim Thatcher et al. (“Here are the laws and regulations, and we’ll help you understand how to meet them.”)

Add appropriate alt text to every image. Add an empty (or “null”) alt attribute (<alt="">) for images that screen readers should ignore, and add helpful, descriptive text for the rest. To learn how to write good alt text—and in fact to learn how to do any of the things in this list—head over to webaim.org. The folks at WebAIM have written excellent practical articles covering the nuts-and-bolts details of almost every accessibility technique. Use headings correctly. The standard HTML heading elements convey useful information about the logical organization of your content to people using screen readers and make it easier for them to navigate via the keyboard. Use <h1> for the page title or main content heading, <h2> for the major section headings, <h3> for subheadings, and so on, and then use CSS to redefine the visual appearance of each level. Make your forms work with screen readers. This largely boils down to using the HTML <label> element to associate the fields with their text labels, so people know what they’re supposed to enter. Put a “Skip to Main Content” link at the beginning of each page. Imagine having to spend 20 seconds (or a minute, or two) listening to the global navigation at the top of every page before you could look at the content, and you’ll understand why this is important. Make all content accessible by keyboard. Remember, not everyone can use a mouse. Create significant contrast between your text and background. Don’t ever use light grey text on a d...

Now the term you hear most often is User Experience Design, or just User Experience (UXD or UX, for short), and there are probably a dozen specialties involved, like Interaction Design, Interface Design, Visual Design, and Content Management—and, of course, Usability and Information Architecture—all under the UX umbrella.

One difference between User Centered Design and User Experience Design is their scope. UCD focused on designing the right product and making sure that it was usable. UX sees its role as taking the users’ needs into account at every stage of the product life cycle, from the time they see an ad on TV, through purchasing it and tracking its delivery online, and even returning it to a local branch store.

Here are the two suggestions I’ve always heard for convincing management to support (and fund) usability work: Demonstrate ROI. In this approach, you gather and analyze data to prove that a usability change you’ve made resulted in cost savings or additional revenue (“Changing the label on this button increased sales by 0.25%”). There’s an excellent book about it: Cost-justifying Usability: An Update for the Internet Age, edited by Randolph Bias and Deborah Mayhew. Speak their language. Instead of talking about the benefits for users, learn what the current vexing corporate problems are and describe your efforts in a way that makes it clear that they’re part of the solution: Talk about things like pain points, touch points, KPIs, and CSI, or whatever management buzzwords are trending in your organization.

Get your boss (and her boss) to watch a usability test. The tactic that I think works best is getting people from higher up the food chain to come and observe even one usability test. Tell them that you’re going to be doing some testing and it would be great for the Web team’s morale if they could just poke their head in for a few minutes.

First there’s Tomer Sharon’s It’s Our Research: Getting Stakeholder Buy-In for User Experience Research Projects. Tomer is a UX Researcher at Google, and I’ve never heard him say anything that wasn’t true, pithy, and actionable.

4 There’s even a book called Evil by Design: Interaction Design to Lead Us into Temptation by Chris Nodder that explains how an understanding of human frailties can guide your design decisions. Each chapter deals with one of the Seven Deadly Sins (Gluttony, Pride, Sloth, and so on).

Don’t use small, low-contrast type. You can use large, low-contrast type, or small (well, smallish) high-contrast type. But never use small, low-contrast type. (And try to stay away from the other two, too.) Unless you’re designing your own design portfolio site, and you really, truly don’t care whether anybody can read the text or not. Don’t put labels inside form fields. Yes, it can be very tempting, especially on cramped mobile screens. But don’t do it unless all of these are true: The form is exceptionally simple, the labels disappear when you start typing and reappear if you empty the field, the labels can never be confused with answers, and there’s no possibility that you’ll end up submitting the labels along with what you type