Chapter 2. Understand Users, Then Ignore Them

Chapter 2. Understand Users, Then Ignore Them

  • Understand How Users Think They Do Things

  • Understand How Users Actually Do Things

  • Know How to Uncover Reality

  • Design for the Activity

  • Write Use Cases

Whether or not you want to believe it, the vast majority of software projects fail. They fail to live up to customers' expectations, fail to sufficiently support the activities they were conceived to make easier, and fail to gain the ever-elusive customer loyalty earned by companies like Apple, Google, and Amazon.

Many factors can be blamed for the ultimate failure of a product, but they tend to fall into the same few camps of thought. Sometimes a product fails because it doesn't stand up against the competition. Sometimes it's because the market isn't ready for your product. And sometimes it's because users just don't get what you were trying to do.

Of course, none of these complaints are the real reason. Sometimes the failure of a product doesn't seem to make any sense at all. Sometimes your product has all the same features as the other guy's productand then someand it still fails to capture the market the way its competitors have. Sometimes users understand completely what the tool is supposed to do but choose another one anyway. You ask yourself over and over, Why? Why can't my product do every bit as well as my competitor's?

There is no single answer. But some of them go like this:

  • Typically, users latch on to the first Web site or tool they find that they can tolerate, and they stick to it. Most of the time users spend on the Web isn't devoted to visiting new sites and discovering new things. Rather, users go to the same sites over and over. And you haven't given them a good enough reason to switch.

  • Your product isn't better than the competition's just because you crammed more features into it (more about this in Chapter 3). Your long list of features may make for good marketing material, but it also adds up to complicated software that confuses and frustrates users. Most users never become experts who benefit from the more advanced features. The majority of users, in fact, become intermediate-level users quickly, and stay at that level as long as they use the product. I'll discuss this point further in Chapter 5.

  • The difficulty of accomplishing tasks in your application means that users don't stick around to fight their way through it, and they don't bother coming back.

Whatever the reason (and there are plenty more to go around), the most important point is that you need to knowat the very beginning of your projectwhat to build, and why. With that knowledge, you can overcome potential causes for failure and build an application that serves its users effectively. To start, you need to know a few things about how people really work with the Web. Much of this chapter is about how to find out how people really work so you can design things that work for them. Later, however, we'll talk about the benefits of largely ignoring users and focusing your design efforts on supporting a specific activity.

Understand How Users Think They Do Things

A few weeks ago, I heard an interesting story that did a nice job of revealing the differences between how people think they act and how they actually act. The story was about a new sandwich from a fast-food restaurant.

See, the marketers did lots of research before releasing the idea upon the public. They asked a bunch of people if they would find appealing the idea of ordering a low-carb version of their hottest-selling cheeseburger. Resound-ingly, people said they would, indeed, love to take their usual trip to the establishment and order something they know is good for them and their families. The marketers knew they were on to something. So they whipped up a plan, sent the recipe-makers into action, and released the sandwich, sure that their hours of hard work would pay off and earn the company big dividends.

Reality kicked in a short while later. The sandwich failed miserably and quickly disappeared from the menu.

Why, you ask?

People often don't do what they think they would do. They don't act the way they think they would act. We can talk for hours about how we would respond in any given situation, but we don't really know what will happen when the hypothetical becomes real. The sandwich failed to live up to its promise because the promise was based on meaningless conversations with people who thought they would do the smart, responsible thing and make the healthy choice.

The marketers, I'm sure, didn't mean to have meaningless conversations. It's more likely that they asked leading questions, such as "Would you choose to eat the healthier version when given the choice?" It's a question designed to make the person who says, "No, I wouldn't" feel like an idiot for doing so. It's a question designed to get a "Yes, I would."

And even if the questions were presented in an unbiased way, you can't just walk up to people on the street and ask them what they would do. No one really knows what he or she would do. History shows us that people don't always make the right choices. They make comfortable choices. They make safe choices. More to the point, they make the choices they know how to make.

It's difficult to predict how we'd make decisions in hypothetical situations. Hardly anyone can do this well. When we intentionally begin making better choices, we usually do so in increments, making small improvements for a short time. At some point we find ourselves in a stressful situation and immediately revert. We fall back on the types of choices we've been making our whole lives. The ones we know how to make.

One kid starts screaming or crying, another starts begging ruthlessly for a kid's meal with the shiny new toy from his new favorite cartoon movie, and the money in hand goes toward whatever will get them to settle down. Forget the healthy sandwich, just give me one kid's meal, please.

When people use computers, it's usually because they need to accomplish something. Your application stands between them and their mission. And while many people who use the Web regularly feel pretty confident with it, we all know someonesomeone closewho can never quite figure out whether or not the one-click purchase they just made on is going to ship to the new house or the old one.

Every time I'm about to make a one-click purchase on Amazon, I make about 20 other superfluous clicks first so I can double-check the address and credit card information Amazon has on file. Of course, if someone from Amazon asked me if I would use the one-click checkout, I'd say yes. I wouldn't admit to the 20 other clicks, because I prefer to believe I can trust the one-click checkout process enough to be sure my order will be shipped to me correctly.

I don't feel comfortable making a one-click purchase on, because I don't trust the one-click settings (which means the design is a little too obvious). But I'd never admit that to an Amazon usability specialist if he asked me outright.

People prefer to think they know how they would act in any given situation. But very few of them chose the low-carb cheeseburger.

You can't ask users outright what they want. You get theoretical answers. You don't get the answers that result from real choices in real situations. You don't get the truth about how people think and work.

Now you know.