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.

I agree that the its often the case that everyone will experience the user research first hand.

However, the data that is behind each persona is very rich. The persona creation process has a lot of vitality.

Much of this is lost in the persona description document. Leaving the job of communicating the true value of the personas to that document is a recipe for failure, in my mind.

There has to be better way of including the newcomers.

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.

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!

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

There’s been a lot of confusion over what a “persona” is. Over on the IxDA discussion list, it’s one of many terms that has met a definition-death-spiral.

Thanks for sharing your intent.

This is a great way to cut through the chaff. I’ve been editing an article by Andrew Hinton that dives more deeply into the personas process vs. documentation.

He unpacks the goals behind our documentation in a way that helps refocus our perspective towards what we do, as opposed to what we deliver. It will be up on Boxes and Arrows soon.

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

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.

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.