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

by Krug Steve

Almost all Web users expect the Site ID to be a button that can take you to the Home page.

every page should have either a search box or a link to a search page. And unless there’s very little reason to search your site, it should be a search box.

If you want to give me the option to scope the search, give it to me when it’s useful—when I get to the search results page and discover that searching everything turned up far too many hits, so I need to limit the scope.

But the reality is that users usually end up spending as much time on lower-level pages as they do at the top.

It may seem trivial, but it’s actually a crucial agreement. Each time a site violates it, I’m forced to think, even if only for milliseconds, “Why are those two things different?”

The most common failing of “You are here” indicators is that they’re too subtle. They need to stand out; if they don’t, they lose their value as visual cues and end up just adding more noise to the page. One way to ensure that they stand out is to apply more than one visual distinction—for instance, a different color and bold text.

They’re called Breadcrumbs because they’re reminiscent of the trail of crumbs Hansel dropped in the woods so he and Gretel could find their way back home.

Breadcrumbs show you the path from the Home page to where you are and make it easy to move back up to higher levels in the hierarchy of a site.

Web experience is often more like being abducted than following a garden path. When you’re designing pages, it’s tempting to think that people will reach them by starting at the Home page and following the nice, neat paths you’ve laid out. But the reality is that we’re often dropped down in the middle of a site with no idea where we are because we’ve followed a link from a search engine, a social networking site, or email from a friend, and we’ve never seen this site’s navigation scheme before.

Everybody wants a piece of it. Since it’s likely to be the page seen by more visitors than any other—and the only page some visitors will see—things that are prominently promoted on the Home page tend to get significantly greater traffic. As a result, the Home page is the waterfront property of the Web: It’s the most desirable real estate, and there’s a very limited supply. Everybody who has a stake in the site wants a promo or a link to their section on the Home page, and the turf battles for Home page visibility can be fierce.

Because the Home page is so important, it’s the one page that everybody (even the CEO) has an opinion about.

Unlike lower-level pages, the Home page has to appeal to everyone who visits the site, no matter how diverse their interests.

The one thing you can’t afford to lose in the shuffle—and the thing that most often gets lost—is conveying the big picture. Whenever someone hands me a Home page design to look at, there’s one thing I can almost always count on: They haven’t made it clear enough what the site is.

the first few seconds you spend on a new Web site or Web page are critical.

Does it look good? Is there a lot of content or a little? Are there clear regions of the page? Which ones attract you?

If their first assumptions are wrong (“This is a site for ____”), they begin to try to force-fit that explanation on to everything they encounter. And if it’s wrong, they’ll end up creating more misinterpretations. If people are lost when they start out, they usually just keep getting...loster.

Compared to the early days of the Web, the Home page has lost its preeminence. Now people are just as likely—or more likely—to enter your site by clicking on a link in an email, a blog, or something from a social network that takes them directly to a page deep in your site.

people have become accustomed to watching short videos on their computers and mobile devices. As a result, people have now come to expect a short explanatory video on most sites and are often willing to watch them.

It’s one of the most important things to test.

Don’t confuse a tagline with a motto, like “We bring good things to life,” “You’re in good hands,” or “To protect and to serve.” A motto expresses a guiding principle, a goal, or an ideal, but a tagline conveys a value proposition.

All the stakeholders need to be educated about the danger of overgrazing the Home page and offered other methods of driving traffic, like cross-promoting from other popular pages or taking turns using the same space on the Home page.

The result is usually a room full of individuals with strong personal convictions about what makes for a good Web site.

We tend to think that most users are like us.

It’s not that we think that everyone is like us. We know there are some people out there who hate the things we love—after all, there are even some of them on our own Web team. But not sensible people. And there aren’t many of them.

The result is that designers want to build sites that look great, and developers want to build sites with interesting, original, ingenious features. I’m not sure who’s the farmer and who’s the cowman in this picture, but I do know that their differences in perspective often lead to conflict—and hard feelings—when it comes time to establish design priorities.

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 only problem is, there is no Average User. In fact, all of the time I’ve spent watching people use the Web has led me to the opposite conclusion: ALL WEB USERS ARE UNIQUE AND ALL WEB USE IS BASICALLY IDIOSYNCRATIC The more you watch users carefully and listen to them articulate their intentions, motivations, and thought processes, the more you realize that their individual reactions to Web pages are based on so many variables that attempts to describe users in terms of one-dimensional likes and dislikes are futile—and counter-productive.

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.

“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?”

Where debates about what people like waste time and drain the team’s energy, usability testing tends to defuse most arguments and break impasses by moving the discussion away from the realm of what’s right or wrong and what people like or dislike and into the realm of what works or doesn’t work.

And while usability testing will sometimes settle these arguments, the main thing it usually ends up doing is revealing that the things they were arguing about weren’t all that important. People often test to decide which color drapes are best, only to learn that they forgot to put windows in the room. For instance, they might discover that it doesn’t make much difference whether you go with cascading menus or mega menus if nobody understands the value proposition of your site.

But I finally realized that testing is really more like having friends visiting from out of town. Inevitably, as you make the rounds of the local tourist sites with them, you see things about your hometown that you usually don’t notice because you’re so used to them. And at the same time, you realize that a lot of things that you take for granted aren’t obvious to everybody.

Testing one user early in the project is better than testing 50 near the end. Most people assume that testing needs to be a big deal. But if you make it into a big deal, you won’t do it early enough or often enough to get the most out of it. A simple test early—while you still have time to use what you learn from it—is almost always more valuable than an elaborate test later.

A morning a month is about as much time as most teams can afford to spend doing testing.

Watching three participants, you’ll identify enough problems to keep you busy fixing things for the next month.

This is much better than basing your test schedule on milestones and deliverables

The purpose of this kind of testing isn’t to prove anything. Proving things requires quantitative testing, with a large sample size, a clearly defined and rigorously followed test protocol, and lots of data gathering and analysis. Do-it-yourself tests are a qualitative method whose purpose is to improve what you’re building by identifying and fixing usability problems. The process isn’t rigorous at all: You give them tasks to do, you observe, and you learn. The result is actionable insights, not proof.

You don’t need to find all of the problems. In fact, you’ll never find all of the problems in anything you test. And it wouldn’t help if you did, because of this fact: You can find more problems in half a day than you can fix in a month. You’ll always find more problems than you have the resources to fix, so it’s very important that you focus on fixing the most serious ones first.

recruiting people who are from your target audience isn’t quite as important as it may seem. For many sites, you can do a lot of your testing with almost anybody. And if you’re just starting to do testing, your site probably has a number of usability flaws that will cause real problems for almost anyone you recruit.

You’ll be using screen sharing software (like GoToMeeting or WebEx) to allow the team members, stakeholders, and anyone else who’s interested to observe the tests from another room.

You should also run screen recording software (like Camtasia from Techsmith) to capture a record of what happens on the screen and what the facilitator and the participant say. You may never refer to it, but it’s good to have in case you want to check something or use a few brief clips as part of a presentation.

Other than keeping the participants comfortable and focused on doing the tasks, the facilitator’s main job is to encourage them to think out loud as much as possible.

One of the most valuable things about doing usability testing is the effect it can have on the observers. For many people, it’s a transformative experience that dramatically changes the way they think about users: They suddenly “get it” that users aren’t all like them. You should try to do whatever you can to encourage everyone—team members, stakeholders, managers, and even executives—to come and watch the test sessions.

it’s a good idea to do a test of competitive sites. They may be actual competitors, or they may just be sites that have the same style, organization, or features that you plan on using. Bring in three participants and watch them try to do some typical tasks on one or two competitive sites and you’ll learn a lot about what works and doesn’t work without having to design or build anything.

continue to test everything the team produces, beginning with your first rough sketches and continuing on with wireframes, page comps, prototypes, and finally actual pages.

start by making a list of the tasks people need to be able to do with whatever you’re testing. For instance, if you’re testing a prototype of a login process, the tasks might be Create an account Log in using an existing username and password Retrieve a forgotten password Retrieve a forgotten username Change answer to a security question

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 often get more revealing results if you allow the participants to choose some of the details of the task. It’s much better, for instance, to say “Find a book you want to buy, or a book you bought recently” than “Find a cookbook for under $14.”

The Home page tour (3 minutes). Then you open the Home page of the site you’re testing and ask the participant to look around and tell you what they make of it. This will give you an idea of how easy it is to understand your Home page and how much the participant already knows your domain.

The tasks (35 minutes). This is the heart of the test: watching the participant try to perform a series of tasks (or in some cases, just one long task). Again, your job is to make sure the participant stays focused on the tasks and keeps thinking aloud.