Don't Make Me Think by Steve Krug

Key Takeaways

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?
Simplicity is key. 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
“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. The point is that every question mark adds to our cognitive workload, distracting our attention 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.
Here’s the rule: If you can’t make something self-evident, you at least need to make it self-explanatory.
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.” We don’t read pages. We scan them. We don’t figure out how things work. We muddle through.
Design Principles – Design for scanning, not reading! Take advantage of conventions. Create effective visual hierarchies Break pages up into clearly defined areas. Make it obvious what’s clickable. Eliminate distractions. Format content to support scanning. Keep paragraphs short. Use bulleted lists. Highlight key terms.
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.
Clarity trumps consistency! If you can make something significantly clearer by making it slightly inconsistent, choose in favor of clarity.
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
This term comes from Peter Pirolli and Stuart Card’s “information foraging” research at Xerox PARC in which they drew parallels between people seeking information (“informavores”) and animals following the scent of their prey.
I think the rule of thumb might be something like “three mindless, unambiguous clicks equal one click that requires thought.”
Get rid of half the words on each page, then get rid of half of what’s left. —KRUG’S THIRD LAW OF USABILITY
Another major source of needless words is instructions. The main thing you need to know about instructions is that no one is going to read them—at least not until after repeated attempts at “muddling through” have failed.
Navigation isn’t just a feature of a Web site; it is the Web site, in the same way that the building, the shelves, and the cash registers are Sears. Without it, there’s no there there. The moral? Web navigation had better be good. One of the most crucial items in the persistent navigation is a button or link that takes me to the site’s Home page.
Given the power of searching and the number of people who prefer searching to browsing, unless a site is very small and very well organized, 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.
The name of the page will match the words I clicked to get there. In other words, if I click on a link or button that says “Hot mashed potatoes,” the site will take me to a page named “Hot mashed potatoes.” It may seem trivial, but it’s actually a crucial agreement.
Too-subtle visual cues are actually a very common problem. Designers love subtle cues, because subtlety is one of the traits of sophisticated design. But Web users are generally in such a hurry that they routinely miss subtle cues.
Think about all the things the Home page has to accommodate: Site identity and mission. Site hierarchy. Search. Teases. Content promos. Feature promos. Timely content. 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.
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. If it’s not clear to me what I’m looking at in the first few seconds, interpreting everything else on the page is harder, and the chances are greater that I’ll misinterpret something and get frustrated. But if I do “get it,” I’m much more likely to correctly interpret everything I see on the page, which greatly improves my chances of having a satisfying, successful experience. This is what I call the Big Bang Theory of Web Design. Like the Big Bang Theory, it’s based on the idea that the first few seconds you spend on a new Web site or Web page are critical. We know now from a very elegant experiment (search for “Attention Web Designers: You Have 50 Milliseconds to Make a Good First Impression!”)
Good Taglines – Good taglines are clear and informative and explain exactly what your site or your organization does. Good taglines are just long enough, but not too long. Six to eight words seem to be long enough to convey a full thought, but short enough to absorb easily. 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. 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.
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.
And the worst thing about the myth of the Average User is that it reinforces the idea that good Web design is largely a matter of figuring out what people like. 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.
Repeat after me: Focus groups are not usability tests. The main difference is that in usability tests, you watch people actually use things, instead of just listening to them talk about 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.
Testing one user early in the project is better than testing 50 near the end.
I think every Web development team should spend one morning a month doing usability testing. In a morning, you can test three users, then debrief over lunch. That’s it. When you leave the debriefing, the team will have decided what you’re going to fix before the next round of testing, and you’ll be done with testing for the month. If you’re doing Agile development, you’ll be doing testing more frequently, but the principles are still the same. For instance, you might be testing with two users every two weeks. Creating a fixed schedule and sticking to it is what’s important.
Typical 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,
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. 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.
the facilitator’s main job is to encourage them to think out loud as much as possible. The combination of watching what the participants do and hearing what they’re thinking while they do it is what enables the observers to see the site through someone else’s eyes and understand why some things that are obvious to them are confusing or frustrating to users.
For each round of testing, you need to come up with 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 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 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 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.
“What are you thinking?” (For variety, you can also say things like “What are you looking at?” and “What are you doing now?”)
Typical problems 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.
After the usability test, focus ruthlessly on fixing the most serious problems first
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.
Unmoderated remote testing. Services like UserTesting.com provide people who will record themselves doing a usability test.
Personally, my focus has always been on the three that are central to 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]. I don’t spend much time thinking about whether things are useful because it strikes me as more of a marketing question, something that should be established before any project starts.
My personal standard for a delightful app tends to be “does something you would have been burned at the stake for a few hundred years ago.”
Delightful apps usually come from marrying an idea about something people would really enjoy being able to do, but don’t imagine is possible, with a bright idea about how to use some new technology to accomplish it.
There’s one more attribute that’s important: memorability. Once you’ve figured out how to use an app, will you remember how to use it the next time you try or will you have to start over again from scratch?
Personally, I think talking to your computer is going to be one of the next big things. Recognition accuracy is already amazing; we just need to find ways for people to talk to their devices without looking, sounding, and feeling foolish. Someone who’s seriously working on the problems should give me a call; I’ve been using speech recognition software for 15 years, and I have a lot of thoughts about why it hasn’t caught on.
Most of this book has been about building clarity into Web sites: making sure that users can understand what it is they’re looking at—and how to use it—without undue effort. Is it clear to people? Do they “get it”? 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 increase goodwill – Know the main things that people want to do on your site and make them obvious and easy. Know what questions I’m likely to have, and answer them.
But I know that we all love to have definitive answers, so here’s a tiny collection of things that you should always do or never do. Don’t use small, low-contrast type.
I hope you’ll check in at my Web site stevekrug.com from time to time, and always feel free to send me email at [email protected]. I can promise you I will read it and appreciate it, even if I can’t always find enough time to reply.

What I got out of it

This is a short and purposeful book that is essential to web designers. Make it clear what you do, help people search, make things easy to scan, don’t expect people to read everything, know what questions a user will likely have and answer them… Worth reading and re-reading

Summary