Personas and the Role of Design Documentation

Posted by

I’d seen hard work on personas delivered in documentation to others downstream, where they were discussed for a little while during a kick-off meeting, and then hardly ever heard from again.

In User Experience Design circles, personas have become part of our established orthodoxy. And, as with anything orthodox, some people disagree on what personas are and the value they bring to design, and some reject the doctrine entirely.

I have to admit, for a long time I wasn’t much of a believer. Of course I believed in understanding users as well as possible through rigorous observation and analysis; I just felt that going to the trouble of “creating a persona” was often wasted effort. Why? Because most of the personas I’d seen didn’t seem like real people as much as caricatured wishful thinking.

Even the personas that really tried to convey the richness of a real user were often assimilated into market-segment profiles — smiling, airbrushed customers that just happened to align with business goals. I’d see meeting-room walls and PowerPoint decks decorated with these fictive apparitions. I’m ashamed to say, even I often gave in to the illusion that these people — like the doe-eyed “live callers” on adult phone-chat commercials — just couldn’t wait for whatever we had to offer.

More often than not, though, I’d seen hard work on personas delivered in documentation to others downstream, where they were discussed for a little while during a kick-off meeting, and then hardly ever heard from again.

Whenever orthodoxy seems to be going awry, you can either reject it, or try to understand it in a new light. And one way to do the latter is to look into its history and understand where it came from to begin with — as is the case with so much dogma, there is often a great original idea that, over time, became codified into ritual, losing much of the original context.

The Origin of Personas

When we say “persona”, designers generally mean some methodological descendant of the work of Alan Cooper. I remember when I first encountered the idea on web-design mailing lists in 1999. People were arguing over what personas were about, and what was the right or wrong way to do them. All most people had to go on was a slim chapter in Cooper’s “The Inmates are Running the Asylum” and some rudimentary experience with the method. You could see the messy work of a community hammering out their consensus. It was as frustrating as it was interesting.

Eventually, practitioners started writing articles about the method. So, whenever I was asked to create personas for a project, I’d go back and read some of the excellent guides on the Cooper website and elsewhere that described examples and approaches. As a busy designer, I was essentially looking for a template, a how-to guide with an example that I could just fill in with my own content. And that’s natural, after all, since I was “creating a persona” to fulfill the request for a kind of deliverable.

It wasn’t until later that Alan Cooper himself finally posted a short essay on “The Origin of Personas.” For me it was a revelation. A few paragraphs of it are so important that I think they require quoting in full:

I was writing a critical-path project management program that I called “PlanIt.” 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 PlanIt 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.

If we slow down enough to really listen to what Cooper is saying here, and unpack some of the implications, we’re left with a number of insights that help us reconsider how personas work in design.

1. Cooper based his persona on a real person he’d actually met, talked with, and observed.
This was essential. He didn’t read about “Kathy” from a market survey, or from a persona document that a previous designer (or a separate “researcher” on a team) had written. He worked from primary experience, rather than re-using a some kind of user description from a different project.

2. Cooper didn’t start with a “method” — or especially not a “methodology”!
His approach was an intuitive act of design. It wasn’t a scientific gathering of requirements and coolly transposing them into a grid of capabilities. It came from the passionate need of a designer to really understand the user — putting on the skin of another person.

3. The persona wasn’t a document. Rather, it was the activity of empathetic role-play.
Cooper was telling himself a story, and embodying that story as he told it. The persona was in the designer, not on paper. If Cooper created a document, it would’ve been a description of the persona, not the persona itself. Most of us, however, tend to think of the document — the paper or slide with the smiling picture and smattering of personal detail — as the persona, as if creating the document is the whole point.

4. Cooper was doing this in his “spare time,” away from the system, away from the cubicle.
His slow computer was serendipitous — it unwittingly gave him the excuse to wander, breathe and ruminate. Hardly the model of corporate efficiency. Getting away from the office and the computer screen were essential to arriving at his design insights. Yet, how often do you see design methods that tell you to get away from the office, walk around outside and talk to yourself?

5. His persona gained clarity by focusing on a particular person — “Kathy”.
I wonder how much more effective our personas would be if we started with a single, actual person as the model, and were rigorous about adding other characteristics — sticking only to things we’d really observed from our users. Starting with a composite, it’s too easy to cherry-pick bits and pieces from them to make a Frankenstein Persona that better fits our preconceptions.

Personas are actually the designer’s focused act of empathetic imagination, grounded in first-hand user knowledge.

The biggest insight I get from this story? Personas are not documents, and they are not the result of a step-by-step method that automagically pops out convenient facsimiles of your users. Personas are actually the designer’s focused act of empathetic imagination, grounded in first-hand user knowledge.

It’s not about the documents

Often when people talk about “personas” they’re really talking about deliverables: documents that describe particular individuals who act as stand-ins or ‘archetypes’ of users. But in his vignette, Cooper isn’t using personas for deliverables — he’s using them for design.

Modern business runs on deliverables. We know we have to make them. However, understanding the purposes our deliverables serve can help us better focus our efforts.

Documentation serves three major purposes when designing in the modern business:

1. Documentation as a container of knowledge, to pour into the brains of others.

By now, hopefully everyone reading this knows that passing stages of design work from one silo to the next simply doesn’t work. We all still try to do it, mainly because of the way our clients and employers are organized. As designers, though, we often have to route around the silo walls. Otherwise, we risk playing a very expensive version of “whisper down the lane,” the game you play as kids where the first kid whispers something like “Bubble gum is delicious” into another’s ear, and by the end of the line it becomes “Double dump the malicious.”

Of course there are some kinds of information you can share effectively this way, but it’s limited to explicit data — things like world capitals or the periodic table of elements. Yet there are vast reservoirs of tacit knowledge that can be conveyed only through shared experience.

If you’ve ever seen the Grand Canyon and tried to explain it to friends back home, you know what I mean. You’d never succeed with a few slides and bullet points. You’d have to sit down with them and — relying on voice, gesture and facial expression — somehow convey the canyon’s unreal scale and beauty. You’d have to essentially act out what the experience felt like to you.

And even if you did the most amazing job of describing it ever, and had your friends nearly mirroring your breathless wonderment, their experience still wouldn’t come close to seeing the real thing.

I’m not saying that a persona description can’t be a useful, even powerful, tool for explaining users to stakeholders. It can certainly be highly valuable in that role. I’m only saying that if you’re doing personas only for that benefit, you’re missing the point.

2. Documentation as a substitute for physical production.

Most businesses still run on an old industrial model based on production. In that model, there’s no way to know if value is being created unless there are physical widgets coming off of a conveyor belt — widgets you can track, count, analyze and hold in your hand.

In contrast, knowledge work – and especially design – has very little actual widget-production. There is lots of conversation, iteration, learning, trying and failing, and hopefully eventual success. Design is all about problem solving, and problems are stubbornly unmeasurable — a problem that seems trivial at the outset turns out to be a wicked tangle that takes months to unravel, and another that seemed insurmountable can collapse with a bit of innovative insight.

Design is messy, intuitive, and organic. So if an industrial-age management structure is to make any sense of it (especially if it’s juicing a super-hero efficiency approach like Six-Sigma), there has to be something it can track. Documents are trackable, stackable, and measurable. In fact, the old “grade by weight” approach is often the norm — hence the use of PowerPoint for delivering paper documents attenuated over two hundred bulleted slides, when the same content could’ve fit in a dozen pages using a word processor. The rule seems to be that if the research and analysis fill a binder that’s big enough to prop your monitor to eye level, then you must’ve done some excellent work.

In the pressure to create documents for the production machine, we sap energy and focus away from designing the user experience. Before you know it, everything you do — from the interviews and observations, to the way you take notes and record things, the way you meet and discuss them after, and the way you write your documentation — all ends up being shaped by the need to produce a document for the process. If your design work seems to revolve mainly around document deadlines, formatting, revision and delivery, stop a moment and make sure you haven’t started designing documents for stake-holders at the expense of designing experiences for users.

Of course, real-world design work means we have to meet the requirements of our clients’ processes. I would never suggest that we all stop delivering such documentation.

Part of the challenge of being a designer in such a context is keeping the industrial beast happy by feeding it just enough of what it expects, yet somehow keeping that activity separate from the real, dirty work of experiencing your users, getting them under your skin, and digging through design ideas until you get it right.

3. Documentation as an artifact of collaborative work and memory.

While the first two uses are often necessary, and even somewhat valuable, this third use of documentation is the most effective for design — essentially a sandbox for collaboration.

These days, because systems tend to be more interlinked, pervasive and complex, we use cross-disciplinary teams for design work. What happened in Cooper’s head on the golf course now has to somehow happen in the collective mind of a group of practitioners; and that requires a medium for communication. Hence, we use artifacts — anything from whiteboard sketches to clickable prototypes.

The artifacts become the shorthand language collaborators use to “speak design” with one another, and they become valuable intuitive reminders of the tacit understanding that emerges in collaborative design.

Personas, as documents, should work for designers the way scent works for memories of your childhood.

Because we have to collaborate, the documentation of personas can be helpful, but only as reminders. Personas, as documents, should work for designers the way scent works for memories of your childhood. Just a whiff of something that smells like your old school, or a dish your grandmother used to make, can bring a flood of memory. Such a tool can be much more efficient than having to re-read interview transcript and analysis documents months down the road.

A persona document can be very useful for design — and for some teams even essential. But it’s only an explicit, surface record of a shared understanding based on primary experience. It’s not the persona itself, and doesn’t come close to taking the place of the original experience that spawned it.

Without that understanding, the deliverables are just documents, empty husks. Taken alone, they may fulfill a deadline, but they don’t feed the imagination.

Playing the role

About six months ago, my thoughts about this topic were prompted by a blog post from my colleague Antonella Pavese. In her post, she mentions the point Jason Fried of 37 Signals makes in +Getting Real+ that, at the end of the day, we can only design for ourselves. This seems to fly in the face of user-centered design orthodoxy – and yet, if we’re honest, we have to realize the simple scientific fact that we can’t be our users, we can only pretend to be. So what do we do, if we’re designing something that doesn’t have people just like us as its intended user?

Antonella mentions how another practitioner, Casey Malcolm, says to approach the problem:

To teach [designers] how to design usable products for an older population, for example, don’t tell designers to take in account seniors’ lower visual acuity and decreased motor control. Let young designers wear glasses that impair their visual acuity. Tie two of their fingers together, to mimic what it means to have arthritis or lower motor control.”

Antonella goes on:

So, perhaps Jason Fried is completely on target. We can only design for ourselves. Being aware of it, making it explicit can make us find creative ways of designing for people who are different from us… perhaps we need to create experience labs, so that for a while we can live the life of the people we are designing for.”

At UX Week in Washington, DC this summer, Adaptive Path unveiled a side project they’d been working on—the Charmr, a new design concept for insulin pumps and continuous monitors that diabetics have to constantly wear on their bodies. In order to understand what it was like to be in the user’s skin, they interviewed people who had to use these devices, observed their lives, and ruminated together over the experience. Some of the designers even did physical things to role-play, such as wearing objects of similar size and weight for days at a time. The result? They gained a much deeper feel for what it means to manage such an apparatus through the daily activities the rest of us take for granted — bathing, sleeping, playing sports, working out, dancing, everything.

Personas aren’t ornaments that make us more comfortable about our design decisions. They should do just the opposite.

One thing a couple of the presenters said really struck me — they said they found themselves having nightmares that they’d been diagnosed with diabetes, and had to manage these medical devices for the rest of their lives. Just think — immersing yourself in your user’s experience to the point that you start having their dreams.

The team’s persona descriptions weren’t the source of the designers’ empathy — that kind of immersion doesn’t happen from reading a document. Although the team used various documentation media throughout their work – whiteboards and stickies, diagrams and renderings – these media furthered the design only as ephemeral artifacts of deeper understanding.

And that statement is especially true of personas. They’re not the same as market segmentation, customer profiling or workflow analysis, which are tools for solving other kinds of problems. Neither do personas fit neat preconceptions, use-cases or demographic models, because reality is always thornier and more difficult. Personas aren’t ornaments that make us more comfortable about our design decisions. They should do just the opposite — they may even confound and bedevil us. But they can keep us honest. Imagine that.


  • Alan Cooper, “The Origin of Personas”:
  • Jason Fried, “Ask 37 Signals: Personas?”:
  • Antonella Pavese, “Get real: How to design for the life of others?”:
  • Dan Saffer, “Charmr: How we got involved”:

_*Author’s Note:* In the months since the first draft of this article, spirited debate has flared among user-experience practitioners over the use of personas. We’ve added a few links to some of those posts below, along with links to the references mentioned in the piece. I’d also like to thank Alan Cooper for his editorial feedback on my interpretation of his Origins article._

  • Peter Merholz, “Personas 99% bad?”:
  • Joshua Porter, “Personas and the advantage of designing for yourself”: and “Personas as tools”:
  • Jared Spool, “Crappy personas vs. robust personas”: and “Personas are NOT a document”:
  • Steve Portigal, “Persona Non Grata”:, interactions, January/February 2008


  1. 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.

  2. 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!

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

    I recently wrote a post you may be interested in here 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?

  4. 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.

  5. 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 🙂

  6. 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.


  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. Hi Andrew,

    I saw your posting on the hot-list of 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.

    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!

  12. 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.

  13. 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.

  14. Nice article, Andrew! I am also a firm believer of being with the user and empathize with him to understand his motivations and aspirations. But as we all are aware, we are not living in an ideal world.
    For example, I was told in my last project – before even it started – that I could empathize only with two user groups because I was supposed to create two personas only with the allotted budget. In such situations, when constraints restrict the creativity, we are left with no choice, but to compromise and do our best on the basis of our experience, expertise, and exposure.
    And this is what distinguishes artists from designers. Artists defy the rules and work on their whims and fancies. Designers, on the other hand, are trained to work in constraints for the masses. Therefore, sometimes I dream of to be an artist. 🙂

  15. Andrew:

    Thanks for taking the time to share your perspective. Obviously a lot of thought went into this piece. Couple of comments to add.

    1) Cooper’s approach to personas works well for Cooper however it doesn’t necessarily transfer to the rest of us working in our varied environments with myriad different partners and stakeholders.

    2) The 37signals thoughts on designing for oneself are noted. I am familiar with this line of thinking and believe it works for some. I refer to this approach as Designer-Centered Design. My personal preference is to practice User-Centered Design. Here’s the continuum as I see it.

    Design for Myself (hit or miss)
    I am the user (good)
    I asked the User (better)
    I Observed the User (best)

    Like many folks who’ve been in the this field for a while I started in product design and software before the Internet blossomed. I have always been a staunch believer in User-Centered Design even before I knew what it was. Designing software using a UCD methodology meant designing for the required user groups and involving them in the process from beginning to end. The end result was a designed product guided and approved by the people who would use it. Personas were not really necessary.

    That all changed when individual software products were adopted and used by masses of people. Suddenly it became impossible to design for and involve all the user groups in the process. It was personas that allowed us to construct archetypal users from these masses. These personified users were developed in a way that allowed us to design for their needs and simultaneously meet the needs of the broader user groups.

    In the beginning the personas were one off creations for a specific problem at hand. They were used by the internal team for a current project. IMO we began to run into all kinds of problems when our clients, partners and stakeholders took a liking to the personas we were creating. One the one hand this was a wonderful thing because it brought everyone together in the process. On the other hand there were several negative effects…a few include:

    1) The personas were interpreted more deeply than the data behind them allowed.
    2) The personas were used outside the scope of their intended use.
    3) We began to make the personas more and more general to allow for mixed use which meant they were less useful for specific tasks at hand.

    To this day I’m still a fan of a more rigorous approach to designing personas. I do think they can be extremely valuable tools for broader audiences and as such I have moved a bit more in the direction of generalizing them for multiple uses. I think it’s also worth noting that personas are not the end-all-be-all tool. There are times when alternative outputs from research are better suited to guide design.

  16. Hi Andrew thank you for taking the time to write this. Good info.

    My background is in Graphic Design and the idea behind drafting personas is very close if not spot on to that of developing a creative brief. We’d often sit around discussing demographics, what made them tick, what were their patterns of behavior that set them apart.

    During one project not too long ago I had the pleasure of reading a beautifully written brief which succinctly outlined the target audience. It avoided the usual bullet points and groups outlining instead what was clearly an effort by my client as she visited her audience, the boutiques where her products would eventually be sold, speaking to sales people, and imagining the aspirations of those who would use the product. Specificaly looking into their lives and how her product would fit into their lifestyle boosting their self image.

    That one sheet of paper was worth at least four weeks of research allowing me to see clearly through, not into, but through the eyes of her audience.

    I wonder if our industry would do well by looking into tradition marketing techniques to define the creative direction of a product. While working for a large internet firm I found information which normally would have been shared in a kickoff meeting – a design studio or ad agency – absent. There weren’t the discussions, process, nor the team environments which help foster creativity. As grids are just becoming popular in the IT environment, it surely would help us to try using the other fundemental concepts behind advertising, information and graphic design.

    Thanks again for the article. Very much appreciated!

  17. Great article, Andrew. From my own experience I wrote a Microsoft Certified Training program a few years back. The focus of the Adult Learning section was premised on David Kolb’s work. He outlined four principles of how adults learn:

    1. Adults need to know “Why?” they are learning something.
    2. Adults learn best when the topic is of immediate value.
    3. Adults approach learning as problem solving.
    4. Adults learn experientially.

    I think all of these points reinforce your ideas around Personas and why Alan Cooper had such great insight while walking that golf course. While strolling around the 9th hole he was asking himself the purpose of the design and its’ inherent value based on different scenarios. By actively questioning this process he was problem solving and doing so in a way that allowed him to experience (even though it was imagined) how to best move forward.

    I’ve had experiences where Personas work very well and where they flop. The ones that worked well, in retrospect after reading your article, were ones where the client bought into the old premise of “seek first to understand, then to be understood”. In other words, the client really got what it meant to be the end user and was able to use the Persona as a kind of “design bible”. In the instances where they flopped, it was, as you pointed out, just a deliverable.

    Thanks for sharing your ideas – brilliant!

  18. NIce article!

    I agree that personas are too often just a deliverable done out of habit. Here are some thoughts on how to make actionable personas that executives can use:

    Here’s an example of personas done wrong:

    “The most important part this new world order is the “persona.” Personas are essentially stereotypes that Best Buy’s salespeople study in order to sell their most profitable services to different “types” of customers. Young urban males are called “Buzz.” Upper middle class women are known as “Jill.””

  19. Excellent article!
    Yes, a persona can end up being a forgotten document if you’re not careful. One method I use to make sure that personas are useful in the entire process is to always include a prioritized list of primary and secondary tasks that each persona/user group will want to perform in the chosen application/site. This way, our team will always refer back to the persona when developing content, design, and functionality.

  20. Nice Article!

    I concur with number 1 and 3 in relation to a project I have worked on where personas were utilized to convince management live collaboration tools can be useful to our company.
    1. Cooper based his persona on a real person he’d actually met, talked with, and observed.
    3. The persona wasn’t a document. Rather, it was the activity of empathetic role-play.

    The personas on this project were based on real employees at my company. We were using them to create scenarios for how “real” employees would utilize live collaboration tools. Some managers believed live collaboration tools were flashy technologies used by teenagers and e-commerce companies. Personas were used to explain the usage within our departments. The document was not the focus, It was the ideas and scenarios for use that helped the team envision the solution. The personas helped management to visualize who would use things like “chat” for business related functions.

    You said ” I’m not saying that a persona description can’t be a useful, even powerful, tool for explaining users to stakeholders. It can certainly be highly valuable in that role. I’m only saying that if you’re doing personas only for that benefit, you’re missing the point.”

    Can’t we utilize personas to make decisions for the field of use of new technologies with in our companies? I hope that is not what you ment by missing the point.

    Personas can be useful in various instances however we need to analyze when and where they will add value to the project and when they are just pretty pictures and stories.

  21. Interesting article. I must admit, I started reading it with a bit of bias: I tend to view personas as Frankenstein’s monsters made up of bits and pieces of real people, and hence not representative of any actual user. You provided a different way of looking at and using personas, though, that may encourage me to incorporate them into my work.

  22. Hi Andrew

    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!

  23. Is it worth adding a comment five months after an article publishes? Oh, what the hell:

    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.

  24. I definately agree with your points and like the article. However, I ask everyone who talks about and posts about personas the same thing… why don’t you show the community what good documentation for sharing and such looks like? What are the most effective visual communication tools for personas as we leverage them and encourage our business partners to leverage them / understand their value as well?

  25. When you use a snapshot personal to personalize the primary user, but also include the characteristics from Lucy Lockwood ‘s user profile, you also display the primary users goals, tech skills, current product usage and so on.

    See Lucy’s article: Users, Roles, and Personas

    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.

Comments are closed.