Designing the Obvious: A Common Sense Approach to Web Application Design

There's one last thing you should understand about people before you run off to create surveys and plan contextual inquiries. And it's the fact that really changes things. It's the fact that makes it possible to design the obvious.

You ready?

People adapt to technology.

I knowit's surprising. But think about your average day. You wake up to a digital alarm clock, use the remote control to turn on the television, hit the start button on the coffeemaker, push another little button to open the garage door, get in your car and fidget with the stereo while hooking your Apple iPod up to it, and drive to work glancing at the speedometer, gas gauge, and iPod controls the whole time. Then you get to work and log in to your computer, where you crank out email, code, Web pages, whatever, until it's time to go home. Once there, you set the DVR to record your favorite show while you make dinner on a stove full of timers and heat settings, simultaneously answering your cell phone so your spouse can tell you he or she is running late.

You've adapted nicely to all these things. You may have had to read a manual or two along the way, but you figured them out at some point, got them up and running, and now you don't even have to think about how these things work. What this tells us is that it's possible to design things that support the needs of your users without knowing anything about their goals and dreams and ambitions and other things movies are made of.

Cars, alarm clocks, stereos, stove-tops, and millions of other devices have been developed almost entirely without the aid of Goal-Directed Design. This is because there are plenty of designers in the world who believe it's possible to design great products without researching users. For this, I commend them. Goal-Directed Design isn't for everyone.

Sure, personas have their upsides, like the fact that having a strong understanding of your target users can help you see more easily what features and functionality might really help them. But thorough user research is time-consuming; I've personally never worked on a project with a long enough time line that user research could be done at all. Most projects are quick, dirty, and painful. Entire Web-based email applications are often designed and built in six weeks instead of six months, and believe me, six weeks is not enough time to learn anything about your users. You're usually far too busy cranking out wireframes.

It's nice when you have the option of getting up close and personal with users, but usually you don't. Time constraints, budgets, lack of interest, and many other factors get in the way almost every single time. And even if it is an option, listening to your loudest users too much often results, ironically, in products that are more difficult for everyone else to use.

To remedy this, we need to trust ourselves to design good Web applications without listening too closely to our users. And renowned user-experience master Donald Norman has just the solution. It's called Activity-Centered Design.

Norman's article "Human-Centered Design Considered Harmful" (http://www.jnd.org/dn.mss/human-centered.html) points out that many technologies and products have become great not as a result of a deep understanding of users, but rather because of a "deep understanding of the activities that were to be performed." He cites everything from clocks to musical instruments as examples of products designed only through an understanding of the activities they were meant to support. He states the following:

His insight is both fascinating and true. Many Web applications have been designed to accommodate niche markets with specific needs, and while many of them are quite successful in their respective markets, Web applications are often, in fact, more successful when they are driven by an authoritative, take-charge designer who almost completely ignores users. And this phenomenon extends well beyond the Web world. Apple's iPod, the most widely adopted portable music player in the world, was designed without a thorough understanding of its users. It was designed to support the activity of listening to music on the go. In the same article Norman states the following:

Granted, not everyone has the vision and design chops of Apple's fearless leader, Steve Jobs, but regardless, understanding the activity itself can lead to creating products that support not only a niche audience, but also the public at large.

37signals, the small company with the giant buzz responsible for products like Basecamp and Backpack, is another great example of this. In the case of Base-camp, they saw that project management software was largely about organization and structure and planning, and decided instead to build a project management system that focuses on communication through the use of collaborative tools like a message board, file manager, to-do-list, and a dashboard view of recent activity. They felt that charts and graphs didn't really speak to those involved in a project, and users might be better empowered by being allowed to communicate their actual thoughts with other team members via the Web.

If you're familiar with Basecamp, you probably know they were right. Even if you don't like it or use it, many thousands of people are using Basecamp because it supports the activity of management, not the concept of management. The boys at 37signals didn't have the time to research users at great lengths (they actually didn't need to, because they originally built Basecamp for themselves)they had projects to manage and built something that effectively supported that activity. By doing so, they satisfied their own needs as a business and have made countless others more productive as a result. They designed around an activity and enabled thousands of potentially very different user types to work within the parameters of the activity.

Basecamp steers away from charts and graphs in favor of communication in plain English.

Norman's article doesn't offer much insight about how to gain such a rich understanding of an individual activity, but it does illustrate very well that one does not need a through knowledge of users to design products that work for them.

It's easy to see how the same conclusion can be drawn from understanding the activity of searching for and purchasing stock photography online, the example in my discussion of Goal-Directed Design. Anyone who has used online stock images knows it's cumbersome at best to troll through the millions of images on any one site, and some creative thinking could very easily have produced the same feature list as that abstracted from the persona about Greg, the print designer with an increasing number of Web projects.

Activity-Centered Design is effective from the beginning, as the team starts with a constructan activitythat the application must support. The team then focuses its efforts on the more practical aspects of design by breaking down the activity into a collection of tasks. Tasks are tangible. You can design ways to complete them without knowing anything about your users. Norman continues (in his second article on Activity-Centered Design, located at http://www.jnd.org/dn.mss/hcd_harmful_a_clari.html):

Task-flow diagrams

Norman advocates the use of task-flow diagrams. So do I.

A task-flow diagram is a flowchart that details how a user will complete all the tasks in an application from beginning to end. Drawing up such a diagram can put you on the path toward an obvious design, because an effective task design is one that makes it obvious how to get from one step to the next in a process, and that process follows an obvious logic.

The diagram below is an example of how a typical shopping experience might go on an e-commerce site. In the diagram, the user wants to buy a desk lamp. To complete the task, the user needs to go to the Products section, drill down into the Desk Lamps category within the Products section, locate a particular desk lamp, add it to the shopping cart, and check out.

Task:Purchase silver desk lamp with clip

The task-flow diagram not only details how the task will be completed in the application, it also can be used as the basis for a prototype later on. And prototypes can be helpful in usability tests to determine how well the design guides users through the process. (I'll talk about prototypes and usability tests in Chapter 4.)