Just wanted to say that I thought this was a very balanced, well-written article, posing some very carefully thought-out and interesting arguments. Thank you!

The detail from Cooper’s “slim” chapter of the Inmates book that pops back in my head most often is his description of personas as a key that unlocks a specific puzzle box. I agree with Andrew, but I think he and most everybody else misses this gem. In the book, the puzzle box was the core functionality of a device on an airplane and the key turned out to be a senior citizen with a bad attitude. My experience is that the value of the warmth and fuzziness of personas is fleeting; bit its value as a problem-solving mechanism is significant and long-lasting.

You heard it here last.

See Lucy’s article: Users, Roles, and Personas
http://www.foruse.com/articles/rolespersonas.htm

Description: User role models are compared in detail with the popular user modeling technique of personas. User roles offer a more compact, more focused means of capturing and exploring those aspects of users most relevant to interaction design. The advantages and limitations of the approaches are considered and a combined strategy is described.

I do feel that documentation, deliverables, are key to define how successful our work is. Design in general has always suffered from not documenting its reasons for making design decisions. The successes are often realised and celebrated but the methods behind these cases are not published, or lost in time, in the heads of the designers.

This is a strength of information architecture and user experience. We have the tools to establish why we can achieve an upturn in site revenue or why the user’s feel that the site is a better product. To deny personas would be a mistake, as 37 signals suggest, and to feel a persona more by role-play sounds interesting and I can see for some situations it is a necessity.

Dan Brown recently mentioned in a talk at IXD that if Apple had used personas – would the browse feature of an iPod have been more intuitively designed? Perhaps a great product could have been even better. I am of the opinion that they are part of a tool box that helps us create better designs, better products. As you say, if they make us honest or true to the delivery of a project, then a persona is a great thing. Let us keep hold of them, and make sure they are alive.

In short: I wanted to emphasize that personas are first and foremost the act of empathetic imagination for design; and I wanted to emphasize that all design documentation is first and foremost an artifact/tool for collaborative reflection, shared understanding and iteration. As long as we remember these things, we can then go on to make all the persona descriptions and slick stakeholder deliverables we want and need to get the rest of the job done

My article is meant as a corrective statement, to a degree. This is why I focus so strongly on what I see as the *first* priority of methods and documentation in design work—shared artifacts for the design process. Because I think this has gotten lost in the conventional wisdom of “documents for stakeholders,” I amped up my point in the other direction, trying to drag the pendulum more toward the center.

I was careful to point out that stakeholder communication is also, of course, a very important goal. But it is a SEPARATE goal. It may even require creating separate deliverables to achieve! We too often get caught up in using documentation as a tool for convincing other people, rather than tools for collaborative design among the practitioners. I may have overstated my case, though, and, alas, obscured these caveats I scattered throughout.

Probably I could’ve been this clear in the actual article? *sigh* …

At any rate, these conversations are the real reason I wrote this … so please keep the feedback coming!

I recently wrote a post you may be interested in here http://userpathways.com/2008/02/22/user-stories-or-personas/ though not as in-depth or well-researched!

I think the communication with stakeholders is separate like you say to the communications you have within the team and perhaps different deliverable is the way to go. A richer set for design and development maybe?

In your recap comment, you talk about documentation “for collaborative design among the practitioners.” I think this means the persona documents serve as a catalyst for (at least one) aspect of collaboration, right? Well, what if personas are themselves developed collaboratively? Like, collaboration by selected team members from all phases of a project or from the different departments that impact an initiative. And of course including a certain number of the actual users.

The various respective team members all have an input in creating the personas; with guidance/facilitation steering the persona-making collaboration session(s), those team members understand the personas’ value and meaning to their interests (stakeholders, graphic design, marketing, database deign, etc). The utility that the personas serve toward design decision-making doesn’t fade away. Therefore personas are less likely to be only a reminder–they become, as you’ve pointed out, part of a common collaborative language essential to the success of the project.

In addition, use of the personas across a diverse team might be articulated in a way that resonates respective to each segment of the team. This too will help vet the personas’ value and meaningfulness, plus nurture consistent visits to the personas to aid collaboration and decision-making. It may help open up some of the silo-ed processes that many of us face in our workplaces.