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