Boxes And Arrows : The Design Behind the Design

Article Idea:

Personas: Why We Get them 99% Wrong

suggested by Andrew Hinton on 2007/04/20

Using personas has become a sort of holy writ best practice among UX practitioners. Many designers tend to use them now as a matter of course. But in my experience, they often just end up being nicely written documents that are occasionally referred to for specific attributes of the user base—something that could be done more efficiently with a spreadsheet of user-profile specifications. More often than not, I hear people say they just don’t see the value in them, or they find them corny.

Last year, some things finally clicked for me about Personas. And the more I mull them over, the more I realize that what most of us call Persona Design has little in common with the origin of this approach.

The one article that really nailed it for me was Alan Cooper’s column on “The Origin of Personas”—http://www.cooper.com/insights/journal_of_design/articles…

I won’t quote it at length here (though I do on my blog post [http://www.inkblurt.com/archives/484] which got me thinking about this story idea), but Cooper describes how he had to go walking on a beach while his (no primitive) system was busy crunching numbers, and it was there where he started talking to himself, embodying a particularly representative user he’d met during interviews.

And then I compared that very intuitive, human, empathetic activity to what most of us call Persona Design, and wondered about the following:

1. Persona design didn’t start as a ‘method’ or especially not a ‘methodology!’ It was the intuition of an empathetic software creator, someone with a personality and mental frame capable of putting himself as much as possible not only in the ’shoes’ but in the voice, body and life of his user.

2. Persona design was this activity of enlightened empathetic roleplay, not a deliverable or procedure to produce it. This explains to me why, in so many situations, I’ve seen personas created and wondered what use they were. The answer: they’re useless on the page, unless the page is used to help tell the story.

3. Personas didn’t start as collaborative artifacts, but that’s how we almost exclusively think of them in UX circles. Cooper was working essentially alone on this: he wasn’t using his persona to explain things to an executive stakeholder — he was just designing, in the present.

4. Cooper was doing this in his ’spare time’ while things were rendering, away from the system, away from the cubicle. I wonder if this would’ve happened if he’d had a more responsive system, like we typically do today? And yet, I’ve *never* seen in any description of a Persona method a direction to get away from the cubicle or meeting room, and breathe fresh air, and talk to yourself!!!

5. His persona was based on a real person, not a mashup of users. Typically, we make personas that cram a number of different characteristics into one person. But I think this approach may lead us astray at times — not that we have to use only a single actual person for a persona, but maybe we should *start* there, before creating a frankensteined non-existent user from the cherrypicked parts of the ones we’ve observed?

Essentially, personas aren’t a method that you follow step by step and end up, automagically, with a reference-facsimile of your user. It’s really an emotional, almost theatrical leap that takes imagination and deliberate, focused empathy. It can be done with no documentation whatsoever!

What happened then? I think Cooper just articulated his experience in a context that’s very metrics and documentation driven. Engineering and software development aren’t very touchy-feely cultures. They take things and codify, categorize and systematize them. It’s necessary in order to take something so tacit and make it explicit, teachable and repeatable. But I wonder if, to steal from Shelley, we “murder to dissect?”

It makes me wonder if, as designers, we should have some kind of method acting seminar, to get us out of our geeky skins?