Comments on Personas and the Role of Design Documentation

Jamie Owen — Thu, 06 Mar 2008 17:06:07 GMT

An instructor of mine once said “Bad design done on a computer doesn’t make it good design.” And I think this phenomenon is what David Royer is getting at when he mentions tech-lust. But in addition to teaching the tech-lusty designers HOW to use personas (“force new designers to approach the design problems in a very human-centered way”), I think it’s important for the designers to understand WHY they are doing it. In this discipline, the lines distinguishing How and Why are very blurry and both need to be represented in instructional settings.

In the marketplace, this metacognitive awareness woven into the practice of using personas helps the future designers understand that they will need to strategically apply personas in differing ways as they respond to different clients or project scopes. And this sensibility, as David says, will make its way tacitly (but why not consciously?!) into other aspects of how they design interactivity.

David Royer — Mon, 17 Mar 2008 17:23:37 GMT

Very nice article. It is funny how personas are becoming a hot topic all of a sudden.

I agree with most things said on this board, but I think one important use of personas was left out. Design education, both formal and informal.

Johnathon said: “As the designer, you just need to know your users and design accordingly. Not a very complicated idea.”

Maybe it is not a complicated idea, but it can be a difficult idea in practice. As an assistant instructor for an interaction design class I observed the tech-lust of many new interaction designers. Using personas (correctly) forces new designers to approach the design problems in a very human-centered way. This human-centered way of approaching problems becomes part of this designers tacit knowledge and changes the way designers work, even when they are not using personas.

Ben Arent — Mon, 17 Mar 2008 17:23:34 GMT

Hi Andrew,

I saw your posting on the hot-list of del.ico.us. I found the article a very interesting read. I’m just about to graduate from my product design degree, of which I have tried to focus on interaction from a very human factors (usefull) manor. I have found that my degree has focused more on ‘experience’ than the traditional of ID. For my dissertation I undertook a range of empirical based methods to understand how technology related product / services / experiences could be better designed. The result was to use these insights to create ‘experiance prototypes (bill buxton style) and to review this with real muliple users in differing situations and contexts. You can see a digram on my website. http://www.benarent.co.uk/bog/dissertation/

On a side note, when Bill Gaver introduced Cultural probes in 1999, a main part of his presentation was that there was to be no analysis of the data itself, rather that it was a point for conversation could be undertaken to greater inform disscussion.

Anyway, Great stuff!

Benjamin Ho — Mon, 17 Mar 2008 17:23:31 GMT

Great article! This compliments Jared Spool’s article on how Personas are like vacations – you can’t really write about them, you have to experience them. So essentially, the process of “Modeling” after particular key users is extremely beneficial in understanding the product’s users.

Jonathan Baker-Bates — Thu, 17 Apr 2008 19:58:13 GMT

37Signals’s assertion that you can only design for yourself is trivially true, but worthless as a practical oberservation. Just thought I’d get that off my chest!

It seems to me that Cooper presented two separate perspectives on personas which have given rise to the endless and confused debate about them ever since. The first perspective is that they are for inspiring the designer (cf his walking on the golf course anecdote), and the second is that they are for inspiring the development team (cf a large chunk of Inmates).

If, for example, a persona is something you have in your head after meeting some real user(s) of your intended product, then that implies documentation isn’t necessary. As the designer, you just need to know your users and design accordingly. Not a very complicated idea (and whether this justifies Andrew’s rather tangential rant about the evils of deliverables cuture I don’t really know).

If, however, a persona is something you construct as an artefact, then what is that artefact for? Cooper says it’s for making sure the development team (ie those who have the power to royally screw up the product) do the right thing. So, create PPT decks, posters, t-shirts and the whole thing. This is bacuase the proor devils can’t actually meet their users (it’s impractical). Also not a very complicated or difficult idea to grasp, assuming the development team will wear the idea, that is.

Now here’s the first tricky problem that comes out of these two perspectives: the designer can influence the design; the develoment team can also influence the design. So (wonders Andrew) what perspective do you take? Cooper’s no help – he has it both ways. He also designs (or says he designs) massively complex systems that require him to shamanically commune within the minds of his users. Most of us, however, design websites selling things people don’t want.

Let the debate continue, I say. I love personas. I also hate their guts.

Tanya Rabourn — Thu, 06 Mar 2008 17:04:37 GMT

Good article!

The real hero of this story isn’t personas, it’s ethnographic methods. You mention that Cooper worked from “primary experience” for example. Methods are just a toolbox and you pick the appropriate tool you need to solve a particular problem. It’s not dogma. So, I’m going to unapologetically use that word ;-)

I’m only echoing your points but I have to say that this one question gets to the heart of the matter: “so what do we do, if we’re designing something that doesn’t have people just like us as its intended user?” Ethnographic work used to construct our concept of the user just might be the answer. Then we can produce documentation in the form of personas or even some other way (whatever works for whomever the audience may be).

A completely separate problem is putting these methods into practice within environments where matching user expectations can run second to executing stakeholder visions. I would say many of us work in a setting that won’t value the sort of information ethnography provides. Among the things that are valued, however, is expediency. It’s always faster to design for ourselves, so the practice of constructing our users as being just like us will continue to be popular.

Colleen Jones — Thu, 06 Mar 2008 17:04:45 GMT

Nice article! The point about personas are not just documentation is well-taken. In fact, I think most of the points in this article apply to most documentation we produce. The documentation is just the expression of the thoughts, the problem-solving, the design process. I agree in the short term we have to give the “beast” what it expects, but in the long term I wonder how can we change its expectations? I find that “beasts” can be anything from large companies to small interactive agencies…the production view of design seems deeply ingrained.

laurie kalmanson — Wed, 05 Mar 2008 09:52:03 GMT

this is the nut graf: the 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.

however you get to that—i am pretty much methodology agnostic; i believe in what works—is a good thing

true story about living with users and empathy: i was working on a web app to take mortgage processing online for a company where the money makers were the “guys,” mostly cops and firemen working second jobs when they weren’t on duty, who talked on the phone and wrote up the papers, and the assistants were the “gals,” who carried the papers upstairs and downstairs from one of the “guys” to another for approvals and signatures.

(there are many off the shelf products for the necessary tasks, but the work was all around the middleware to bridge a bunch of things together.)

after living with the company for a few days, and doing all the shadowing and interviewing and process flow charting you’d expect, i had a real duh moment when one of the “guys” took me aside and said, “you’re doing a great job of talking to the gals; i just wish we could get them to move our paper faster.”

i said thank you

and i asked two questions: which papers exactly was it most important to move faster, and were there any “gals” writing deals, too.

Andrew Hinton — Thu, 28 Feb 2008 01:51:53 GMT

Jamie: I agree totally. The article is already super-long, so I didn’t get into that aspect, but I’m a BIG fan of “Contextual Design”- like process, where there is HIGH collaboration through as much of the design process as possible. In CD all analysis & development of models happens in collab. with stakeholders involved as well. (I’m not doctrinaire on the Holzblatt-specific CD method, but the essential elements are incredibly important—and undergird a lot of my assumptions in this piece). Thanks for making this point :-)

Jamie Owen — Wed, 16 Apr 2008 22:15:12 GMT

Yes indeed, thanks for revisiting this topic. Since we’re all constantly gaining new experiences, revisiting segments of the IA canon with an evolved perspective can only serve to keep our fundamentals both strong and adaptable.

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.

James Kelway — Wed, 16 Apr 2008 22:15:03 GMT

Cheers Andrew – I think collaboration, as you say, between team members is key.

I recently wrote a post you may be interested in here http://userpathways.com/2008/02/22/user-stories-or-person… 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?

Andrew Hinton — Wed, 16 Apr 2008 22:14:44 GMT

Livia & James: Thanks so much for the feedback. I’ll admit, I did think of these points, and tried to pre-empt them in the piece, but maybe didn’t do it well enough.

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!

James Kelway — Wed, 16 Apr 2008 22:14:36 GMT

Hi Andrew, I agree with your reservations about our industry’s use of personas and its great to read another angle about how we use them. I feel that in many environments, as Livia points out, they are the tools that you need to capture the imagination of stakeholders who will inevitably throw the project off the road on an ill-conceived whim. I have found that there are good and bad uses of personas and I guess this is what we are highlighting here.

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.

Livia Labate — Tue, 20 May 2008 19:56:50 GMT

Andrew, I agree with all your sentiments and I disagree with most of your conclusions. :D

Totally in agreement about the level of empathy we need to establish with users to gain a true understanding of their motivations and desires. Also in agreement that there is no such a thing as “second-hand” “quick-summary” empathy; looking at the poster of the persona with the Getty Images photo during the project kick-off will do nothing for me.

However, we don’t create persons just for ourselves—and this is pretty key to me—in many a case, the reason for developing personas (or any other approach that seeks to convey who users are and what makes them tick) is to affect people who do NOT have the desired empathy level. They may not be people playing the designer role but they are final decision-makers, people who will bring up random edge cases that steer discussions in the wrong directions, folks who have limited involvement/contribution to the goals of your project, etc, etc. Personas (or your tool of choice), play the role of “grounding” conversations.

How exposed people are to the truth of the user reality varies in a spectrum (from Cooper’s re-enactment of his experience with a real person to the “kick-off meeting persona deck” exposure), where it is obvious which extreme is most valuable, but even the most remote exposure to it will act as a “grounding” element that contributes to better decision-making. And while that may be a secondary goal of Personas specifically, I seem to encounter that more frequently than not (both in my experience and what I’ve observed from colleagues).

This is also why there are specialist roles in an organization. Not everyone has the profile/background/interest/tools/shared goals to establish this close rapport with the actual users, so you need people like designers and researchers who will did on everyone’s behalf acting, therefore, as proxies between users and stakeholders. Not to contradict myself, again, no such a thing as second-hand empathy with the end user, but definitely a more cohesive understanding of the actual people being represented.

“Cooper didn’t start with a “method”—or especially not a “methodology”!”—right on. The reality of the world is that you have to get financial approval/sponsorship, recruit participants and coordinate all the logistics of getting your user research done, actually do that research, PLUS get all the relevant stakeholders involved in this process. And you don’t want to waste time. So while personas aren’t a document, how this effort is captured, shared and communicated is crucial to ensure not only its success but your ability to do it efficiently and repeatedly. So, again, I agree with the sentiment, but my conclusion is that capturing all this richness in a document as a task that you check off your project plan is pure waste of time. Rather, time spent planning how the outcome of the research and the persona artifacts will be used on the day to day, is time much better spent—or really where you should spend more time on versus documenting. But documenting may very well be part of that strategy, so I wouldn’t paint such a negative picture of personas as documentation.

I’m actually experiencing this right now. For three months I’ve been trying to kick off a project with the goal to bring our team closer to the reality of users in a service we support. I don’t know if I want the project to produce personas or something else. Even picking a name for this effort has been a problem since I don’t want to make that assumption and would prefer to let this exercise of bringing all stakeholders together and doing the research, allow for the best method to emerge. This is making the planning of the actual work much harder, but I’m confident I can’t do more good by keeping things “open”—I’m pointing this out because while I believe this is desirable and necessary, I know this is not the level of energy I have spent in the past or that other people are comfortable with. It would be a million times faster, easier and convenient for all involved if I just ‘cranked the widget’ of running a “personas project” aka, using an ‘established methodology’. It is in a sense, just economy of scale.

Livia Labate — Wed, 16 Apr 2008 22:14:22 GMT

Dan Brown just wrote something interesting about Personas:
http://www.greenonions.com/archives/2008/02/24/personas-g…