Joshua Porter (formerly of UIE, but now doing great work on his own at Bokardo Design) recently described much of the latest online debate about the need to develop personas when designing. Josh got a lot of things right, but he got one thing very, very wrong. And, unfortunately, he bases a lot of his argument on that one thing.

Josh said this:

Definition, please?

But while all of this arguing is going on, nobody is really defining what personas are. This, of course, is a big part of the problem. What most definitions don’t say is that personas are a document. They might be a poster, a word file, or a PDF. But they are a document that represents an archetypical person that is passed around design teams. Ok, just wanted to make that clear.

Personas are not a document. Persona descriptions can be a document (or a movie or any other practical rendering). But, those are just renderings of what happened during the persona creation process.

Here’s the way to think of it:

Personas are to Persona Descriptions as Vacations are to Souvenir Picture Albums.

While people who didn’t go on the vacation can look through the album and think, “Boy, that must’ve been fun,” they’ll never get the full experience of what the actual vacation experience was. The album is just a remnant.

In the UX community, many folks are now saying, “I’ve looked at these documents and they just don’t do anything for me. I don’t think personas are valuable.” Unfortunately, they are judging the value of creating and using robust personas based on the quality of the paper deliverable. If the vacation pictures aren’t compelling, did the vacation itself suck?

To be fair, I think there could be a lot of improvement in the ways people document their personas. Todd Zaki Warfel, over at MessageFirst has some interesting diagrams, though he admits they take a bit of explanation.

However, these are just the final souvenirs, after the team has gained the real value. That value comes when the team visits and observes their target audience, absorbs and discusses their observations, and reduces the chaos into patterns, which then become the personas.

What’s in the team’s head, as they are designing, is what will make a difference in the final design. The persona descriptions are just there to remind everyone what happened.

If you’re amongst those who insist on judging the value of personas on their descriptions, I suggest you cancel your next vacation and just order one of these gift boxes. I’m sure you’ll find it just as valuable as the vacation itself.

39 Responses to “Personas are NOT a Document”

Very well said. The real value, in my mind, of personas (or persona descriptions or whatever) is the act of their creation; the observation, research, etc. and the lessons learned from that. Simply handing a designer (who didn’t participate in its creation) a document is almost useless.

Ironically, even though I am the one Joshua cites as an inspiration for his actually publishing a few good persona documents, I agree with you, Jared, that the majority of the benefit of creating personas comes not in the document itself, but in the research and interpretation process. The creation of the document, of course, is part of that process — when interpreting the data to synthesize it into a document, the design team is actually thinking about the data in useful ways, in ways that resemble the things they will need to think about when they begin desigining. They are “warming up the brain muscles” they will soon use when designing the product itself.

The document is in many ways nothing but an information-visualization fetish object, something to justify the cost of the research and thinking efforts to the people who paid for it. But the more important purpose of the document is the thinking that the producers of the document go through as they create it. In an odd coincidence, I just blogged about this very thing this morning, but unfortunately it was only just now that I thought of the “warm up the brain muscles” metaphor.

And I agree completely with Keith that handing a designer a persona is just wrong. The designers should create, or participate in the creation of, the personas. A persona is a design exercise, not a research report.

Jared, thanks so much for this post! The analogy to the picture album is spot on.

We get so lost in our deliverables and sharing information that we forget that we’re really trying to collect and share knowledge. Just like the software we build, the persona document is hopefully an interface to a much deeper connection and store of insight or “institutional memory.” In most cases, I fear that we’re just leaving the document, not the knowledge.

Agreed 100%, Jared. If you read the rest of my post you’ll see that I use the term “persona” to mean both the hypothetical archetype as well as the resulting document. I quoted both Wikipedia definition as well as Alan Cooper.

Sorry for your confusion. I was simply using the term as it is commonly used…

Jared, typically well put. The map is not the territory. The idea that personas=a document is a common misconception that I find we have to dispel in our training courses on usability. Once people realise that the real value is in the process, not the deliverable, it helps people appreciate the futility of just “making it up” rather than basing personas on real research.

I’ve been through the process and created the deliverable many times. It was always (to me) time that could have been much better put to use with other user research like focus groups, task analysis, and user testing. Personas are 90% fluff to me. If I can already use the market research and use user contact to create a visual picture of the main types of users in my head, then why go through a laborious process creating tons of docs to tell me what I already know? People ‘used’ to say personas were supposed to be used by everyone on the project including development. No one ever read the persona documents. So now its the PROCESS thats the goodness, it doesn’t matter that no one reads it except the client. Well I don’t need the process either – I should already know everything in the deliverable if Ive done my homework. Ill take that chunk of time and budget and maybe do some phone questionnaires or sit some live folks down and watch them go through a prototype.

When talking about who we were designing products for I kept a
this quote from Philippe Starck handy:
“[At Thompson] I outlawed the word ‘consumer’ in all company meetings, and insisted it be replaced by the words ‘my friend,’ ‘my wife, ‘my daughter,’ ‘my mother,’ or ‘myself.’ It doesn’t sound the same at all, if you say: ‘It doesn’t matter, it’s shit, but the consumers will make do with it,’ or if you start over again and say, ‘It’s shit, but it doesn’t matter, my daughter will make do with it.’ All of a sudden, you can’t get away with it anymore. There is an enormous task to be done with this kind of symbolic repositioning.”
We ARE designing for people by creating great “things” to help them … not great products that they buy!
and I found this grounded people in persona work.

Jared. Thanks. In some respects, this may seem like a no-brainer, but when you’re stuck in the daily grind of getting usability into an organization, it’s easy to loose perspective and fall into the documentation trap. Your comment helped me refocus on what is important and its implications for how we work.

We often use other techniques like persona video diaries – where a persona gets acted out and makes video diary that communicate how they feel at different points in the process. The tough bit is finding someone who can make a convincing persona that people don’t look at and say “but that’s Kerry from reception”!

The process of creating this as you say, is the key bit of learning, but the output is often much more useful than the paper document to communicate the ideas.

We also use the mood tracking bar, to follow a persona through a journey (which is usually much wider than the web user journey – it’s almost always the entire process e.g. buying a car, or a mortgage, which includes the ‘offline’ aspects of the journey too) and to track how they feel emotionally through the process. e.g. to document the gulf of despair people fall into after the elation of having got their mortgage approved when they realise they still have to go through the trauma of actually buying a house!

I disagree somewhat with this – “However, these are just the final souvenirs, after the team has gained the real value. That value comes when the team visits and observes their target audience, absorbs and discusses their observations, and reduces the chaos into patterns, which then become the personas.

What’s in the team’s head, as they are designing, is what will make a difference in the final design. The persona descriptions are just there to remind everyone what happened.”

I agree that the document is not the persona. Obviously you can change the way you design your persona document but that doesn’t mean you’ve changed the persona. The problem with the above statement is that for many teams, it’s unrealistic to think that the entire team will be engaged in the user research and experiencing it first-hand. In fact, this is often one of the core values of the personas – it personalizes the user research for people who weren’t involved when it happened. For these consumers of the personas, the document IS the persona — it’s all they see. Which means it’s absolutely critical to do a good job of designing the persona document… and calling the document a “reminder” could trivialize its importance.

[...] criticism and commentary from user experience heavyweights like Peter Merholz at Adaptive Path, and Jared Spool at User Interface Engineering. Then I tried to write my own clever and finely tuned rebuttal. After [...]

[...] me of Spalding Gray’s comedic novel/memoir Impossible Vacation. Spool insists that an online persona is not a document. He contends that it is far more alive — a corpus of research and hands-on interaction. His [...]

In comment #17, you stated, “There has to be better way of including the newcomers.”

But then didn’t offer any answer.

In my experience, personas are the single best tool for engendering empathy throughout an organization for customers, particularly for all those who don’t have the opportunity to engage in deep interactions with them. This is not to say that they are a great tool — I have found no better tool.

The second best tool is probably a video highlight reel. The problem with video highlights is that, because you want them to be focused and punchy, I think you actually lose more of the nuance and context that even a persona provides. What you do get is a more visceral response.

I’m not so sure I’m ready to commit to Persona being a verb. We persona’d and afterward there was a persona description.
Flipping through a souvenir picture album is essentially data and if the persona document does no more than record the story of the research, it is inadequate.

A well executed persona is about analysis, synthesis, and storytelling. When I do design research, I don’t see it as taking an interesting trip that I will casually share some cool moments from afterward.

Personas are a representation of the qualitative data story in much the same way that a documentary or a travelogue is a representation of a qualitative data story. You do know and feel something without being there at the time. Further, an important measure of success for a qualitative data story is that you understand more from the story than what you understood if you were there at the time.

A souvenir picture album is essentially data. Taking a trip, is essentially taking a trip.

Telling an effective qualitative data story is about finding the right methods and representations that map to both the research findings (developed through analysis, synthesis) and the audience that needs to use these stories to move their project forward.

[...] the design research phase. It was Jared Spool that mentioned the real value of personas being the actual process of engaging with users and developing empathy towards their circumstances and experience interacting with a product.1 The [...]

[...] the design research phase. It was Jared Spool that mentioned the real value of personas being the actual process of engaging with users and developing empathy towards their circumstances and experience interacting with a product.1 The [...]

[...] the design research phase. It was Jared Spool that mentioned the real value of personas being the actual process of engaging with users and developing empathy towards their circumstances and experience interacting with a product.1 The [...]

[...] video, screen recorders, and persona write-ups. In large projects, that stuff is mostly for you to communicate with others on the project, to convince clients, developers, and managersthat you know what you’re doing [...]

[...] where the value in doing these expensive design research exercises are. Just like Jared Spool said Personas are not a document. It’s the journey of actually experiencing what it’s like to be with someone who will [...]

I’m sure it was semantics. I’d guess that his comment that personas are a document was to make clear that personas descriptions should be defined and set down in a fixed medium in order to be shared with team members.

btw, I’ve worked with hundreds of clients on hundreds of websites and few agencies or clients give a crap about personas, use case scenarios, roles, etc. True they’re missing out and likely don’t even know what they’re missing out on, but still, they expect their RFP was enough info for you to whip together their website in a couple of months.

[...] design research phase. It was Jared Spool that mentioned the real value of personas being the actual process of engaging with users and developing empathy towards their circumstances and experience interacting with a [...]