Home / Books / Don’t Make Me Think
Don’t Make Me Think: A Common Sense Approach to Web (and Mobile) Usability
10/10

Don’t Make Me Think

Steve Krug

If I had to pick only one book for learning UX Design, it would be this one. It should be required reading for all designers. It covers what usability is, why it’s important, and the simplest way you can start usability testing today. Highly recommended for all designers and product managers.

Buy it

Highlights and notes

Definition of usability: A person of average (or even below average) ability and experience can figure out how to use the thing to accomplish something without it being more trouble than it’s worth.

What should I do to make my site or app is easy to use? Don’t make me think!

If you have room in your head for only one usability rule, make it this one.

When I look at a Web page it should be self-evident. Obvious. Self-explanatory.

I should be able to “get it”—what it is and how to use it—without expending any effort thinking about it.

All kinds of things on a Web page can make us stop and think unnecessarily. Take names, for example. Typical culprits are cute or clever names, marketing induced names, company specific names, and unfamiliar technical names.

There’s almost always a plausible rationale—and a good, if misguided, intention—behind every usability flaw.

Another needless source of question makes over people’s heads is links and buttons that aren’t obviously clickable. As a user, I should never have to devote a millisecond of thought to whether things are clickable—or not.

Every question mark adds to our cognitive workload, distracting our attention from the task at hand.

People don’t like to puzzle over how to do things.

The fact that people who build the site didn’t care enough to make things obvious—and easy—can erode our confidence in the site and the organization behind it.

You can’t make everything self evident.

Your goal should be for each page or screen to be self-evident, so that just by looking at it the average user will know what it is and how to use it. In other words, they’ll “get it” without having to think about it.

Sometimes, though, particularly if you’re doing something original or groundbreaking or something that’s inherently complicated, you have to settle for self-explanatory.

Here’s the rule: If you can’t make something self-evident, you at least need to make it self-explanatory.

Making every screen self-evident is like having good lighting at a store: it just makes everything seem better. Using a site that doesn’t make us think about unimportant things feels effortless, whereas puzzling over things that don’t matter to us tends to sap our energy and enthusiasm—and time.

If Web pages are going to be effective, they have to work most of their magic at a glance. And the best way to do this is to create pages that are self-evident, or at least self-explanatory.

We act as though people are going to pour over each age, reading all of our carefully crafted text, figuring out how we’ve organized things, and weighing their options before deciding which link to click.

What they actually do most of the time (if we’re lucky) is glance at each new page, scan some of the text, and click on the first link that catches their interest or vaguely resembles the thing they’re looking for. There are almost always large parts of the page that they don’t even look at.

It makes sense that we picture a more rational, attentive user when we’re designing pages. It’s only natural to assume that everyone uses the Web the same way we do, and—like everyone else—we tend to think that our own behavior is much more orderly and sensible than it really is.

Fact of Life #1: We don’t read pages. We scan them.

Why do we scan?

What we see when we look at a page depends on what we have in mind, and it’s usually just a fraction of what’s there.

We tend to focus on words and phrases that seem to match (a) the task at hand or (b) our current or ongoing personal interests. And of course, © the trigger words that are hardwired into our nervous systems, like “Free,” “Sale,” and “Sex,” and our own name.

Fact of Life #2: We don’t make optimal choices. We satisfice.

When we are designing pages, we tend to assume that users will scan the page, consider all of the available options, and choose the best one.

In reality, though, most of the time we don’t close the best option—we choose the first reasonable option, a strategy known as satisficing. As soon as we find a link that seems like it might lead to what we’re looking for, there’s a very good chance that we’ll click it.

So why don’t Web users look for the best choice?

Fact of Life #3: We don’t figure out how things work. We muddle through.

One of the things that becomes obvious as soon as you do any usability testing—whether you’re testing Web sites, software, or household appliances—is the extent to which people use things all the time without understanding how they work, or with completely wrong-headed ideas about how they work.

Faced with any sort of technology, very few people take the time to read instructions. Instead, we forge ahead and muddle through, making up our own vaguely plausible stories about what we’re doing and why it works.

Why do we muddle through?

If your audience is going to act like you’re designing billboards, then design great billboards.

How to design great billboards:

One of the best ways to make almost anything easier to grasp in a hurry is to follow the existing conventions—the widely used or standardized design patterns.

When applied well, Web conventions make life easier for users because they don’t have to constantly figure out what things are and how they’re suppose to work as they go from site to site.

One problem with conventions, though: Designers are often reluctant to take advantage of them.

Faced with the prospect of following a convention, there’s a great temptation for designers to try reinventing the wheel instead, largely because they feel (not incorrectly) that they’ve been hired to do something new and different, not the same old thing.

Occasionally, time spent reinventing the wheel results in a revolutionary new rolling device. But usually it just amounts to time spent reinventing the wheel.

If you’re not going to use an existing Web convention, you need to be sure that what you’re replacing it with either (a) is so clear and self-explanatory that there’s no learning curve—so it’s as good as the convention, or (b) adds so much value that it’s worth a small learning curve.

My recommendation: Innovate when you know you have a better idea, but take advantage of conventions when you don’t.

The rule of thumb is that you can—and should—be as creative and innovative as you want, and add as much aesthetic appeal as you can, as long as you make sure it’s still usable.

You often hear consistency cited as a absolute good. People win a lot of design arguments just by saying “We can’t do that. It wouldn’t be consistent.”

Here’s the rule to keep in mind:

Clarity trumps consistency.

If you make something significantly clearer by making it slightly inconsistent, choose in favor of clarity.

Create effective visual hierarchies

Pages with clear visual hierarchies have three traits:

A good visual hierarchy saves us work by preprocessing the page for us, organizing and prioritizing its contents in a way that we can grasp almost instantly.

But when a page doesn’t have a clear visual hierarchy—if everything looks equally important, for instance—we’re reduced to the much slower process of scanning the page for revealing words and phrases and then trying to form our own sense of what’s important and how things are organized. It’s a lot more work.

Break up pages into clearly defined areas

Dividing the pages into clearly defined areas is important because it allows users to decide quickly which areas of the page to focus on and which areas they can safely ignore.

Make it obvious what’s clickable

In general, you’ll be fine if you just stick to one color for all text links or make sure that their shape and location identify them as clickable. Just don’t make silly mistakes like using the same color for links and nonclickable headings.

One of the great enemies of easy-to-grasp pages is visual noise.

There are really three different kinds of noise.

Format text to support scanning

Here are the most important things to can do to make your pages scan-friendly:

If you really want to learn about making content scannable, order Ginny Redish’s book Letting Go of the Words.

“It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice.” —Krug’s Second Law of Usability

In general, I think it’s safe to say that users don’t mind a lot of clicks as long as each click is painless and they have continued confidence that they’re on the right track—following what’s often called the “scent of information.”

When you can’t avoid giving me a difficult choice, you need to go out of your way to give me as much guidance as I need—but no more.

This guidance works best when it’s:

“Get rid of half the words on each page, then get rid of half of what’s left.” —Krug’s Third Law of Usability

Getting rid of all those words that no one is going to read has several beneficial effects:

Happy talk must die

Happy talk is like small talk—content-free, basically just a way to be sociable. But most Web users don’t have time for small talk; they want to get right to the point. You can—and should—eliminate as much happy talk as possible.

Instructions must die

Another major source of needless words is instructions.

Your objective should always be to eliminate instructions entirely by making everything self-explanatory, or as close to it as possible. When instructions are absolutely necessary, cut them back to their bare minimum.

It’s a fact: People won’t use your Web site if they can’t find their way around it.

Navigation has some important—and easily overlooked—functions:

On pages where a form needs to be filled in, the persistent navigation can sometimes be an unnecessary distraction.

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

For search, avoid:

There are four things you need to know about page names:

The name needs to match what I clicked. Even though nobody ever mentions it, every site makes an implicit social contract with its visitors: The name of the page will match the words I clicked to get there.

Best practices for implementing breadcrumbs:

Whenever someone hands me a Home page design to look at, there’s on thing I can almost always count on: They haven’t made it clean enough what the site is.

As quickly and clearly as possible, the Home page needs to answer the four questions I have in my head when I enter a new site for the first time:

I need to be able to answer these questions at a glance, correctly and unambiguously, with very little effort.

There are three important places on the page where we expect to find explicit statements of what the site is about.

Some attributes to look for when choosing a tagline:

There’s something about the Home page that seems to inspire shortsighted behavior.

The worst of these behaviors, of course, is the tendency to try to promote everything.

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 strong 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.

All of us who work on Web sites have one thing in common—we’re also Web users. And like all Web users, we tend to have strong feelings about what we like and don’t like about Web sites.

And when we’re working on a Web team, it turns out to be very hard to check those feelings at the door.

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 most users are like us.

As soon as the clash of personal and professional opinions results in a stalemate, the conversation usually turns to finding some way to (whether it’s the opinion of an outside expert, published research, a survey, or focus groups) to determine what most users like or don’t like—to figure out what the Average Web User is really like. The only problem is, there is no Average User.

In fact, all of the time I’ve spent watching people use them Web has head me to the opposite conclusion:

All Web users are unique and all Web use is basically idiosyncratic.

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

There’s really only one way to answer that kind of question: testing.

There’s no substitute for it.

Where debate 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 works or doesn’t work. And by opening our eyes to just how varied users’ motivations, perceptions, and responses are, testing makes it hard to keep thinking that all users are like us.

Repeat after me: Focus groups are not usability tests.

In the 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 test 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.

Focus groups can be great for determining what your audience wants, needs, and likes–in the abstract. They’re good for testing whether the idea behind your site makes sense and your value proposition is attractive, to learn more about how people currently solve the problems your site will help them with, and to find out how they feel about you and your competitors.

But they’re not good for learn about whether your site works and how to improve it.

Here are the main things I know about usability testing:

I think every Web development team should spent one morning a month doing usability testing.

Why a morning a month?

How many users do you need? I think the ideal number for each round of do-it-yourself testing is three.

Here’s why:

You can find more problems in half a day than you can fix in a month.

It’s good to do your testing with participants who are like the people who will use your site, but the truth is that 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.

Recruit loosely and grade on a curve.

In other words, try to find users who reflect your audience, but don’t get hung up about it. Instead, loosen up your requirements and then make allowances for the differences between your participants and your audience. When somebody has a problem, ask yourself “Would our users have that problem, or was it only a problem because they didn’t know what our users know?”

If using your site requires specific domain knowledge (e.g., a currency exchange site for money management professionals), then you’ll need to recruit some people with that knowledge. But they don’t all have to have it, since many of the most serious usability problems are things that anybody will encounter.

I’m in favor of always using some participants who aren’t from your target audience, for three reasons:

How do you find participants?

There are many places and ways to recruit test participants, like user groups, trade shows, Craigslist, Facebook, Twitter, customer forums, a pop-up on your site, or even asking friends and neighbors.

If you’re going to do your own recruiting, I recommend that you download the Nielsen Norman Group’s free 147-page report How to Recruit Participants for Usability Studies. You don’t have to read it all, but it’s an excellent source of advice.

Typically participant incentives for a one-hour test session range from $50 to $100 for “average” Web users to several hundred dollars for busy, highly paid professionals, like cardiologists for instance.

Where do you test?

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

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 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.

Who should do the testing?

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.

I’m assuming that you’re going to facilitate the tests yourself, but if you’re not, try to choose someone who tends to be patient, calm, empathetic, and a good listener.

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.

Who should observe?

As many people 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.

You’ll need an observation room (usually a conference room), a computer with Internet access and screen sharing software, and a large screen monitor or projector and a pair of external speakers so everyone can see and hear what’s happening in the test room.

During the break after each test session, observers need to write down the three most series usability problems they noticed during that session so they can share them in the debriefing. You can download a form I created for this purpose from my Web site. They can take as many notes as they want, but it’s important that they make this short list because, as you’ll see, the purpose of the debriefing is to identify the most serious problems so they get fixed first.

What do you test, and when do you test it?

As any usability professional will tell you, it’s important to start testing as early as possible and to keep testing through the entire development process.

In fact, it’s never too early to start. Even before you begin designing your site, for instance, 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.

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

How do you choose the tasks to test?

For each round of testing, you need to come up with the tasks: the things the participants will try to do.

The tasks you test in a given round will depend partly on what you have available to test. If all you have is a rough sketch, for instance, the task may consist of simply asking them to look at it and tell you what they think it is.

If you have more than a sketch to show them, though, 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:

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 that 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 cookbook for under $14.” It increases their emotional investment and allows them to use more of their personal knowledge of the content.

What happens during the test?

You can download the script 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.

A typical one hour test would be broken down something like this:

Note: While the participant is doing the tasks, I’m careful not to ask leading questions because I don’t want to bias her. But I always save some time at the end specifically to ask probing questions so I can understand more about what happened and why it happened.

Typical problems

Here are some of the types of problems you’re going to see more often:

The debriefing: Deciding what to fix

After each round of tests, you should make time as soon as possible for the team to share their observations and decide which problems to fix and what you’re going to do to fix them.

I recommend that you debrief over lunch right after you do the tests, while everything is still fresh in the observers’ minds.

Whenever you test, you’re almost always going to find some serious usability problems. Unfortunately, they aren’t always the ones that get fixed. Often, for instance, people will say, “Yes, that’s a real problem. But that functionality is all going to change soon, and we can live with it until then.” Or faced with a choice between trying to fix one serious problem or a lot of simple problems, they opt for the low hanging fruit.

Focus ruthlessly on fixing the most serious problems first.

Here’s the method I like to use to make sure this happens:

You don’t have to fix each problem perfectly or completely. You just have to do something—often just a tweak—that will take it out of the category of “serious problem.”

Here are some tips for deciding what you fix—and what not to do:

Tw other ways to do testing:

Excuses for not doing testing:

We don’t have the time. Done right, it will save time because you won’t have to (a) argue endlessly and (b) redo things at the end.

We don’t have the money. You should only have to spend a few hundred dollars for each round of testing—even less if your participants are volunteers.

Mobile

The principles are still the same for usability on mobile.

One way to look at design is that it’s essentially about constraints and tradeoffs.

Whenever you’re designing, you’re dealing with constraints. And where there are constraints, there are tradeoffs to be made.

In my experience, many—if not most—serious usability problems are the result of a poor decision about a tradeoff.

Managing real estate challenge should be done at the cost of usability.

Two things to know about scalable design (responsive, adaptive, dynamic layout, etc.):

Mobile usability suggestions:

Don’t hide your affordances

For affordances to work, they need to be noticeable, and some characteristics of mobile devices have made them less noticeable or, worse, invisible. And by definition, affordances are the last thing you should hide.

No cursor = no hover = no clue

As a designer, you need to be away that these elements don’t exist for mobile users and try to find ways to replace them.

On “flat design”

Affordances require visual distinctions. But the recent trend in interface design has moved in exactly the opposite direction: removing visual distinctions and “flattening” the appearance of interface elements.

Unfortunately, Flat design has a tendency to take along with it not just potentially distracting decoration but also the useful information that the more textured elements were conveying.

By removing a number of these distinctions from the design palette, Flat design makes it harder to differentiate things.

Be careful that your responsive design solutions aren’t loading up pages with huge amounts of code and images that are larger than necessary for the user’s screen.

My definition of usability:

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].

Delight is a bit harder to pin down. The words that people use when describing delightful products: fun, surprising, impressive, captivating, clever, and even magical.

Delightful apps usually come from marrying an idea about something people would really enjoy being able to do, but don’t imagine it’s possible, with a bright idea about how to use something new technology to accomplish it.

Building delight into mobile apps has been increasingly important because the app market is so competitive.

Making your app delightful is a fine objective. Just don’t focus so much attention on it that you forget to make it usable, too.

One of the biggest problems with apps is that they have more than a few features they may not be very easy to learn.

For the most part, doing usability testing on mobile devices is exactly the same.

Almost everything that’s different when you’re doing mobile testing isn’t about the process, it’s about logistics.

One of the main reasons why mobile testing is complicated is that some of the tools we rely on for desktop testing don’t exist yet for mobile devices.

Until technology based solutions come along, here’s some recommendations: