Book Read Free

0321702832.pdf

Page 13

by Steve Krug


  And, of course, if you implement the quick fix you can always continue to work on the “perfect” solution, but in the meantime you don’t just stand there: you do something. As General Patton said, “A good plan implemented today is better than a perfect plan implemented tomorrow.”2

  “It’s a core problem. There’s no easy way to fix it.” People seem to believe that solutions to serious problems can’t be simple. I think there’s often some cognitive dissonance involved: “If it was easy to fix, we would have done it a long time ago.”

  You may not be able to fix the root cause of a serious usability problem right away, but there’s almost always something you can do to mitigate its impact on your users, even if the fix amounts to putting lipstick on the proverbial pig. (Or in some cases, another coat of lipstick.)

  “That’s all going to change soon anyway. We can live with it until then.” Often people will try to avoid having to do anything about a problem by pointing out that it’s going to be fixed (or made irrelevant) by an upcoming redesign. Maybe you can live with it in the meantime, but what about your users? And what if the redesign gets delayed—or canceled?

  2 I can’t believe I’m actually quoting General Patton.

  [ 112 ]

  the least you can do

  Don’t wait for a redesign to fix serious problems.3 If it’s a serious problem, you need to deal with it as soon as possible so it doesn’t go on causing people trouble. Yes, if the redesign actually happens, you may have some duplication of effort, but you’re going to keep the initial effort very small anyway.

  “It’s going to end up feeling like a kludge.” Kludge is such an onomatopoetic word 4—it sounds so ugly and unpleasant. And there can be something distasteful about implementing a lot of temporary fixes, patches, and workarounds. But even though a piece of duct tape covering a hole in your pants may not be pretty, it’s still better than a hole.

  “We can’t fix that right now. We don’t have time.” It’s true that you may not have time to implement the perfect solution, but for the most serious problems you always have time to do something. That’s why when you’re going through your team’s list of the top ten problems, you have to start with the worst first and not skip any. These are the WORST

  problems. You either have to make time or find a simple, elegant way to reduce the impact of the problem on your users.

  Here are the two principles for doing as little as possible that I find work best: Tweak, don’t redesign.

  Take something away.

  3 Recently, we renovated our kitchen. For ten years we’d been living with vintage grey Formica countertops (the kind with gold speckles in it) and an area rug covering the gap in the fl ooring where we’d taken out a back hallway to make more room. We now realize in retrospect that we could have spent $1,000 ten years ago on new linoleum and Home Depot countertops and enjoyed a better quality of life (at least in our kitchen) for an entire decade. Of course, we didn’t because we knew we were going to redesign “soon,” so why throw money away?

  4 I don’t know about you, but I’m impressed. I spelled “onomatopoetic” correctly without looking it up.

  [ 113 ]

  chapter 11

  Tweak, don’t redesign

  When you’re trying to figure out

  how to fix usability problems,

  Nine reasons why tweaking is better

  there’s always a temptation to

  than redesigning

  make changes that go beyond the

  1. Tweaks cost less.

  problems you actually observed—

  2. Tweaks require less work.

  to redesign your whole site, your

  Home page, your navigation

  3. Tweaks don’t ruin lives, break up

  system, your whole checkout

  families, and wreck careers.

  or registration system, or your

  4. Small changes can be made sooner.

  whole…anything—even when

  what’s really needed (and what

  5. Small changes are more likely to

  you can afford to do) is some

  actually happen.

  tweaks.

  6. If you make larger changes,

  If you look back on the first page

  you’re more likely to break other

  of this chapter, you’ll notice that

  things that are working fine in the

  I didn’t say your fix should keep

  process.

  people from having the problem.

  7. Most people don’t like change, so a

  I said it should keep people from

  redesign annoys them.

  having the problem you observed.

  8. A redesign means making a lot of

  I said it this way because the

  changes at once, with the attendant

  observed problems so often get

  complexities and risks.

  restated as a larger problem:

  “He had trouble with that menu”

  9. A redesign means involving a lot

  becomes “We need to redesign

  of people in a lot of meetings.

  our menu system.”

  Enough said.

  The idea of a redesign can be very seductive in the abstract: it promises a new lease on life, a chance to start over and do it right this time.

  In some ways making tweaks isn’t as satisfying as redesigning something—in the same way repairing your old car isn’t as satisfying as getting a new one.

  (You don’t get that “new site smell,” for instance.)

  [ 114 ]

  the least you can do

  But tweaks do have a lot of benefits (see box on previous page).

  So what are tweaks, anyway? Let’s see. Hmmm. If only there was some quick way to look up something like that…. Oh, wait:

  A tweak is a slight adjustment or modification, often one that requires a few rounds of trial and error to get it exactly right.

  Usually Web site tweaks involve making something more prominent by changing its size, position, or appearance, changing some wording, or just moving things around.

  Here’s the process, which is also shown in the flowchart on the next page: 1. Try a simple tweak first: the simplest change you can make that you think might solve the observed problem for most people.

  2. If it doesn’t seem to work, try a stronger version of the same tweak. For instance, if you tried making something larger, try making it a little larger. Keep trying until either (a) it feels done or (b) it’s clear that it’s not going to work.

  3. If the first tweak doesn’t work, consider trying another, different tweak before turning to redesign.

  4. Always keep an eye out for unintended consequences. Does it seem like your change has thrown something else out of whack? (As the old saying goes, if it ain’t broke, don’t break it.)

  [ 115 ]

  chapter 11

  [ 116 ]

  the least you can do

  Take something away

  One of the things people are often tempted to do when there’s a usability problem is to add something. If someone didn’t understand the instructions, add more instructions. If someone couldn’t find what they were looking for in the text, add more text. If someone didn’t notice something they needed to, add more color to it, or make it bolder, or make it larger.

  But very often the best way to fix a usability problem is to do just the opposite: take something away. Remove something from the page.

  The real problem very often is that there’s already too much there. Most pages have all kinds of things that the user doesn’t need: too many words, too many irrelevant pictures, too much decoration—too much “noise”—and that’s the reason users aren’t finding what they need.

  If your first impulse is to add something, you should always question it.

  Usually you’re better off taking away some of the things that were distracting the user. />
  As French aviator, adventurer, and author Antoine de Saint-Exupéry said, “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

  [ 117 ]

  chapter 11

  FAQ

  Don’t you need to do a redesign sometimes?

  Redesign? Yes. All-at-once, redone-from-the-ground-up redesign? Maybe.

  For a while periodic redesigns were considered a necessity, just like new car models every year. They didn’t really have to be better than last year’s, just new. But the current trend seems to be away from wholesale redesign and toward phased, continuous redesign. In fact, Jared Spool has gone so far as to say he’s never seen a major redesign that’s worked.

  How do you know if your tweaks worked? Do you retest the same tasks the following month to make sure?

  I used to think retesting your fixes was always necessary. In fact, I used to glibly paraphrase Ronald Reagan: “Tweak, but verify.”

  If you make a major change or a lot of smaller changes as a result of what you saw in testing, you may want to include the same task in the next monthly round of testing.

  But the truth is, not an awful lot of retesting goes on and not a lot is necessary, because you can usually tell just by looking at it that the tweak is an effective one. When you look at the tweaked page, you usually get a pretty clear sense of either “This solves that problem” or “This doesn’t solve that problem.” To coin a phrase, it’s not rocket surgery.

  Usually it will be obvious that the new, improved version is better and fixes the problem. If you’re not entirely certain, though, you have a few options:

  Do a few quick “hallway tests.” Often what you’re trying to verify is along the lines of “People didn’t notice the left-hand navigation. Will they notice it now that we’ve made it more prominent?” Grab almost anybody, give them the scenario for the affected task (or even a simplified version that focuses on the thing that was changed), and ask them to think aloud and do the task.

  [ 118 ]

  the least you can do

  Test it with a remote testing service like Usertesting.com (page 138–139). Submit the URL of the tweaked version and the relevant task and pay for one or two users to try doing it.

  Run an A/B test of the original and tweaked versions. Using something like Google Website Optimizer (available free as part of Google Analytics), you can run a test that sends half of your site visitors to the original page and half to your tweaked version. Then it allows you to see, for instance, whether more people who used the tweaked version actually got to whatever target page you intended them to get to.

  [ 119 ]

  chapter

  chapter3

  12

  The usual

  suspects

  some problems you’re likely to find and how to

  think about fixing them

  [ 120 ]

  Round up the usual suspects.

  — CAPTAIN RENAULT (CLAUDE RAINS),

  IN CASABLANCA

  W hen you do a lot of usability testing, you tend to see the same problems turn up over and over.

  You’d think it would get boring, but somehow it doesn’t. In fact, over time you develop favorites, and they’re a little like old friends. You’re always glad to see them again—like the marine biologists who recognize individual whales returning each year by the patterns and scars on their flukes, or the prisoners who know each others’ jokes so well they tell them by number.1

  I thought it might be helpful to talk about two of my personal favorites—which I also happen to think are among the ones that cause the most trouble—and explain how I think about fixing them.

  Say hello for me when you see them. (You will.)

  1 A man goes to prison. Every so often somebody calls out a number, like “42,” and all the other prisoners laugh uproariously. He asks his cellmate what’s going on. “We’ve all heard the same jokes so often that we gave them numbers,” he explains. “If you want to tell a joke, you just call out the number.”

  Eventually the newcomer screws up his courage and calls out “37.” Nobody laughs. “What happened?” he asks. His cellmate shrugs and says, “Some people just can’t tell a joke.”

  [ 121 ]

  chapter 12

  Getting off on the wrong foot

  THE PROBLEM:

  The usability problem that has always fascinated me the most is users getting off on the wrong foot.

  When you watch a usability test, you’re basically watching somebody take a little trip. They figure out where they want to go, they get their bearings, and then they head out. You’re standing by, just watching; you can see their every move—and even hear their thought process—but you can’t help them.

  What amazes me most is how often people get off on the wrong foot. Time and again you’ll see people start off with some misapprehension and head off in all kinds of wrong directions, often without realizing for a long time that they’re in any trouble.

  It’s exactly like what Erik Jonsson describes in his

  wonderful book about how people get lost, Inner

  Navigation (Scribner, 2007).

  On a trip to Cologne in 1948, Jonsson left the train station

  before dawn and headed toward the Rhine. He was sure

  he was heading west, even though he could see the sun

  rising over the river ahead of him. He remained “turned

  around,” thinking that east was west and vice versa, until

  he finally left the city. He spent years afterwards collecting

  stories about how people have gotten lost, trying to figure

  out how it happens.

  [ 122 ]

  the usual suspects

  It turns out that the first steps are crucial: people who start off lost tend to stay lost. If you think you know where you’re going but you really don’t, it’s easy to end up wandering around aimlessly.

  I’ve come to think of it in terms of what I call the Big Bang Theory of Web Usability. Like the real Big Bang, a lot happens in your first few seconds on a new Web page or Web site:

  You take in an overall impression, mostly visual: Does it look professional?

  Polished? Serious? Reliable? An excellent research paper (“Attention Web 2

  Designers: You Have 50 Milliseconds to Make a Good First Impression!” ) makes a convincing argument that this process happens very quickly.

  You parse the page visually, identifying the regions of the page and making assumptions about what’s where.

  You identify the site: What is it? Who publishes it? What kinds of things are here? And so on.

  In other words, you form a number of working assumptions, which may or may not be accurate. You use those first bits of information you acquire (“This is a ____ site”) as a toehold, the Rosetta Stone that you use to help interpret everything you see later. If your assumptions are wrong, you’ll try to force everything you see to fit them, usually creating more misinterpretations that have to be straightened out. The lost get…loster.

  As a Web designer, you’ve got to make sure your site sets users off on the right foot. Do visitors get the big picture: what this is, how it’s organized, what they can find here and what they can do here? And do they get it in a few seconds, with little or no effort?

  2 Gitte Lindgaard, Gary Fernandes, Cathy Dudek and J. Brown, Behaviour & Information Technology , Vol. 25, No. 2, March-April 2006, 115–126.

  [ 123 ]

  chapter 12

  HOW TO THINK ABOUT FIXING IT:

  People get lost on sites for a lot of reasons, but the thing that most often gets them off on the wrong foot is a failure of the Home page to do its job of orienting them. You have to make sure your Home page works.

  And even a good Home page requires constant vigilance.

  The user experience of Home pages, in particular, has a tendency to deteriorate over time as stakeholders insist on adding things. As
a result, most Home pages suffer from the kitchen sink syndrome: just too much stuff. (When I look at most Home pages—overcrowded, no focus, in my face—I feel a little bit like the boy in The Sixth Sense, except that instead of “I see dead people,” the thought going through my head is “I see stakeholders.”)

  You need to check regularly to make sure that your Home page still works, which is why I think it’s always worth doing a Home page tour in every test session. You can never test your Home page too many times. (And besides: it never hurts to have everyone on the team—particularly stakeholders—hear strangers say, “There’s an awful lot here. I’m not sure what all of this stuff is.”) Failure to shout

  THE PROBLEM:

  Designers—especially designers who have ever worked in print—love subtle visual distinctions. In print, for instance, you can use a hairline rule to indicate one kind of heading and a half-point rule to indicate another, and people may actually notice the difference. (More important, judges in design competitions will notice the difference.) And things like hairline rules and tiny, low-contrast type are hallmarks of sophisticated design.

  Unfortunately, people using the Web are moving so fast—and screen resolution is so low compared to print—that they almost always miss subtle visual distinctions. Web users rarely “get” subtle visual cues.

  [ 124 ]

  the usual suspects

  HOW TO THINK ABOUT FIXING IT:

  If it’s important that people notice something

  on your site, you need to make it stand out

  more than you probably think you do—and

  almost certainly more than your visual

  designer would like.

  What you and your designer need to

  understand is that this doesn’t mean it

  has to be ugly.

  For instance, on the page on the right, what

  do you think are the two things Amazon

  has decided their visitors absolutely need

  to notice?

  I’m guessing you knew it was the two

  yellow buttons. I’m guessing it because

  I’ve shown this page many times in

  my slides and people usually have no

  trouble spotting the buttons from 50 or

 

‹ Prev