Designers should always know their users, as deeply as they can. Are personas the right thing to do?
Personally i never understood the logic behind using personas to convince people about your users. They would make sense only if you model them on actual users and get under the skin of them. However the emphasis put on documenting and presenting these personas is not helping much. This is especially true if your personas are not really completely based on a thorough understanding of your users. This article by Andrew Hilton, which appears on Boxes and Arrows , i think hits the nail on the head. Quoting Andrew Hilton:
Personas and the Role of Design Documentation
How it’s less about deliverables, and more about design.
by Andrew Hinton on 2008/02/26 | [18 Comments]
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.
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.
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.
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.
