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

by Krug Steve

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. You have to use the collective skill, experience, creativity, and common sense of the team to build some version of the thing (even a crude version), then watch some people carefully as they try to figure out what it is and how to use it. There’s no substitute for it.

In a 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 tests 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 learning about whether your site works and how to improve it.

Testing reminds you that not everyone thinks the way you do, knows what you know, and uses the Web the way you do.

It gives you what you need. Watching three participants, you’ll identify enough problems to keep you busy fixing things for the next month. It frees you from deciding when to test.

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. And three users are very likely to encounter many of the most significant problems related to the tasks that you’re testing.

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

FOCUS RUTHLESSLY ON FIXING THE MOST SERIOUS PROBLEMS FIRST

Take “new feature” requests with a grain of salt. Participants will often say, “I’d like it better if it could do x.” It pays to be suspicious of these requests for new features.

To paraphrase Lincoln, the best you can do is please some of the people some of the time.

One way to deal with a smaller living space is to leave things out: Create a mobile site that is a subset of the full site. Which, of course, raises a tricky question: Which parts do you leave out? One approach was Mobile First. Instead of designing a full-featured (and perhaps bloated) version of your Web site first and then paring it down to create the mobile version, you design the mobile version first based on the features and content that are most important to your users. Then you add on more features

MANAGING REAL ESTATE CHALLENGES SHOULDN’T BE DONE AT THE COST OF USABILITY3

Allow zooming. If you don’t have the resources to “mobilize” your site at all and you’re not using responsive design, you should at least make sure that your site doesn’t resist efforts to view it on a mobile device.

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

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

Just doing something well isn’t good enough to create a hit; you have to do something incredibly well. Delight is sort of like the extra credit assignment of user experience design. 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.

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?

I’ve always found it useful to imagine that every time we enter a Web site, we start out with a reservoir of goodwill. Each problem we encounter on the site lowers the level of that reservoir.

Things that diminish goodwill Here are a few of the things that tend to make users feel like the people publishing a site don’t have their best interests at heart: Hiding information that I want. The most common things to hide are customer support phone numbers, shipping rates, and prices. The whole point of hiding support phone numbers is to try to keep users from calling, because each call costs money. The usual effect is to diminish goodwill and ensure that they’ll be even more annoyed when they do find the number and call. On the other hand, if the 800 number is in plain sight—perhaps even on every page—somehow knowing that they can call if they want to is often enough to keep people looking for the information on the site longer, increasing the chances that they’ll solve the problem themselves.

Punishing me for not doing things your way. I should never have to think about formatting data: whether or not to put dashes in my Social Security number, spaces in my credit card number, or parentheses in my phone number. Many sites perversely insist on no spaces in credit card numbers, when the spaces actually make it much easier to type the number correctly. Don’t make me jump through hoops just because you don’t want to write a little bit of code.

Your site looks amateurish. You can lose goodwill if your site looks sloppy, disorganized, or unprofessional, like no effort has gone into making it presentable.

(I tell people to ignore all comments that users make about colors during a user test, unless three out of four people use a word like “puke” to describe the color scheme. Then it’s worth rethinking.2)

Sometimes it makes business sense not to do exactly what the customer wants. For instance, uninvited pop-ups almost always annoy people to some extent. But if your statistics show you can get 10 percent more revenue by using pop-ups and you think it’s worth annoying your users, you can do it. It’s a business decision.

Know the main things that people want to do on your site and make them obvious and easy. It’s

Tell me what I want to know.

Save me steps wherever you can. For instance, instead of giving me the shipping company’s tracking number for my purchase, put a link in my email receipt that opens their site and submits my tracking number when I click it. (As usual, Amazon was the first site to do this for me.)

When in doubt, apologize. Sometimes you can’t help it: You just don’t have the ability or resources to do what the user wants (for instance, your university’s library system requires separate passwords for each of your catalog databases, so you can’t give users the single login they’d like). If you can’t do what they want, at least let them know that you know you’re inconveniencing them.

Add appropriate alt text to every image.

Here are the two suggestions I’ve always heard for convincing management to support (and fund) usability work: Demonstrate ROI. In this approach, you gather and analyze data to prove that a usability change you’ve made resulted in cost savings or additional revenue (“Changing the label on this button increased sales by 0.25%”). There’s an excellent book about it: Cost-justifying Usability: An Update for the Internet Age, edited by Randolph Bias and Deborah Mayhew. Speak their language. Instead of talking about the benefits for users, learn what the current vexing corporate problems are and describe your efforts in a way that makes it clear that they’re part of the solution: Talk about things like pain points, touch points, KPIs, and CSI, or whatever management buzzwords are trending in your organization.

Do a test of the competition. I mentioned in Chapter 9 that it’s a good idea to test some competitive sites at the start of any project.

Don’t use small, low-contrast type.

Don’t put labels inside form fields.

Don’t float headings between paragraphs. Headings should be closer to the text that follows them than the text that precedes them. (Yes, I know I mentioned this is Chapter 3, but it’s so important it’s worth repeating.) That’s all, folks.