"Reaction [beta]"
Personas? 13 Nov 2007
A interesting debate is developing over at Signal vs. Noise on the usefulness of personas. 37signals seem to think they are useless:
"We don't use personas. We use ourselves. I believe personas lead to a false sense of understanding at the deepest, most critical levels.
"Every product we build is a product we build for ourselves to solve our own problems. We recognize our problems aren't unique. In fact, our problems are probably a lot like your problems. So we bundle up the solutions to our problems in the form of web-based software and offer them for sale.
"We recognize not everyone shares our problems, our point of view, or our opinions, but that verdict's the same if you use personas. Making decisions based on real opinions trumps making decisions based on imaginary opinions.
"I've never been a big believer in personas. They're artificial, abstract, and fictitious. I don't think you can build a great product for a person that doesn't exist. And I definitely don't think you can build a great product based on a composite sketch of 10 different people all rolled into one (or two or three)."
We have a lot of respect for 37signals, but in this particular case, they're plain wrong. If you create personas based on your own personal opinions and presuppositions about your users, then of course they'll be useless. In this case, they'll represent little more than an attempt to legitimise your own political viewpoint regarding how your design should progress. However, this isn't what real (or good) persona development is about. Good personas are underpinned by user research - that is, they summarise a set of data garnered from observation of real-life end users of the system you are developing.
Here's a comment we left on 37s' site that illustrates this point:
"Here's a quick example of how we used personas on a recent project:
"One of our clients - a rail operator - wanted to allow its customers to purchase train tickets by phone / online and pick them up at the station on the day of travel. To do so, however, required customers to bring along the credit card they had used at the time of booking as proof-of-identity.
"When viewed through our own eyes (as designers / developers / people who travel quite regularly) this all seemed fine...however, upon reviewing our persona docs a problem became immediately obvious.
"The notes we'd made when constructing our 'Personal Assistant' persona revealed that PAs often booked travel on behalf of the company executives they assisted, and did so using their own credit cards. Thus, had the process described above been implemented as specified, we'd have seen lots of company execs turning up at train stations without a means of collecting their tickets (as they wouldn't have had their PA's credit card with them on the day of travel).
"Now, perhaps we should have been able to anticipate this problem without need for persona docs...but for one reason or another we didn't. Most likely because we aren't PAs ourselves and we don't employ any PAs at our company. In these circumstances, our PA persona provided a useful 'PA-by-proxy';, enabling us to validate our designs more thoroughly than we otherwise would have done - and reminding us to ensure that this users group's needs were being met as the project progressed.
"(Our 'Personal Assistant' persona wasn't made up btw - we job-shadowed ten real-life PAs in order to construct it...which is why it proved so useful later on in the project)."
Next article: reCAPTCHA comingATCHA
Previous article: The accessibility cookbook: A recipe for disaster
Bookmark this page
Trackbacks
To create a TrackBack to this entry simply append ping/ to the permalink URL for this page.
