Two colleagues in the last week or so have posted in their blogs about persona-based design.

Austin Govella gives us a nice set of links about Personas, and Antonella Pavese touches on some counterintuitive truths about personas after reading Jason Fried’s Getting Real in her post Get Real: How to design for the life of others.

Antonella in particular mentions that one way to ‘get real’ about design is to realize you can’t design for anyone but yourself. That is, you can’t read a bunch of facts and figures about your users and somehow methodically design for them; that it takes a kind of roleplaying, and how that was Alan Cooper’s approach when he initially articulated a persona-based approach.

I only recently realized how powerful persona design can really be, and even more recently realized why.

When most people talk about “personas” they’re really talking about deliverables: documents that describe particular individuals who act as stand-ins or ‘archetypes’ for other users.

The truth, however, is that personas aren’t the documents, or the method, or any of that. Personas are people! But they’re people a designer needs to “get” in a visceral, intuitive way.

I was actually fairly confused about what personas should be, how they were different from marketing segments or “user profiles,” until I read Alan Cooper’s own column about “The Origin of Personas.”

A few paragraphs of it are so important that I think they deserve quoting in full:

I was writing a critical-path project management program that I called “Plan*It.” Early in the project, I interviewed about seven or eight colleagues and acquaintances who were likely candidates to use a project management program. In particular, I spoke at length with a woman named Kathy who worked at Carlick Advertising. Kathy’s job was called “traffic,” and it was her responsibility to assure that projects were staffed and staffers fully utilized. It seemed a classic project management task. Kathy was the basis for my first, primitive, persona.

In 1983, compared to what we use today, computers were very small, slow, and weak. It was normal for a large program the size of Plan*It to take an hour or more just to compile in its entirety. I usually performed a full compilation at least once a day around lunchtime. At the time I lived in Monterey California, near the classically beautiful Old Del Monte golf course. After eating, while my computer chugged away compiling the source code, I would walk the golf course. From my home near the ninth hole, I could traverse almost the entire course without attracting much attention from the clubhouse. During those walks I designed my program.

As I walked, I would engage myself in a dialogue, play-acting a project manager, loosely based on Kathy, requesting functions and behavior from my program. I often found myself deep in those dialogues, speaking aloud, and gesturing with my arms. Some of the golfers were taken aback by my unexpected presence and unusual behavior, but that didn’t bother me because I found that this play-acting technique was remarkably effective for cutting through complex design questions of functionality and interaction, allowing me to clearly see what was necessary and unnecessary and, more importantly, to differentiate between what was used frequently and what was needed only infrequently.

There are several very important insights I had from reading this:

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 makes me wonder if, as designers, we should have some kind of method acting seminar, to get us out of our geeky skins?