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.