In my post titled "Understand users, then ignore them", I stated that we should ignore users and focus on designing to support a specific activity. I spent a lot of time focusing on why Goal-Directed Design is wasteful, but not enough time explaining what to do instead.

We should practice what Donald Norman calls "Activity-Centered Design". Instead of writing personas and running them through hypothetical scenarios, focus on the activity itself.

In the case of Cooper's Airport Guide, the activity is that of locating various points of interest in an airport and figuring out how to get to each one without a lot of hassle. To do this, any kind of device with a wi-fi or Bluetooth connection would come in very handy. And a simple, 2-screen interface consisting of an index and a mapping system is an obvious solution. The user simply browses locations and clicks through to a map, which provides directions to the location from where the user currently stands.

Cell phones have offered similar solutions for a few years now. Ultimately, all Cooper Labs did was localize the solution to make it specific to an airport.

Cooper spent a lot of time and energy interviewing users, creating personas, writing scenarios, and so on. This effort cost a lot more money than it needed to. Any good designer who focused his or her attention on the activity itself could have come up with the same solution (perhaps even a better one) in far less time, with far fewer resources.

To be clear (and I'm saying this because someone asked), I'm not saying that because I've been in an airport, I know what everyone needs. That would be "self-referential design", and it's not good (unless, of course, you're the primary user).

I'm saying we should focus our design efforts on the acitivites our applications are meant to support. It takes less time and resorces, is less expensive, and results in designs that are every bit as good, if not better, than those that result from expensive user research.

The bonus side-effect is that, since you're not focusing on one audience, you open up the design to work for other audiences. Create something that supports an activity, and you create something that many user types can adapt to and use, regardless of their specific needs or goals.

Chapter 2 in my new book, Designing the Obvious, is titled "Understand Users, Then Ignore Them". Here's why:

Airport Guide, from Cooper Labs, is an example of one of the most common design approaches in the software business: Goal-Directed Design (GDD). Alan Cooper's team of interaction designers interviewed users, noted the "concerns and goals that they have in common", created personas (fictional archetypal users) based on those interviews, wrote scenarios (stories about how the personas will use the design), and then finally got to work on designing an airport guide that allows users to get off of an airplane, whip out a PDA, and get a map of the airport, complete with walking directions to the nearest coffee shop and anything else available.

Great idea. And a ridiculous waste of time.

The primary persona for this project was Angela, a 31-year-old PR consultant who travels regularly. According to the persona - which, again, is the result of interviews and research - Angela's goals are to be on time, travel without hassle, and not feel stupid.

Consider this for a moment. Do you know anyone whose goals are not exactly the same as Angela's while struggling anxiously through the average airport experience? Were the expensive and time-consuming interviews that led to the creation of the almighty Angela persona really necessary? Most people who put five seconds of thought into the subject could have come up with the same list of goals.

The scenarios that were written for Angela include having her locate a coffee shop by looking it up in the index, click through to a map, and follow the walking directions. Another has Angela looking up her gate and following directions to it, arriving with plenty of time to spare.

Again, a waste of time. Any designer worth his/her salt would have come up with the same set of tasks when thinking about the issues the average traveler faces at the airport.

In Designing the Obvious, I state that it's important to have a general understanding of users. This is true because we need to know how people work with software and how they think, so we can better design for and support effective mental models and steamline task flows and interactions. But then I state that we should ignore the demands of our specific audiences. Why do I do this?

Because GDD is a waste of time. And it's expensive. And it puts too much focus on a particular audience when designers would be better off focusing design efforts on the activity the application is meant to support.

First, companies rarely have the time or resources to manage and perform interviews with all the different user types expected to work with an particular application. Most of the time, companies have almost no time at all to dedicate to design work. But it doesn't really matter. If you know how to design the Obvious, you don't need a lot of time.

Second, focusing on one audience means you risk alienating others.

Third, Cooper Labs didn't even use what they discovered in their research. Despite revolving all design efforts around Angela, they didn't do anything that was specific to Angela's problems. They ended up with a design that would work for pretty much anyone with a PDA and Bluetooth. Yes, this is a good thing, but it means Cooper Labs wasted their time focusing on Angela.

For all the time and energy the Cooper team spent interviewing users, creating personas, writing scenarios, etc., they came up with something that any good designer could have come up with on his/her own, in far less time, by focusing on the activity.

Don't design for an audience. Design for an activity.