Don't Make Me Think

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

• My definition of usability. 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.

• Krug’s first law of usability - Don’t make me think!

• Krug’s second law of usability - It doesn’t matter how many times I have to click, as long as each click is a mindless, unambiguous choice.

• Krug’s third law of usability - Get rid of half the words on each page, then get rid of half of what’s left.

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

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

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

• If you can’t make something self-evident, you at least need to make it self-explanatory.

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

  • Fact of life #2: We don’t make optimal choices. We satisfice.

  • Fact of life #3: We don’t figure out how things work. We muddle through.

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

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

• Some important things you can do to make sure they see and understand as much of what they need to know—and of what you want them to know—as possible:

  • 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

• If an idea works well enough, other sites imitate it and eventually enough people have seen it in enough places that it needs no explanation.

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

• Innovate when you know you have a better idea, but take advantage of conventions when you don’t.

• If you can make something significantly clearer by making it slightly inconsistent, choose in favor of clarity.

• Pages with a clear visual hierarchy have three traits:

  1. The more important something is, the more prominent it is.

  2. Things that are related logically are related visually.

  3. Things are “nested” visually to show what’s part of what.

• A good visual hierarchy saves us work by preprocessing the page for us, organizing and prioritizing its contents in a way that we can grasp almost instantly.

• Dividing the page into clearly defined areas is important because it allows users to decide quickly which areas of the page to focus on and which areas they can safely ignore.

• Format text to support scanning

  • Use plenty of headings.

  • Keep paragraphs short.

  • Use bulleted lists.

  • Highlight key terms.

• We face choices all the time on the Web and making those choices mindless is one of the most important things you can do to make a site easy to use.

• Happy talk is like small talk—content-free, basically just a way to be sociable. But most Web users don’t have time for small talk; they want to get right to the point. You can—and should—eliminate as much happy talk as possible.

• Your objective should always be to eliminate instructions entirely by making everything self-explanatory, or as close to it as possible. When instructions are absolutely necessary, cut them back to the bare minimum.

• People won’t use your Web site if they can’t find their way around it.

• The unbearable lightness of browsing

  • No sense of scale.

  • No sense of direction.

  • No sense of location.

• When we want to return to something on a Web site, instead of relying on a physical sense of where it is we have to remember where it is in the conceptual hierarchy and retrace our steps. This is one reason why bookmarks—stored personal shortcuts—are so important, and why the Back button is the most used button in Web browsers.

• Home pages is so important. Home pages are—comparatively—fixed places. When you’re in a site, the Home page is like the North Star. Being able to click Home gives you a fresh start.

• 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 overlooked purposes of navigation

  • It tells us what’s here.

  • It tells us how to use the site.

  • It gives us confidence in the people who built it.

• Navigation is one of the best opportunities a site has to create a good impression.

• One of the most crucial items in the persistent navigation is a button or link that takes me to the site’s Home page.

• Having a Home button in sight at all times offers reassurance that no matter how lost I may get, I can always start over, like pressing a Reset button or using a “Get out of Jail Free” card.

• There are four things you need to know about page names:

  1. Every page needs a name.

  2. The name needs to be in the right place.

  3. The name needs to be prominent.

  4. The name needs to match what I clicked.

• Here are a few best practices for implementing Breadcrumbs:

  • Put them at the top.

  • Use > between levels.

  • Boldface the last item.

• Three reasons why I still love tabs

  1. They’re self-evident.

  2. They’re hard to miss.

  3. They’re slick.

• Web experience is often more like being abducted than following a garden path. When you’re designing pages, it’s tempting to think that people will reach them by starting at the Home page and following the nice, neat paths you’ve laid out. But the reality is that we’re often dropped down in the middle of a site with no idea where we are because we’ve followed a link from a search engine, a social networking site, or email from a friend, and we’ve never seen this site’s navigation scheme before.

• Here’s how you perform the trunk test:

  • Step 1: Choose a page anywhere in the site at random, and print it.

  • Step 2: Hold it at arm’s length or squint so you can’t really study it closely.

  • Step 3: As quickly as possible, try to find and circle each of these items: Site ID Page name Sections (Primary navigation) Local navigation “You are here” indicator(s) Search

  • Try it on your own site and see how well it works. Then ask some friends to try it, too. You may be surprised by the results.

• 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:

  • What is this?

  • What can I do here?

  • What do they have here?

  • Why should I be here - and not somewhere else?

• Compared to the early days of the Web, the Home page has lost its preeminence. Now people are just as likely—or more likely—to enter your site by clicking on a link in an email, a blog, or something from a social network that takes them directly to a page deep in your site. Because of this, every page of your site should do as much as it can to orient them properly: to give them the right idea about who you are, what you do, and what your site has to offer.

• Some attributes to look for when choosing a tagline:

  • Good taglines are clear and informative

  • Good taglines are just long enough, but not too long.

  • Good taglines convey differentiation and a clear benefit.

  • Bad taglines sound generic.

  • Good taglines are personable, lively, and sometimes clever.

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

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

• Several true things about usability testing

  • If you want a great site, you’ve got to test.

  • Testing one user is 100 percent better than testing none.

  • Testing one user early in the project is better than testing 50 near the end.

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

• Testing always works, and even the worst test with the wrong user will show you important things you can do to improve your site.

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

Do-it-yourself usability testing

• Usability testing has been around for a long time, and the basic idea is pretty simple: If you want to know whether something is easy enough to use, watch some people while they try to use it and note where they run into problems.

• How often should you test? — 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.

• Why a morning a month?

  • It keeps it simple so you’ll keep doing it.

  • It gives you what you need.

  • It frees you from deciding when to test.

  • It makes it more likely that people will attend.

• How many users do you need? — I think the ideal number of participants for each round of do-it-yourself testing is three. But they just don’t matter, and here’s why:

  • The purpose of this kind of testing isn’t to prove anything.

  • You don’t need to find all of the problems.

  • You’re going to be doing another round each month. It’s much more important to do more rounds of testing than to wring everything you can out of each round.

• How do you choose the participants? — 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.

  • We’re all beginners under the skin.

  • Experts are rarely insulted by something that is clear enough for beginners.

• Where do you test? — 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.

• Who should do the testing? — The person who sits with the participant and leads them through the test is called the facilitator. Almost anyone can facilitate a usability test; all it really takes is the courage to try it, and with a little practice, most people can get quite good at it.

• Who should observe? — As many people as possible! One of the most valuable things about doing usability testing is the effect it can have on the observers. For many people, it’s a transformative experience that dramatically changes the way they think about users: They suddenly “get it” that users aren’t all like them.

• During the break after each test session, observers need to write down the three most serious usability problems they noticed during that session so they can share them in the debriefing.

• What do you test, and when do you test it? — As any usability professional will tell you, it’s important to start testing as early as possible and to keep testing through the entire development process.

• How do you choose the tasks to test? — The tasks you test in a given round will depend partly on what you have available to test. If all you have is a rough sketch, for instance, the task may consist of simply asking them to look at it and tell you what they think it is. 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.

• What happens during the test? — A typical one-hour test would be broken down something like this:

  • Welcome (4 minutes). You begin by explaining how the test will work so the participant knows what to expect.

  • The questions (2 minutes). Next you ask the participant a few questions about themselves. This helps put them at ease and gives you an idea of how computer-savvy and Web-savvy they are.

  • The Home page tour (3 minutes). Then you open the Home page of the site you’re testing and ask the participant to look around and tell you what they make of it. This will give you an idea of how easy it is to understand your Home page and how much the participant already knows your domain.

  • The tasks (35 minutes). This is the heart of the test: watching the participant try to perform a series of tasks (or in some cases, just one long task). Again, your job is to make sure the participant stays focused on the tasks and keeps thinking aloud. If the participant stops saying what they’re thinking, prompt them by saying—wait for it—“What are you thinking?” (For variety, you can also say things like “What are you looking at?” and “What are you doing now?”) During this part of the test, it’s crucial that you let them work on their own and don’t do or say anything to influence them. Don’t ask them leading questions, and don’t give them any clues or assistance unless they’re hopelessly stuck or extremely frustrated. If they ask for help, just say something like “What would you do if I wasn’t here?”

  • Probing (5 minutes). After the tasks, you can ask the participant questions about anything that happened during the test and any questions that the people in the observation room would like you to ask.

  • Wrapping up (5 minutes). Finally, you thank them for their help, pay them, and show them to the door.

• Typical problems

  • Users are unclear on the concept.

  • The words they’re looking for aren’t there.

  • There’s too much going on.

• The debriefing: Deciding what to fix — After each round of tests, you should make time as soon as possible for the team to share their observations and decide which problems to fix and what you’re going to do to fix them.

  • Make a collective list.

  • Choose the ten most serious problems.

  • Rate them.

  • Create an ordered list.

• Here are some tips about deciding what to fix—and what not to.

  • Keep a separate list of low-hanging fruit.

  • Resist the impulse to add things.

  • Take “new feature” requests with a grain of salt.

  • Ignore “kayak” problems.

• I recommend that you debrief over lunch right after you do the tests, while everything is still fresh in the observers’ minds.

• Focus ruthlessly on fixing the most serious problems first.

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

• 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 and content to create the desktop/full version. It was a great idea. For one thing, Mobile First meant that you would work hard to determine what was really essential, what people needed most. Always a good thing to do.

• As long as the user continues to feel confident that what they want is further down the screen or behind that link or button, they’ll keep going.

• Memorability can be a big factor in whether people adopt an app for regular use. Usually when you purchase one, you’ll be willing to spend some time right away figuring out how to use it. But if you have to invest the same effort the next time, it’s unlikely to feel like a satisfying experience. 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.

• The reservoir is limited, and if you treat users badly enough and exhaust it there’s a good chance that they’ll leave. But leaving isn’t the only possible negative outcome; they may not be as eager to use your site in the future, or they may think less of your organization and savage you on Facebook or Twitter. For those of you in marketing, your NPS (Net Promoter Score) probably goes down.

• There are a few things worth noting about this reservoir:

  • It’s idiosyncratic.

  • It’s situational.

  • You can refill it.

  • Sometimes a single mistake can empty it.

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

  • Punishing me for not doing things your way.

  • Asking me for information you don’t really need.

  • Shucking and jiving me.

  • Putting sizzle in my way.

  • Your site looks amateurish.

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

• Things that increase goodwill

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

  • Tell me what I want to know.

  • Save me steps wherever you can.

  • Put effort into it.

  • Know what questions I’m likely to have, and answer them.

  • Provide me with creature comforts like printer-friendly pages.

  • Make it easy to recover from errors.

  • When in doubt, apologize.

• Making sites more usable for “the rest of us” is one of the most effective ways to make them more effective for people with disabilities.

• The nuts-and-bolts details of almost every accessibility technique.

  • Use headings correctly.

  • Make your forms work with screen readers.

  • Put a “Skip to Main Content” link at the beginning of each page.

  • Make all content accessible by keyboard.

  • Create significant contrast between your text and background.

  • Use an accessible template.