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

by Steve Krug

  “What the deuce is it to me? You say that we go round the sun. If we went round the moon it would not make a pennyworth of difference to me or to my work.”

  I find that the most valuable contributions I make to each project always come from keeping just a few key usability principles in mind. I think there’s a lot more leverage for most people in understanding these principles than in another laundry list of specific do’s and don’ts. I’ve tried to boil down the few things I think everybody involved in design should know about usability.

  Not present at time of photo

  Just so you don’t waste your time looking for them, here are a few things you won’t find in this book:

  Hard and fast usability rules. I’ve been at this for a long time, long enough to know that there is no one “right” answer to most usability questions. Design is a complicated process and the real answer to most of the questions people ask me is “It depends.” But I do think that there are a few useful guiding principles it always helps to have in mind, and those are what I’m trying to convey.

  Predictions about the future of technology and the Web. Honestly, your guess is as good as mine. The only thing I’m sure of is that (a) most of the predictions I hear are almost certainly wrong, and (b) the things that will turn out to be important will come as a surprise, even though in hindsight they’ll seem perfectly obvious.

  Bad-mouthing of poorly designed sites and apps. If you enjoy people poking fun at things with obvious flaws, you’re reading the wrong book. Designing, building, and maintaining a great Web site or app isn’t easy. It’s like golf: a handful of ways to get the ball in the hole, a million ways not to. Anyone who gets it even half right has my admiration.

  As a result, you’ll find that the examples I use tend to be from excellent products with minor flaws. I think you can learn more from looking at good designs than bad ones.

  Now with Mobile!

  One of the dilemmas I faced when updating this book was that it’s always been a book about designing usable Web sites. Even though the principles apply to the design of anything people have to interact with (including things like election ballots and voting booths, and even PowerPoint presentations), its focus was clearly on Web design, and all the examples were from Web sites. Until recently, that’s what most people were working on.

  But now there are a lot of people designing mobile apps, and even the people working on Web sites have to create versions of them that work well on mobile devices. I know they’re very interested in how all of this applies to them.

  So I did three things:

  Included mobile examples wherever it made sense

  Added a new chapter about some mobile-specific usability issues

  And the most important one: Added “and Mobile” to the subtitle on the cover

  And as you’ll see, in some places where it made things clearer, instead of “Web site” I’ve written “Web site or mobile app.” In most cases, though, I used the Web-centric wording to keep things from getting cumbersome and distracting.

  One last thing, before we begin

  One crucial thing, really: My definition of usability.

  You’ll find a lot of different definitions of usability, often breaking it down into attributes like

  Useful: Does it do something people need done?

  Learnable: Can people figure out how to use it?

  Memorable: Do they have to relearn it each time they use it?

  Effective: Does it get the job done?

  Efficient: Does it do it with a reasonable amount of time and effort?

  Desirable: Do people want it?

  and recently even

  Delightful: Is using it enjoyable, or even fun?

  I’ll talk about these later. But to me, the important part of the definition is pretty simple. If something is usable—whether it’s a Web site, a remote control, or a revolving door—it means that

  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.

  Take my word for it: It’s really that simple.

  I hope this book will help you build better products and—if it lets you skip a few of the endless arguments about design—maybe even get home in time for dinner once in a while.

  Guiding Principles

  Chapter 1. Don’t make me think!

  KRUG’S FIRST LAW OF USABILITY

  Michael, why are the drapes open?

  —KAY CORLEONE IN THE GODFATHER, PART II

  People often ask me:

  “What’s the most important thing I should do if I want to make sure my site or app is easy to use?”

  The answer is simple. It’s not “Nothing important should ever be more than two clicks away” or “Speak the user’s language” or “Be consistent.”

  It’s...

  “Don’t make me think!”

  For as long I can remember, I’ve been telling people that this is my first law of usability.

  It’s the overriding principle—the ultimate tie breaker when deciding whether a design works or it doesn’t. If you have room in your head for only one usability rule, make this the one.

  For instance, it means that as far as is humanly possible, 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.

  Just how self-evident are we talking about?

  Well, self-evident enough, for instance, that your next door neighbor, who has no interest in the subject of your site and who barely knows how to use the Back button, could look at your Home page and say, “Oh, it’s a _____.” (With any luck, she’ll say, “Oh, it’s a _____. Great!” But that’s another subject.)

  Think of it this way:

  When I’m looking at a page that doesn’t make me think, all the thought balloons over my head say things like “OK, there’s the_____. And that’s a _____. And there’s the thing that I want.”

  * * *

  Not Thinking

  * * *

  But when I’m looking at a page that makes me think, all the thought balloons over my head have question marks in them.

  * * *

  Thinking

  * * *

  When you’re creating a site, your job is to get rid of the question marks.

  Things that make us think

  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.

  For instance, suppose a friend tells me that XYZ Corp is looking to hire someone with my exact qualifications, so I head off to their Web site. As I scan the page for something to click, the name they’ve chosen for their job listings section makes a difference.

  Note that these things are always on a continuum somewhere between “Obvious to everybody” and “Truly obscure,” and there are always tradeoffs involved.

  For instance, “Jobs” may sound too undignified for XYZ Corp, or they may be locked into “Job-o-Rama” because of some complicated internal politics or because that’s what it’s always been called in their company newsletter.1 My main point is that the tradeoffs should usually be skewed further in the direction of “Obvious” than we think.

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

  Another needless source of question marks 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.

  You may be thinking, “Well, it really doesn’t matter that much. If you click or tap it and nothing happens, what’s the big deal?”

  The point is that every question mark adds to our cognitive workload, distracting our attenti
on from the task at hand. The distractions may be slight but they add up, especially if it’s something we do all the time like deciding what to click on.

  And as a rule, people don’t like to puzzle over how to do things. They enjoy puzzles in their place—when they want to be entertained or diverted or challenged—but not when they’re trying to find out what time their dry cleaner closes. The fact that the people who built the site didn’t care enough to make things obvious—and easy—can erode our confidence in the site and the organization behind it.

  Another example from a common task: booking a flight.

  Granted, most of this “mental chatter” takes place in a fraction of a second, but you can see that it’s a pretty noisy process, with a lot of question marks. And then there’s a puzzling error at the end.

  Another site just takes what I type and gives me choices that make sense, so it’s hard to go wrong.

  No question marks. No mental chatter. And no errors.

  I could list dozens of things that users shouldn’t spend their time thinking about, like

  Where am I?

  Where should I begin?

  Where did they put _____?

  What are the most important things on this page?

  Why did they call it that?

  Is that an ad or part of the site?

  But the last thing you need is another checklist to add to your stack of design checklists. The most important thing you can do is to understand the basic principle of eliminating question marks. When you do, you’ll begin to notice all the things that make you think in the sites and apps you use. And eventually you’ll learn to recognize and avoid them in the things you’re building.

  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 user2 will know what it is and how to use it. In other words, they’ll “get it” without having to think about it.

  2 The actual Average User is kept in a hermetically sealed vault at the International Bureau of Standards in Geneva. We’ll get around to talking about the best way to think about the “average user” eventually.

  Sometimes, though, particularly if you’re doing something original or groundbreaking or something that’s inherently complicated, you have to settle for self-explanatory. On a self-explanatory page, it takes a little thought to “get it”—but only a little. The appearance of things (like size, color, and layout), their well-chosen names, and the small amounts of carefully crafted text should all work together to create a sense of nearly effortless understanding.

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

  Why is all of this so important?

  Oddly enough, not for the reason people usually cite:

  It’s true that there’s a lot of competition out there. Especially in things like mobile apps, where there are often many readily available (and equally attractive) alternatives, and the cost of changing horses is usually negligible (99 cents or even “Free”).

  But it’s not always true that people are fickle. For instance:

  They may have no choice but to stick with it, if it’s their only option (e.g., a company intranet, or their bank’s mobile app, or the only site that sells the rattan they’re looking for).

  You’d be surprised at how long some people will tough it out on sites that frustrate them, often blaming themselves and not the site. There’s also the “I’ve waited ten minutes for this bus already, so I may as well hang in a little longer” phenomenon.

  Besides, who’s to say that the competition will be any less frustrating?

  So why, then?

  Making every page or screen self-evident is like having good lighting in 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.

  But as you’ll see in the next chapter when we examine how we really use the Web, the main reason why it’s important not to make me think is that most people are going to spend far less time looking at the pages we design than we’d like to imagine.

  As a result, 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.

  Chapter 2. How we really use the Web

  SCANNING, SATISFICING, AND MUDDLING THROUGH

  Why are things always in the last place you look for them? Because you stop looking when you find them!

  —CHILDREN’S RIDDLE

  In all the time I’ve spent watching people use the Web, the thing that has struck me most is the difference between how we think people use Web sites and how they actually use them.

  When we’re creating sites, we act as though people are going to pore over each page, 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.

  We’re thinking “great literature” (or at least “product brochure”), while the user’s reality is much closer to “billboard going by at 60 miles an hour.”

  As you might imagine, it’s a little more complicated than this, and it depends on the kind of page, what the user is trying to do, how much of a hurry she’s in, and so on. But this simplistic view is much closer to reality than most of us imagine.

  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.

  If you want to design effective Web pages, though, you have to learn to live with three facts about real-world Web use.

  FACT OF LIFE #1: We don’t read pages. We scan them.

  One of the very few well-documented facts about Web use is that people tend to spend very little time reading most Web pages. Instead, we scan (or skim) them, looking for words or phrases that catch our eye.

  The exception, of course, is pages that contain documents like news stories, reports, or product descriptions, where people will revert to reading—but even then, they’re often alternating between reading and scanning.

  Why do we scan?

  We’re usually on a mission. Most Web use involves trying to get something done, and usually done quickly. As a result, Web users tend to act like sharks: They have to keep moving, or they’ll die. We just don’t have the time to read any more than necessary.

  We know we don’t need to read everything. On most pages, we’re really only interested in a fraction of what’s on the page. We’re just looking for the bits that match our interests or the task at hand, and the rest of it is irrelevant. Scanning is how we find the relevant bits.

  We’re good at it. It’s a basic skill: When you learn to read, you also learn to scan. We’ve been scanning newspapers, magazines, and books—or if you’re under 25, probably reddit, Tumblr, or Facebook—all our lives to find the parts we’re interested in, and we know that it works.

  The net effect is a lot like Gary Larson’s classic Far Side cartoon about the difference between what we say to dogs and what they hear. In the cartoon, the dog (named Ginger) appears to be listening intently as her owner gives her a serious talking-to about staying out of the garbage. But from the dog’s point of view, all he’s saying is “blah blah GINGER blah blah blah blah GINGER blah blah blah.”

  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.

  Like Ginger, 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, (c) 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’re 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 choose the best option—we choose the first reasonable option, a strategy known as satisficing.1 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.

  1 Economist Herbert Simon coined the term (a cross between satisfying and sufficing) in Models of Man: Social and Rational (Wiley, 1957).

  I’d observed this behavior for years, but its significance wasn’t really clear to me until I read Gary Klein’s book Sources of Power: How People Make Decisions.

  Klein spent many years studying naturalistic decision making: how people like firefighters, pilots, chessmasters, and nuclear power plant operators make high-stakes decisions in real situations with time pressure, vague goals, limited information, and changing conditions.