The Author of ‘Don’t Make Me Think’ Discusses UX Design’s 20-Year Evolution
When I caught up with Steve Krug on a Zoom call, he was self-quarantined in his home in Brookline, Massachusetts. “We’re old people, so we’re just here,” he said.
His breezy and eminently readable book on web design, Don’t Make Me Think: A Common Sense Approach to Web Usability, now 20 years old and in its third edition, has sold more than 600,000 copies and is used as a web design primer in college courses.
The book started serendipitously in the mid-’90s era of dial-up when acclaimed magazine designer and typography sage Roger Black, who is credited with the design or redesign of Rolling Stone, the New York Times Magazine and Esquire, along with websites like Barnes & Noble’s, approached Krug about a possible book deal with Macmillan Publishers. At the time, the two had been consulting for @Home Network, one of the country’s first high-speed cable internet service providers. They were close colleagues who admired each other’s work — Black the graphic design sage and Krug the usability pro.
“He was going to do a series of books on the web. And he said, well, you could do one about usability. And I said, sure, if you can get me some money, because I can’t afford to take the time off to do it,” Krug said. “He got me far more money than made any sense.”
How much money? “Oh, he talked them into giving me $40,000. Which, if you know anything about tech books, if you get $1,000 advance to write a textbook, you’re doing really well.”
The book soon developed a passel of devotees and catapulted Krug’s consultancy Advanced Common Sense into the public spotlight. Krug’s more recent Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems, though aimed at a narrower audience and less commercially successful, has helped convince many software firms that user testing is the most reliable way to ensure products speak intuitively to everyday users, who rarely think like software engineers.
The 70-year-old’s frank, straight-talk approach to design may be why Don’t Make Me Think continues to be relevant 20 years after its release. Still, Krug, now semi-retired, remains humble about his influence on the tech community. We spoke with him to learn more about the lessons Don’t Make Me Think continues to offer designers.
If you had to break down the book into three key lessons on web usability, what would they be?
There’s one big one, which has a number of parts. When you’re designing a website, the people using it are on much shakier ground than you think. They’re going faster, they’re paying less attention, they know less about your topic, or your company, than you think, and they’re easily distracted. So I described it in the book as they’re “muddling through,” which is one of my favorite phrases. I think it’s the best description of how most people use things.
So how do you help them muddle through?
If you want them to succeed, which of course you do, you have to do everything you can to keep them from getting lost or confused or stuck. And that’s the idea of the title, which worked out very well.
“Don’t Make Me Think” really means don’t make me think about things I don’t need to think about. And pretty much everybody has understood that. I’ve seen a handful of people writing articles in the last couple of years expressing some skepticism regarding the premise, suggesting there are sites where you want to make people think. And I’m like: “Right, of course. We all want that.”
Then what’s the distinction? What do you want people to think about and what do you want them to be unaware of?
You do want them to think about the meaning of your content. You want them to think about what’s in it for them. If you’re explaining something, you want them to be able to understand your explanation. There are any number of parts of a website where people need to think. They’re learning something; it’s pretty obvious.
What you don’t want them to think about is: “What is that thing on the screen? What is it for? What’s going to happen if I click that?” You want those things to be as obvious as possible. You want it to be clear what the kinds of information are available on the site and how you navigate to them.
Can you give a couple examples of features that might confuse or distract people?
Confusing names are a big problem. Like, if you have a button that says “share,” and it’s not clear, from the context, what it shares. Whether you’d want to share this mysterious thing with other people. Things that are ambiguously named, things that are poorly organized. There’s a whole field called information architecture that’s, basically, about organizing information so people can find what they’re looking for. Another big problem is just too much stuff. There’s a tendency to try and put too much information in front of the user, rather than focusing on what they’re likely to be looking for. And so the whole thing ends up being so noisy they can’t find what they’re after.
Tell me about another important lesson in the book.
As a designer or developer, you can’t judge for yourself whether people are going to be able to use what you’re creating. You know how it’s supposed to work, which they don’t. And so you can’t self-edit, you can’t look at your own work and say, “Well, this part is going to be confusing.” What you’re more likely to say is, “Well, everybody’s going to understand that.” That’s the book’s conclusion: You need to watch other people try to use your website. And that’s why I appreciate usability testing.
In a later edition of the book, I also added a chapter on accessibility, because it’s important and it felt like the responsible thing to do. I think the arguments that are usually made for making things accessible aren’t very convincing — particularly to young able-bodied people — and a lot of sites aren’t very accessible as a result.
People overstate the case. They say, like, you know, 60 percent of people have some disability. That’s sort of a strange count. But what matters is: You should do this because it’s the right thing. It improves people's lives. And how often do you get a chance in your job to dramatically improve other people’s lives by just doing your work a little better?
What was going on in the world of web design when you wrote the book?
And it worked. The browser manufacturers caved and made things much more consistent. That was kind of the biggest thing that was going on at the time. But it was also 2000, and, so, far more people were using the internet and we’d reached the point of true, serious adoption. It had become a big deal. I was actually working on the web in 1994, consulting for Apple. And they were using AOL software to do something called e-World, the Apple-branded version of AOL, with web access. By 2000, it had come a long way.
How did your consulting background inform the book?
What I was trying to do was explain what I had always done as a usability consultant. I go in as an outsider who doesn’t know anything about a site. And I look at it from the user’s point of view and I tell the people who are building it: “Here’s what people aren’t going to understand. Here’s what you need to do.”
Why do you think it’s had such a lasting impact; you’ve said it’s still selling at the same rate as the time of its first publication?
It’s all by word of mouth, basically. Historically, the pattern was somebody would read it and they’d give it to their boss, and their boss would buy copies to give to the whole department. Nowadays, the tagline for the book is probably, “Most people’s introduction to UX.” But, at the time I wrote it, UX didn’t exist. It only really came into being with the iPhone. Because Steve Jobs proved that you could actually make money by doing user experience work and paying attention to users. And that made UX into a profession. Before that, if you had a big company, it would be hard to convince you to spend a lot of money on user experience.
What are your favorite current web interfaces?
Sadly, the one that I always cite, which is my absolute favorite, just died. It was a company called Hipmunk. It was a flight booking site for airlines. And it had the best interface ever. It did exactly what you wanted it to do. Unfortunately, about two months ago, they announced they were going out of business. I think there was a problem with their business model: You could use their site to find what you were looking for and then go directly to the carrier to book the flight. I suspect that’s what the problem was.
The sad part is now you can’t go and try it yourself. But it was the best interface because you put in the destination, “I want to go from here to here, on this class, on these dates,” and it would display a scrolling list of timelines showing you flights from all the airlines. And if there was a connecting flight, it would show you a gap between two banded chunks of flight time. At a glance, you could see which were the earlier flights, which were the later flights, which ones were going to take you forever. The default sort order, which was brilliant, was called “Agony.” At the top of the list were the flights that had the shortest layovers, the best on-time rates, and the lowest price, a combination of those factors. So just by looking at the sorted list, you knew exactly what you needed to know. You didn’t have to calculate time zone differences and layovers and all that stuff.
I also admire Uber. I think Uber works really well and, as much as I dislike Uber as a company, the interface is great. It does exactly what you need. And they have the advantage that they started late. People had been doing complicated web apps for quite a while before Uber came in. So they were able to take advantage of everything that people had learned.
Can you give some examples?
One, as compared to the taxi experience, which it replaced, Uber shows you how far away your ride is. It confirms the driver is going to the right place. So you’re not standing there thinking, they haven’t gotten here yet, am I in trouble? And so it relieves those kinds of anxieties. When you enter where you’re going, it shows you cars in your area, which, I think isn’t even true. I suspect that’s a fake. But that’s what you want. When you tell it where you want to go, it will say we have three drivers in your area, and then very quickly one of them will pick you up. And it tells you what kind of car they drive and what color it is, so you can be on the lookout for it.
What are the biggest mistakes organizations make when they attempt to redesign or refresh a website?
They tend to be overambitious. Any site you go to has some existing major flaws. And they’re probably well known by the people who run the site management. But people often think the solution is to do a major redesign instead of going in, doing triage and repairing the worst problems. The thinking is these issues can be tolerated until a redesign. Basically, they’re saying, “We’re going to allow these major problems that are costing us money and causing headaches for users to persist for another year while we work on this redesign.”
You’ve also written Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems. What are some common issues, and how can they be fixed?
If you’re having problems, parachuting in a consultant is really good and, if you can afford it, you should do it. But usability testing is even better. You get the team, you have to sit them down and watch a couple people try to use the thing. The amount of learning that goes on is always incredible. That’s the point of Rocket Surgery Made Easy: to get people to do their own usability testing, to make it clear that this is something that’s so simple you can do it yourself and it doesn’t have to take a lot of time.
What does usability testing look like for contemporary tech firms? Is it pulling in team members or potential customers into your office? Or is it something that can be done with virtual tools, remotely?
With screen-sharing software advancing a ton and tools like Zoom, Skype, and GoToMeeting, you can easily do it remotely. And there a ton of advantages. It used to be you had to drag people into your office. Remote testing makes recruiting much easier because your recruiting pool goes from people who are the kind of people you want to test with who are within 20 minutes of your office to pretty much anybody. And, obviously, with the coronavirus, it’s a real boon to being able to conduct user testing remotely.
Essentially, the participant is sharing their screen with you so you can see what they’re doing, and you have the conversation. You assign them tasks and they think out loud, which is the key. There’s also unmoderated testing (such as usertesting.com), where basically you send somebody the tasks that you want them to do and the URL of the site or your prototype or app. And a pool of testers will sit for 15 or 20 minutes and do those tasks and it gets recorded and uploaded and you can watch the recording. So there’s nobody prompting them, but they’ve been recruited because they’re capable of thinking aloud without being reminded.
How do you recruit a good pool of user testers?
Whether you do the testing or not is far more important than whether you have the right participants. You actually tend to learn valuable lessons from the wrong participants. So, in the book, I sort of leaned over backwards, saying, “Don’t get hung up on getting people who are exactly like your users.” Because, depending on what your product is or who your uses are, that can be tough.
I recommend that, even if you have people who represent your target audience, you also throw in one person per round who’s not from your target audience because you’ll learn different things from them. One of the maxims I have in the book is “recruit loosely and grade on a curve,” which, basically, means don’t get hung up about recruiting to the point where it’s going to keep you from doing testing.
How many people do you need?
Jakob Nielsen and other people did studies years ago. Nielsen, in particular, came out with an article 20 years ago. It found that, after five people, you reached diminishing returns and started to see the same problems repeating, in most cases. I reduced it to two or three people because, the fact is, you’re far more likely to do it — and keep doing it — if you test two or three people. My recommendation is that you test once a month with three people. Also, get as many people as possible to come and watch the tests together, which you can also do remotely.
What has been the most surprising change you’ve seen in web design since Don’t Make Me Think was first published?
Do the same web design principles you write about in the book apply today?
In the introduction, I quoted Donald Norman, who said, “technology may change rapidly, but people change slowly.” The issues around usability are still issues of cognition and perception. And that hasn't changed very much. We’re still muddling through.