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

by Krug Steve

the user thinks “What do they have here?” The major sections in the website are listed at the bottom right and the user thinks “Why should I be here—and not somewhere else?”

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.

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. Mottoes are lofty and reassuring, but if I don’t know what the thing is, a motto isn’t going to tell me.

Good taglines are personable, lively, and sometimes clever. Clever is good, but only if the cleverness helps convey—not obscure—the benefit.

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.

On sites that are built around a step-by-step process (applying for a mortgage, for instance), the entry point for the process should leap out at me. And on sites where I have to register if I’m a new user or sign in if I’m a returning user, the places where I register or sign in should be prominent. Unfortunately, the need to promote everything (or at least everything that supports this week’s business model) sometimes obscures these entry points. It can be hard to find them when the page is full of promos yelling “Start here!” and “No, click me first!” The best way to keep this from happening is to make the entry points look like entry points (i.e., make the search box look like a search box and the list of sections look like a list of sections). It also helps to label them clearly, with labels like “Search,” “Browse by Category,” “Sign in,” and “Start here” (for a step-by-step process).

The worst of these behaviors, of course, is the tendency to try to promote everything. The problem with promoting things on the Home page is that it works too well. Anything with a prominent Home page link is virtually guaranteed to get more traffic—usually a great deal more—leading all of the site’s stakeholders to think, “Why don’t I have one?”

The section that’s being promoted gets a huge gain in traffic, while the overall loss in effectiveness of the Home page as it gets more cluttered is shared by all sections.

Preserving the Home page from promotional overload requires constant vigilance, since it usually happens gradually, with the slow, inexorable addition of just...one...more...thing.

the stakeholders need to be educated about the danger of overgrazing the Home page and offered other methods of driving traffic, like cross-promoting from other popular pages or taking turns using the same space on the Home page.

ALL WEB USERS ARE UNIQUE AND ALL WEB USE IS BASICALLY IDIOSYNCRATIC

The problem is there are no simple “right” answers for most Web design questions (at least not for the important ones). What works is good, integrated design that fills a need—carefully thought out, well executed, and tested.

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.

they might discover that it doesn’t make much difference whether you go with cascading menus or mega menus if nobody understands the value proposition of your site.

I’ve often had to work very hard to make clients understand that what they need is usability testing, not focus groups

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.

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

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.

you want a great site, you’ve got to test. After you’ve worked on a site for even a few weeks, you can’t see it freshly anymore. You know too much. The only way to find out if it really works is to watch other people try to use it.

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

ask for a volunteer to try to perform a task on a site belonging to one of the other attendees. These tests last less than fifteen minutes, but in that time the person whose site is being tested usually scribbles several pages of notes. And they always ask if they can have the recording of the test to show to their team back home. (One person told me that after his team saw the recording, they made one change to their site which they later calculated had resulted in $100,000 in savings.)

Testing one user early in the project is better than testing 50 near the end. Most people assume that testing needs to be a big deal. But if you make it into a big deal, you won’t do it early enough or often enough to get the most out of it. A simple test early—while you still have time to use what you learn from it—is almost always more valuable than an elaborate test later.

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

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. And if you’re just starting to do testing, your site probably has a number of usability flaws that will cause real problems for almost anyone you recruit.

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: It’s usually not a good idea to design a site so that only your target audience can use it. Domain knowledge is a tricky thing, and if you design a site for money managers using terminology that you think all money managers will understand, what you’ll discover is that a small but not insignificant number of them won’t know what you’re talking about. And in most cases, you need to be supporting novices as well as experts anyway. We’re all beginners under the skin. Scratch an expert and you’ll often find someone who’s muddling through—just at a higher level. Experts are rarely insulted by something that is clear enough for beginners. Everybody appreciates clarity. (True clarity, that is, and not just something that’s been “dumbed down.”) If “almost anybody” can use it, your experts will be able to use it, too.

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. 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. Who should observe? As many people as possible!

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.

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 book you want to buy, or a book you bought recently” than “Find a cookbook for under $14.” It increases their emotional investment and allows them to use more of their personal knowledge of the content.

You probably already have a good idea of why we’ve asked you to come here today, but let me go over it again briefly. We’re testing a Web site that we’re working on so we can see what it’s like for people to use it. The session should take about an hour. I want to make it clear right away that we’re testing the site, not you. You can’t do anything wrong here. In fact, this is probably the one place today where you don’t have to worry about making mistakes. We want to hear exactly what you think, so please don’t worry that you’re going to hurt our feelings. We want to improve it, so we need to know honestly what you think. As we go along, I’m going to ask you to think out loud, to tell me what’s going through your mind. This will help us. I’m reading from the script that I use when I do usability tests. You can download this script at rocketsurgerymadeeasy.com. If you have questions, just ask. I may not be able to answer them right away, since we’re interested in how people do when they don’t have someone sitting next to them to help, but I will try to answer any questions you still have when we’re done. And if you need to take a break at any point, just let me know. It’s important to mention this, because it will seem rude not to answer their questions as you go along. You have to make it clear before you start that (a) it’s nothing personal and (b) you’ll try to answer them at the end if they still want to know. You may have noticed the microphone. With your permission, w...

There’s a well-established meme that suggests that rather than being the negative force that they often feel like, constraints actually make design easier and foster innovation.

Having something pinned down can have a focusing effect, where a blank canvas with its unlimited options—while it sounds liberating—can have a paralyzing effect.

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

Most of the challenges in creating good mobile usability boil down to making good tradeoffs.

If there are two things I can tell you about scalable design (a/k/a dynamic layout, fluid design, adaptive design, and responsive design), they’re these: It tends to be a lot of work. It’s very hard to do it well.

Affordances are the meat and potatoes of a visual user interface. For instance, the three-dimensional style of some buttons makes it clear they’re meant to be clicked. The same as with the scent of information for links, the clearer the visual cues, the more unambiguous the signal.

affordances are the last thing you should hide.

useful, learnable, memorable, effective, efficient, desirable, and delightful. Well, that time has arrived. 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

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.

one reason it’s so much fun to use is that they’ve come up with innovative interactions, gestures, and navigation, but there’s a lot to learn.

Unless you’re very impressed by what it does, there’s a good chance you’ll abandon it—which is the fate of most apps. Life is cheap (99 cents) on mobile devices.

mirroring isn’t a good way to watch tests done on touch screen devices, because you can’t see the gestures and taps the participant is making. Watching a test without seeing the participant’s fingers is a little like watching a player piano: It moves very fast and can be hard to follow. Seeing the hand and the screen is much more engaging.

Out of curiosity, I built myself a camera rig by merging a clip from a book light with a Webcam. It weighs almost nothing and captures the audio with its built-in microphone. Mine cost about $30 in parts and took about an hour to make. I’m sure somebody will manufacture something similar—only much better—before long.

Photograph of Macally web camera is shown with online information displayed as follows: “Macally ICECAM2 USB 2.0 Video Web Camera with Built-in Microphone (White) By Macally (Five stars with 3.5 shaded) 209 customer reviews List Price: $29.99 (striked out) Price: $16.59 You Save: $13.40 (45%) Only 14 left in stock Ships from and sold by Amazon.com” Plus Photograph of reading light is shown with online information displayed as follows: “Lightwedge Flex Neck Reading Light, Soft Touch Black By Lightwedge (Five stars with 3.5 shaded) 250 customer reviews Price: $15.03 Only 1 left in stock. Sold by DMK Retail and Fulfilled by Amazon” Equals Photograph of Brundleyfly camera. “Lightweight webcam plus Lightweight clamp and Gooseneck equal Brundlefly” is labeled at bottom.

They’re heavy and awkward. It weighs almost nothing and barely changes the way the phone feels in your hand. They’re distracting. It’s very small (smaller than it looks in the photo) and is positioned out of the participant’s line of sight, which is focused on the phone. Nobody wants to attach anything to their phone. Sleds are usually attached to phones with Velcro or double-sided tape. This uses a padded clamp that can’t scratch or mar anything but still grips the device firmly. One limitation of this kind of solution is that it is tethered: It requires a USB extension cable running from the camera to your laptop. But you can buy a long extension inexpensively. The rest of the setup is very straightforward: Connect the Brundlefly to the facilitator’s laptop via USB. Open something like AmCap (on a PC) or QuickTime Player (on a Mac) to display the view from the Brundlefly. The facilitator will watch this view. Share the laptop screen with the observers using screen sharing (GoToMeeting, WebEx, etc.) Run a screen recorder (e.g., Camtasia) on the computer in the observation room. This reduces the burden on the facilitator’s laptop.

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.

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