robert hoekman, jr. / blog
Note: This is the old blog for rhjr.net. The new one is here.
Trading users for activities
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.
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.
Understand users, then ignore them
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.
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.
The death of online ads
Jared Spool is talking about the potential death of online ads.
Nothing shocking here - we all know online ads are useless. I've often said, "The best marketing you can have is a great application." But it turns out that the hard research is proving it. Proving that word of mouth is the best form of advertising.
This quote from the article explains how to get people talking:
"And what would make me go on-and-on about my TiVo? Not a great ad. Not a celebrity endorsement. But a great experience."
That's where good design comes in. Good design = happy customers. Happy customers = chatty, happy customers.
Nothing shocking here - we all know online ads are useless. I've often said, "The best marketing you can have is a great application." But it turns out that the hard research is proving it. Proving that word of mouth is the best form of advertising.
This quote from the article explains how to get people talking:
"And what would make me go on-and-on about my TiVo? Not a great ad. Not a celebrity endorsement. But a great experience."
That's where good design comes in. Good design = happy customers. Happy customers = chatty, happy customers.
My podcast interview with Lynda (dot com) now available
My podcast with Lynda Weinman, for FlashForward 2006 in Austin, is now available over on the FlashForward blog. Check it out!
Free expert review still up for grabs
UPDATED: I have a winner! Thanks to everyone who contacted me. Once I'm ready to start doing onseheet reviews regularly, please contact me again and we'll talk about going forward.
Need a free expert review?
Starting ... now, I'm offering one absolutely free expert review of one task or screen in your web application to one individual or company willing to let me use the review as an example for my new service, onesheet.
In conjunction with the release of my new book, Designing the Obvious, I'm redesigning my site and starting a couple of new services, one of which is called onesheet, a service in which I'll deliver a onesheet review (which, ironically, is a two-page PDF) of one page or task flow in a web application, in one week, for $1,000. To create the page about this service on my site, however, I need a good sample, so I'm offering one review free of charge.
Note that this is not simply a matter of being the first person to take me up on the offer. I need a sample that will reflect well on the client and myself (I want you to look good, too, you know), so I'll be hand-picking the lucky winner. In other words, send me something that you think is already good, but could use improvement.
Contact me here to tell me what you want me to review!
In conjunction with the release of my new book, Designing the Obvious, I'm redesigning my site and starting a couple of new services, one of which is called onesheet, a service in which I'll deliver a onesheet review (which, ironically, is a two-page PDF) of one page or task flow in a web application, in one week, for $1,000. To create the page about this service on my site, however, I need a good sample, so I'm offering one review free of charge.
Note that this is not simply a matter of being the first person to take me up on the offer. I need a sample that will reflect well on the client and myself (I want you to look good, too, you know), so I'll be hand-picking the lucky winner. In other words, send me something that you think is already good, but could use improvement.
Contact me here to tell me what you want me to review!
Falling out of the LendingTree
I went to AutoTrader.com to see about a car loan (AutoTrader gets multiple lenders to compete against each other).
Filled out the entire application. Social Security number, phone, address, name, mother's maiden name, amount of loan, and on and on and on.
When I finished the incredibly long form, I was greeted by this message:
"LendingTree cannot accept auto loan requests for Arizona."
I told them I was in Arizona in the first of the two application screens. At the very least, they could have stopped me there. At best, they could have mentioned this little tidbit before I even started the process.
Filled out the entire application. Social Security number, phone, address, name, mother's maiden name, amount of loan, and on and on and on.
When I finished the incredibly long form, I was greeted by this message:
"LendingTree cannot accept auto loan requests for Arizona."
I told them I was in Arizona in the first of the two application screens. At the very least, they could have stopped me there. At best, they could have mentioned this little tidbit before I even started the process.
Celebrating Flash at the Adobe party
The Flash 10-year Anniversary party on Wednesday evening at the Adobe offices in San Francisco (the former Macromedia offices) was absolutely fantastic.
First, it was a great chance for my wife and I to hang out with the usual suspects (Scott Fegette, Mike Downey, Robert Reinhardt, Jen Dehaan, etc) and meet a few people I previously only knew by email (Erica Norton, George Fox, Mike Chambers, and many others).
Second, it was the only time I've ever ordered a drink called a "Flashtini" (a drink made cold by pouring it through an ice sculpture with the Flash logo projected onto it).
But most of all, it was an honor to be invited. I've worked with the Flash team on many occasions, during betas and while writing articles and working on books, and suffered through many long nights right along with them as they prepared another great release of the software that changed the web. And on Wednesday, we all gathered together to goof off, chat with old friends and new faces, and drink some Flashtinis.
Mike Downey posted photos from the event over at Flickr, so you can see the ice sculpture and all the happy Flash geeks.
Here's one of me and my wife, Christine. And one of me being interviewed for some sort of press video by Magent Media. Nothing like a little beer before an interview to loosen you up (that's mine there on the table next to Christine).
Later on, everyone gathered at Mars, the bar down the street, and drank for a few more hours. I'm surprised a few of those people made it to work the next day. (I know at least one who had a serious hangover, but I won't mention any names.)
The next day, Scott Fegette was kind enough to give us the grand tour of the Adobe offices and introduce us to even more people I'd only known by email (like Michael Williams, who I worked with on the Flash Player Detection Best Practices article).
Thanks very much to Adobe for a great party, and a great product. Congratulations on the 10-year anniversary of Flash!
Read "Designing the Obvious" online
Hooray!
My new book, Designing the Obvious: A Common Sense Approach to Web Application Design, is now available as a Rough Cut (unfinished, evolving version of the book) through Safari Books Online. Get yourself a copy now and read the first four chapters and chapters 6 and 7 as a PDF or in your browser (chapters 5, 8, and 9 are not ready for prime-time yet).
Designing the Obvious, if you don't already know, discusses the qualities that make great web-based applications and how to design them.
(The print version of the book should be available in October.)
My new book, Designing the Obvious: A Common Sense Approach to Web Application Design, is now available as a Rough Cut (unfinished, evolving version of the book) through Safari Books Online. Get yourself a copy now and read the first four chapters and chapters 6 and 7 as a PDF or in your browser (chapters 5, 8, and 9 are not ready for prime-time yet).
Designing the Obvious, if you don't already know, discusses the qualities that make great web-based applications and how to design them.
(The print version of the book should be available in October.)
RSS feed