This is an excerpt from “UX Storytellers”:http://uxstorytellers.blogspot.com. If you enjoy it, consider getting the kindle edition of UX Storytellers – Connecting the Dots with all the stories!

Here’s something I believe in: stories are what make us human. Opposable thumbs? Other animals have those. Ability to use tools? Ditto. Even language is not exclusive to human beings.

From my amateur reading of science, the story behind our stories goes something like this: the human brain evolved with an uncanny knack to recognize and create patterns; and through some strange twist of natural selection, gradually over millions of years, our brains started turning the incredible power of that pattern-making machinery on ourselves, until we became self-aware.

Aware of ourselves—our own faces, bodies, journeys, homes, children, tools, and everything else around us. Over eons, we went from being creatures that lived in each moment as it came and went, to protagonists in our own myths. Everything in our midst became the material for making stories, strands of moments woven into tapestries that we call things like “nation”, “family,” “love” or “discovery.”

And “design.” Because design is, ultimately, a story we make. And designing is an act of weaving a new story into an existing fabric in such a way that it makes it stronger, better, or at least more interesting, and hopefully more delightful.

An Origin Story

My identity as an information architect happened accidentally, and gradually. I just kept doing things I liked, that people were willing to pay me for, until I woke up one day and realized I had a career. And the things I liked doing were invariably surrounded by people’s stories.

One of the earliest jobs I had out of college (after trying my hand at carpet cleaning, waiting tables and telemarketing) was as an office manager in a medical office. It was 1990, and this office of five or six providers was running entirely on a phone, a copier and an electric typewriter. No computer in sight. Every bill, insurance claim, or patient report had to be typed anew … as if the 80s had never happened. I talked the owner into getting a computer and a database management package—a sort of Erector set for database application design that I’d seen at a Mac user group a year before—so I could make the office more efficient.

It would’ve been pretty easy to create a quick application with a minimal user interface, if I were the only one using it. But the owner also had a couple of people helping in the office part-time who needed to use the system too—people who had never even used a computer before. Did I mention this was 1990?

So I had a challenge: how to make it work so that total computer newbies could use it? It was frustrating, fascinating, and probably the single most important experience of my career, because it was a crucible for acknowledging the importance of understanding the user.

To understand the people who were to use the application, I had to talk to them, get a sense of what they’d done before and what sort of forms they had used in the past. What sorts of technology? What terminology was going to make sense for them? How do they tend to learn—by written instruction or hands-on activity, by rote or through improvisation? I learned these things by watching and conversing. Eventually I had enough of a sense of those “users” that I had a full story in my head about how they came to the experience of this particular application, in this particular place.

I wasn’t conscious of this at the time; and I was working completely by intuition. I would’ve done a better job if I’d had the experience, methods and tools I’ve picked up since. But looking back, the experience itself has become a story I tell myself when I need a rudder to remind me of my direction as a designer so that, even when I have nothing else to go on, if I just watch, listen and absorb the stories of the people for whom I’m designing, my design will generally head in the right direction.

An Architecture Story

Much later, about ten years ago, I was working at a web design agency, and our client was an organization that acted as a sort of confederation of research scientists, universities and technology corporations. The organization funneled research money from “investor” companies to the scientists and their students in the universities, and in return the companies received “pre-competitive” research and dibs on some of the brightest graduates.

Their website had evolved like so many in those days—having started from a few linked documents, it had grown by the addition of ad-hoc sections and content created in response to member requests and complaints, until it had become a horribly unwieldy mass of links and text. We had been called in to clean it up and organize it. That sounded straightforward enough. But when we started interviewing its users, we found people who were unhappy with the organization and its community in general—scientists who had become more entrenched in their own sub-disciplines, and divisions between those managing the community and those merely dwelling there. Not to mention the natural enmity between academics and business leaders.

We realized that the web site had become a visible instantiation of that discord: a messy tangle of priorities in tension. A new information architecture would mean more than just making things more “findable.” It meant trying to make a digital place that structurally encouraged mutual understanding. In essence, a more hospitable online home for people with different backgrounds, priorities and personalities. It was a chance to create a system of linked contexts—an information architecture—that could help to heal a professional community, and in turn strengthen the organization founded to support it.

That project provided an insight that has forever shaped how I understand the practice of information architecture: the web isn’t just a collection of linked content, it’s a habitat. And the structures of habitable digital places have to be informed by the stories of their inhabitants.

A Survival Story

Much more recently, I had the opportunity to work with a non-profit organization whose mission was to educate people about breast cancer, as well as provide an online forum for them to share and learn from one another. When interviewing the site’s users, it soon became clear how important these people’s stories were to them. They would tell the tale of their cancer, or the cancer of a loved one, and in each case the story was one of interrupted expectation—a major change of direction in what they assumed to be the storyline of their lives.
I learned that this website was merely one thread in a great swath of fabric that the site would never, ultimately, touch. But the site was most valuable to these people when it supported the other threads, buttressed them, added texture where it was needed, especially when it helped fill in the gaps of their stories: How did I get cancer? What do my test results mean? What treatment should I choose? What can I eat when getting chemo? How do I tell my children?

They wanted information, certainly. Articles full of facts and helpful explanations. And the site did that very well by translating medical research and jargon into information people could use. But even more than the packaged articles of information, so many people wanted—needed—to share their stories with others, and find other stories that mirrored their own. The most valuable learning these people discovered tended to be what they found in the forum conversations, because it wasn’t merely clinical, sterile fact, but knowledge emerging organically from the personal stories, rich in context, written by other people like them.

One woman in particular lived on an island in the Caribbean, and had to fly to the mainland for treatment. There were no support groups around her home, and few friends or family. But she found a community on this website; one that would cheer her on when she was going to be away for tests, console her or help her research alternatives if the news was bad, and celebrate when news was good. She made a couple of very close friends through the site, and carried on relationships with them even after her cancer had been beaten into submission.

Here were stories that had taken hard detours, but had found each other in the wilderness and had become intertwined, strengthening one another on the new, unexpected journey.

This work, more than any other I’d done before, taught me that stories aren’t merely an extra layer we add to binary logic and raw data. In fact, it’s reversed—the stories are the foundations of our lives, and the data, the information, is the artificial abstraction. Information is just the dusty mirror we use to reflect upon ourselves, merely a tool for self-awareness.

It was through listening to the whole stories as they were told by these digital inhabitants that I learned about their needs, behaviors and goals. A survey might have given me hard data I could’ve turned into pie charts and histograms, but it would’ve been out of context, no matter how authoritative in a board room.

And it was in hearing their stories that I recognized, no matter how great my work or the work of our design team might be, we would only be bit players in these people’s lives. Each of them happens to be the protagonist in their own drama, with its own soundtrack, scenery, rising and falling action, rhyme and rhythm. What we made had to fit the contours of their lives, their emotional states, and their conversations with doctors and loved ones.

The Moral of the Story

Design has to be humble and respectful to the presence of the user’s story, because it’s the only one that person has. Stories can’t be broken down into logical parts and reconstituted without losing precious context and background. Even though breaking the story down into parts is often necessary for technological design, the story lives only if we serve as witness to the whole person, with a memory of his or her story as it came from that person’s mouth, in that person’s actions.

Keeping the story alive keeps the whole idea of the person alive. Whether we use “personas” or “scenarios” or task analysis or systems thinking, the ultimate aim should be to listen to, understand and remember the stories, precisely because the stories are the beating heart of why we’re designing anything at all.

So, now, when I’m working on more mundane projects that don’t touch people in quite the same way as some of the others I’ve done, I still try to remember that even for the most everyday task, something I design still has to take into account the experience of the whole person using the product of my work. That, after all, is what we should mean when we say “user experience”—that we seek first to listen to, observe and understand the experience of the people for whom we design. We honor them in what we make, when we honor their stories.

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.

References:

• Alan Cooper, “The Origin of Personas”:http://www.cooper.com/insights/journal_of_design/articles/the_origin_of_personas_1.html
• Jason Fried, “Ask 37 Signals: Personas?”:http://www.37signals.com/svn/posts/690-ask-37signals-personas
• Antonella Pavese, “Get real: How to design for the life of others?”:http://www.antonellapavese.com/archive/2007/04/249/
• Dan Saffer, “Charmr: How we got involved”:http://www.adaptivepath.com/blog/2007/08/14/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?”:http://www.peterme.com/?p=624
• Joshua Porter, “Personas and the advantage of designing for yourself”:http://bokardo.com/archives/personas-and-the-advantage-of-designing-for-yourself/ and “Personas as tools”:http://bokardo.com/archives/personas-as-tools/
• Jared Spool, “Crappy personas vs. robust personas”:http://www.uie.com/brainsparks/2007/11/14/crappy-personas-vs-robust-personas/ and “Personas are NOT a document”:http://www.uie.com/brainsparks/2008/01/24/personas-are-not-a-document/
• Steve Portigal, “Persona Non Grata”:http://interactions.acm.org/content/?p=262, interactions, January/February 2008

In practice, outcomes indicate that designing with any persona is better than with no personas, even if the personas used are entirely fictitious. Better yet, however, are personas that are based on real user data. Reports and case studies that support this approach typically offer examples incorporating data into personas from customer service call centers, user surveys and interviews. It’s nice work if you can get it, but not all design projects have all (or even any!) of these rich and varied user data sources available.

However, more and more sites are now collecting web analytic data using vendor solutions or free options such as Google Analytics. Web analytics provides a rich source of user data, unique among the forms of user data that are used to evaluate websites, in that it represents the users in their native habitat of use. Despite some drawbacks to using web analytics that are inherent to the technology and data collection methods, the information it provides can be very useful for informing design.

Google Analytics is readily accessible and offers great service for the price, so for the sake of example, the methods described here will refer to specific reports in Google Analytics. Any web analytics solution will provide basic reporting similar to Google Analytics, give or take a few reports, so using a different tool will just require you to determine which reports will provide data equivalent to the reports mentioned here.

To illustrate the process, an example persona design scenario is included in the description for each of the five steps:

Kate is an independent web design contractor who is redesigning the website of a nonprofit professional theater company. She has hardly any budget, plenty of content, and many audiences to consider. The theater’s website fills numerous functions: it advertises the current and upcoming plays for patrons; provides patrons information about ticketing and the live theater experience; announces auditions; specifies playwright manuscript and design portfolio requirements for theater professionals; recruits theater intern staff; serves as the central repository of collected theater history in the form of past play archives and press releases; advertises classes and outreach activities; and attempts to develop a donor base as well. As she gathers requirements, Kate decides to use the theater’s new Google Analytics account as a data source for building personas.

Step One: Collect Data

After Google Analytics has been installed on a site, you must wait for data to accumulate. Sometimes you will have the good fortune to start a project that has already been collecting data for months or years, but when this isn’t the case, try to get as much data as you can before extracting the reports you will use to build personas. Ideally, you want to have enough data for reporting to have statistical power, but not all sites generate this level of traffic. As a rule of thumb, less than two weeks of data is not sufficient for any meaningful analysis. One to three months of the most recent data is much more appropriate.

If it is reasonable, try to set up two profiles to filter on new and returning visitors. While some Google Analytics reports do allow segmentation, profile filtering on new versus returning visitor status gives you the best access to the full array of reports for each visitor segment. If this setup can be arranged early in data collection, then you can later draw on a profile that contains only new visitors to determine the characteristics of your personas who are new visitors, and likewise for returning visitors.

Kate has been given administrator privileges in the theater’s Google Analytics account for the duration of her contract. The theater has just one profile that includes all site traffic, so she starts off by making two new profiles with filters to include new visitors in one profile and returning visitors in the other. Kate knows that she needs a decent sample of site data, so she monitors the profiles weekly to make sure that the data is accumulating. She starts designing her personas using the existing Google Analytics profile (all visitors), and checks back later on the custom profiles to see if the segmented data can provide any new insights to add to her personas.

Step Two: Determine How Many Personas to Use

Next, determine how many personas to use–generally no less than three and rarely more than seven or eight. This gives you the number of blank slates across which to proportionately distribute the user characteristics that you extract from Google Analytics reports. If there are four personas, each will be assigned the characteristics of 25% of the site audience in each report; if five personas, each represents 20% of the site audience. Despite the fact that you’re working with statistics, you don’t have to be exacting in proportionately representing user segments; sometimes it is very important, for business reasons, to strongly represent a small user segment.

After thinking carefully about the many functions that the site has to fill, Kate looks at the Top Content report in Google Analytics to see what pages get the most traffic. She notices that most of the top pages are related to current shows, tickets and directions, and decides that she will have at least one persona represent a first-time patron who plans to travel from out of town. The other pages that are popular include the “About Us,” “People,” and “Classes” pages; “Auditions” is a little further down the page, but well above “Support Us.” Kate determines that she will create another persona to represent people interested in joining the theater company. Kate knows that fund development is important to the theater, but it doesn’t appear to be all that important to the website audience, so she decides to create another patron persona who has attended several plays and is interested in becoming a donor. She feels that these three roles can represent the audience the theater is most interested in reaching, and starts creating a persona document for each of them. She names her personas: Regina is the first-time out-of-town patron, Monica is the would-be theater participant, and Rex is the returning patron.

Step Three: Gather Your Reports

After allowing some data to accumulate, the next step is to acquire the Google Analytics reports, whether you’re interacting directly with the application yourself or someone else is providing you with reports. If you are not the person extracting data, make sure that you receive the PDF exports of reports, as these contain summary data that is not present in some of the other export formats. Whether or not you have profiles that are filtered on new versus returning visitor segments, you will be interested in the same handful of reports:

• Visitors Overview Report. In one convenient dashboard-style screen, you can get the percentage of “new visits,” or visits by new visitors, and a snapshot of other visitor characteristics.
• Browsers and OS Report. While you can look at browsers and operating systems separately in other individual reports, it usually makes more sense to look at them in combination in the Browsers and OS Report. Typically only a handful of browser and operating system combinations are required to represent well over 90% of the site’s visitors.
• Map Overlay Report. To use this report, which provides a great deal of detail on the geographic origins of site visits, you will need to do just a little bit of math. Divide the number of visits from the top country or region (whichever is of greater use to you) by the total number of visits to get the percentage of visits from that geographical area. This allows you to determine the proportions of domestic and international visits. For the visits from your country, you will want to drill down to the city level and select a few cities from the top ranks of the list, keeping in mind that big cities will statistically generate more traffic than small ones. For your international visitors, choose from the top cities in the countries that bring the most visits.
• Keywords Report. This report shows the queries that bring users to your site. When you look at the search engine query terms, ask yourself, “What are our users looking for? What type of language do they use when searches bring them to our site?” This gives you a starting point to think about user motivations and goals.
• Referring Sites Report. Like the Keywords Report, the Referring Sites Report gives you an opportunity to look for answers to questions like, “Where do our users come from? Are they reaching our site from search engines, other sites, or just appearing directly with no referrer, as returning visitors are more likely to do?”

If you have the segmented profiles set up, extract the same reports from both of these profiles, and get the Visitors Overview report from an unfiltered profile.

Kate starts looking for report data to build her personas. She has already generated user goals for her 3 personas, but the goals are pretty general, so she hopes to find more specific characteristics that are based on the real user population. Kate consults the Visitors Overview report and find that about 75% of the site’s visits in the last month were from new visitors; she decides that the Regina and Monica personas will be new visitors to the site and quickly brainstorms a few questions that she thinks they might have, based on their goals, that motivate their site visits. The last persona, Rex, will be a returning visitor.

Kate knows that the overwhelming majority of patrons are local because it is a regional theater company. She checks the Map Overlay report and sees that at the state level, about half of the visitors come from Michigan, where the theater is located. She decides that Monica comes from another state, and picks New York because it’s in second place behind her state, and because of the level of activity of the theater community in New York City. Kate drills down to view the traffic from Michigan, and chooses the top city for Rex’s home–the city is near the theater, so this makes intuitive sense. For Regina, who is planning to travel a little further, she selects the #4 city, which is about an hour away, and is a much bigger city. The visitors from that city have longer visits and a lower bounce rate, so she feels these characteristics would match well with Regina’s goal of planning an out-of-town visit to the theater. Coming from that city, she will also want to have dinner and stay the night at a local bed-and-breakfast, so Kate jots down these additional goals for Regina.

Since two of her personas are new visitors, Kate looks up the Traffic Sources Overlay and then the Referring Sites and Keywords reports. There’s a lot of search engine referral traffic, and some strong referrers among regional event listings sites. She decides that Regina got to the site from an event listings site that refers a lot of traffic, and that Monica arrived from a Google search on the phrase, “auditions in Michigan.” Kate thinks that a logical reason Monica would be searching for auditions in Michigan is because she’s planning to move there from New York, so Kate adds this detail to Monica’s persona.

Step Four: Fill in the Blanks

The next step is to “fill in the blanks” from the report data. Make a template for each persona, and first fill in whether they are a new or returning visitor. If you have segmented profiles on new versus returning visitor status, draw the remaining characteristics of your new visitors evenly from the new visitors profile, and likewise for the returning visitors. When you have distributed the other statistics (browser, operating system, and geographical location) among your persona templates, review them against the unfiltered “all visitors” profile for a reality check to make sure you have not unintentionally over-represented a user characteristic, which is one hazard of using segmented data. If you have no preconceptions about user goals, you can distribute the report characteristics randomly at this point, as there is not necessarily much meaningful interplay between the statistics for new/returning status, geographic location, and browser/OS. Alternately, using a goal-oriented approach as in the example, you can select persona characteristics from the user data that make sense with the goals you have established.

Kate took a goal-oriented approach to building her personas, so she has already assigned the report data to the personas. She builds her normal persona description template with the notes she made while looking at reports and adds OS and browsers based on the Google Analytics report to each of them. Kate then starts drilling down into the Google Analytics reports’ segmentation to add more detail. She clicks on Rex’s city in the Map Overlay to check the average visit length, bounce rate, and number of pageviews in the visit, which she uses to help her think about which pages Rex would be looking at, given his goals and those averages. Visits from Regina’s city are a little longer, so Kate considers what pages might show up, and checks the event listings site that referred Regina’s visit to find out what Regina might already know before visiting the theater’s site. Kate also checks on the referrers and keywords for visits from NYC and verifies that they contain some phrases similar to the one she chose for Monica.

Step Five: Bring the Personas to Life

The fifth and final step is to breathe life into these rough skeletons of personas. This is the familiar practice of generating the rest of the fictitious biography of the user, the detailed picture of who that person is and what motivates her or him, and so on. Let your creativity take over and build off the initial characteristics from the web analytics data to create a coherent persona. For example, the assigned browsers and operating systems should guide the determination of the computer makes and models that your personas use. Use the new or returning visitor status to assign the personas a level of comfort with using your site and their motivations for the site visits. The geographic location determined from the user data can help generate appropriate user goals and challenges, as well as occupations and hobbies, which may differ for domestic and international users. The reports on Keywords and Referring Sites offer insight on visitors’ interests and motivations, albeit slightly abstracted, and are a good starter for writing usage scenarios.

Kate spends some more time fleshing out her personas, and eventually decides that she needs more information about Rex, the returning patron and would-be donor. She asks the theater for some information from their patron database about how often regular patrons from Rex’s city visit the theater. Kate also interviews the company’s Development Director to gain more perspective on the characteristics of the theater’s existing donors from the local area. After learning more about the types of donors that the theater attracts and the general giving patterns they have, Kate feels that Rex is a good representation of the kind of potential donor who would visit the theater’s website repeatedly, and adds in some additional details based on her interview with the Development Director.

If you have other sources of user data, this is a great time to work it in. Survey data can often provide useful demographics that web analytics cannot, like users’ age, sex, and education level, for example. Free answers from surveys, interviews and focus groups are great sources of inspiration for filling in the details that make personas come to life. The Google Analytics Keywords report can sometimes provide the very questions that bring users to your site–and where better to answer them than in the design process?

Even when there is relatively little user data available to aid in the process of persona development, leveraging the resources at hand creates a stronger design tool. The 5-step process presented here aims to provide a starting point for developing personas using web analytic user data, rather than relying solely on assumption or imagination. An evidence-based approach like this one can lend structure and credibility to using personas and scenarios in the design process. At the same time, user data and statistics must be creatively synthesized to produce a useful representation, and imagination is always required to transform a user profile into a persona.

You’ve tried it all. User personas as posters, ala Alan Cooper, hanging on the office walls. User personas as cardboard cutouts, sitting at the conference table with you and your client. User personas as glossy deliverables. As paper mâché projects. As collages, comics, mood boards, Word documents, lists, charts, and just regular conversations.

Through all your attempts to bring user personas into your project, one thing remains consistent: user personas are hard to get right. And even if you get them right, they’re even more difficult to integrate into your day-to-day process.

Steve Mulder, user persona aficionado, has some suggestions. A whole book of them, in fact. That’s why Boxes and Arrows needed to interview him after getting a preview of his new book, The User is Always Right, late last year. Steve’s been kind enough to talk with us and to provide us with a free sample chapter below.

Liz Danzico: Congratulations on your book. What is The User Is Always Right, and, well, is it true?

Steve Mulder: This book was born out of the sinking feeling that, despite all the constant preaching about knowing your users, too many websites are created and grown without keeping users in mind. More companies are doing user research than ever before, but they’re challenged with making the results of that research understandable and actionable. Enter personas, which are generating more and more buzz.

But what are the various approaches to creating personas? How do I actually interview and survey users? How do I segment users and turn the segments into realistic personas? How do I use personas for directing overall business strategy, scoping features and content, and guiding information architecture, content, and design? The intent of this book is to give practical advice and direction on creating and using personas, and also to challenge all of us to bring personas to the next level.

So, is the user always right?

Yes, philosophically. Successful companies recognize that putting users at the center of decision-making is almost always a good idea. But taken literally, the book’s title is also a lovely, overstated attention-grabber. Let’s face it, users often can’t tell you the right direction for the website. But buried in their goals, behaviors, and attitudes (both stated and unstated) is everything you need to discover the right path. That’s why good user research isn’t just about listening to what users say.

So it sounds like analyzing research—not just plain listening to what users say—takes a certain kind of background and training. Is that true, or can anyone conduct this kind of research?

Sure, anyone can conduct this kind of research provided you don’t care whether the output is useful or not. Okay, maybe that’s harsh.

As our work as information architects, designers, marketers, or insert-your-favorite-title-here gets more sophisticated, so, too, do our methodologies. Talking to a dozen users and making critical business decisions based solely on that qualitative research just doesn’t cut it within some organizations. Increasingly, we need to raise the bar and invoke proven tools from other disciplines, such as statistical analysis techniques that enable us to generate persona segmentation based on quantitative research. We need to incorporate data on not only what users say (in a survey, for example) but also what they do (log files and search logs). All of this can inform the creation of personas that represent a much more accurate and useful portrait of users.

Raising the bar means bringing in specialists more often, or training ourselves in new specialties. But honestly, isn’t that what we love most: pushing ourselves in new directions?

Indeed. But, as you say in the book, “pushing ourselves” means playing nicely with others in the company—others in departments that may not cooperate or throw up roadblocks. You point out, “Increasingly, companies are realizing that their Web sites need to be a cornerstone of their marketing, sales, and servicing efforts.” Can we leverage these departments with their new outlook on research for tools and techniques?

Absolutely, though I’d describe it as “collaborating” with them rather than “leveraging” them. Running a business based on actionable knowledge about users requires understanding those users throughout their complete lifecycle with an organization. Thus, all customer touchpoints within a company (from sales and marketing to user experience to customer service) must come together to create a shared vision of who the users are and how to best serve them. Personas that are more rigorous and that are communicated in the language of business are more likely to bring these different groups together and bring their strengths to the table.

I’d love to talk more about the rigor or fidelity of personas. In the book, you go into great detail on how to show the right personal information in personas. Can you describe the process of turning your research into a reality?

As you saw in the book, I believe that personas are only as good as they are actionable, and that means creating realistic details that will actually inform decision making. If I say that Francis the First-Time Home Buyer loves Billy Idol, that’s an interesting detail that makes her persona more realistic, but it doesn’t help me make critical decisions about the real estate site I’m working on. On the other hand, if I say Francis is embarrassed by her ignorance of real estate and unlikely to ask friends for advice, that’s helpful information for deciding what content the site could offer and how that content should be provided.

With personas, the right kinds of details matter, and they typically involve goals, behaviors, and attitudes.

When you’re unable to talk to real people to gather research (and you give us your blessing in your book to do so!), where do you look for inspiration for creating them?

Let me first say that talking with real people is always better than not doing so. I don’t believe it’s ever a waste of time to do primary research with users. And it doesn’t take much time or effort to set up a few one-on-one interviews with typical users.

However, when even that kind of limited research is impossible, personas based on no research are better than no personas at all. At a minimum, personas force everyone to agree on and apply a shared vision of who you’re targeting and what they need, and that’s a very good thing. When creating personas in this way, involve colleagues in your organization who have direct contact with customers, such as those in sales or customer service. Take advantage of internal knowledge that already exists, then look externally at research by companies such as Forrester Research. These can be great sources of insight for brainstorming which goals, behaviors, and attitudes might be most effective for defining your personas.

I was surprised to see that you recommend using very specific photos to represent the personas. Isn’t a more general photo better? Isn’t that what Scott McCloud taught us?

Ahh, but remember that in Understanding Comics, McCloud points out that generalized sketches work well in comics because they better enable us to see ourselves in the comic. With personas, however, the whole point is to see real people as our users and not focus on ourselves. Choosing very specific photos forces us outside of the habit of thinking about ourselves. Suddenly there’s a very real person staring back at us with specific goals, behaviors, and attitudes that we must address.

Some of the examples in your book are spectacular in that they reveal details of deliverables that are often hidden behind proprietary walls. Of particular interest was the way you wove personas into the process of prioritizing features. Did extreme programming have any influence on this tool? Bringing “user stories” into their feature prioritization is a standard part of that process.

Actually, no. The tools I show in the book were simply a natural extension of what many of us already do. We talk about things like scenario-based design and use cases, but we seldom make the connections explicitly between the user research we do and the decision-making tools we use. At Molecular, we spend a lot of time drawing these connections, so it’s clear to our clients that decisions we make about features, IA, content, and design are all tied back to our knowledge about the real people we serve. Making personas a living part of the entire process is at least as important as creating effective personas to begin with, so we embed personas in our deliverables as much as we can.

Can you talk about a time where you weren’t able to make personas part of the process despite your best efforts? Perhaps there are even times when integrating personas is not useful.

I remember a time when my team presented personas to a client using cardboard cutouts and a little role-playing, only to find that this company’s culture frowned on anything remotely touchy-feely. They wanted hard data, and we foolishly didn’t take the time to understand our audience before presenting personas to them. On that project, we continued to use personas, but because our initial presentation left a bad taste in everyone’s mouth, the personas simply weren’t as effective in guiding decision making. As you can imagine, we didn’t repeat that mistake.

I was excited to see you start a book site to supplement and support the book. What are your plans for the site going forward?

The blog is intended to continue the conversation. A book is a snapshot frozen in time, but of course personas continue to evolve as a useful tool for managing websites. So my site tracks the latest news and opinions about personas, and I hope it becomes a useful resource for the community.

Did you use personas to create and guide the content for your book? How applicable are these techniques for other media?

Yes, I sketched out a few personas for the book, and found them very helpful for guiding not only what I wanted to cover, but also how to approach each topic. One persona was very much based on a client that I worked closely with, but I’ll never reveal that person’s true identity!

I absolutely believe that personas are valuable across many different domains. Whether you’re designing tax forms, toasters, or retirement accounts, taking time to describe who your users are and what they need can always be helpful for creating a product that will best serve them.

What’s next? Are you excited about using real stories and people to guide design? Are there changes coming in the way we use personas in the process?

More and more, businesses are letting real users have a tangible impact on decision-making, and I find the results exciting. My favorite current example is the way Starwood Hotels has used Second Life, that crazy virtual environment everyone is talking about, to create a large, detailed 3D model of a new chain of hotels it’s creating. In this virtual environment, users can walk through the hotel and give feedback on everything from the overall architecture to the fabrics. Starwood gains valuable feedback for improving its product before actual construction begins, and users get to contribute in a very real way.

The whole point of personas is to make users an active part of the process of running your business. Virtual or not, personas keep our eyes focused on the people who matter most: the customers we serve and who send us the business results that we so richly deserve.

Download Chapter 3, The User Is Always Right (PDF)

Most user-centered design (UCD) companies create personas (profiles of representative users) to guide their designs. To do UCD, you need to get the “U” in focus right from the start. So you’ve got your persona set all neatly defined and documented. Now what? How can you ensure the persona isn’t “just another deliverable?”

It’s in The Method
You may have heard of ’”method acting,” and how Robert DeNiro spent several months on the streets of Manhattan in a cab to prepare for his role in the movie Taxi Driver. He did this to understand the life of a taxi driver, so for movie-goers, the character felt realistic. He didn’t get advice from the drivers on how to act the role, he simply observed and eventually “became” a taxi driver, enabling him to empathize and see the world from their unique perspective.

Method acting is a technique in which actors try to replicate the emotional conditions under which a character operates, in an effort to create a life-like, realistic performance. “The Method” typically refers to the practice of actors drawing on their own emotions, memories, and experiences to influence their portrayals of characters.

Your persona is your “character sketch.” For software development projects, it may include information about the persona’s demographics, attitude, goals, environment, and how he or she will interact with your software in the context of the day. More advanced personas will also include detailed descriptions of activities or scenarios—these become the scripts for your persona to follow.

I figure the typical persona profile has just enough ingredients for our own version of “The Method.”

“The Method” was popularized by Lee Strasberg at The Actors Studio and the Group Theatre in New York City in the 1940s and 1950s. It was derived from the Stanislavski System, after Konstantin Stanislavski, who pioneered similar ideas in his quest for “theatrical truth.”

Strasberg’s students included quite a few of America’s most famous actors of the 20th century, including Paul Newman, Al Pacino, and James Dean.

Method acting combines a careful consideration of the psychological motives of the character and some sort of personal identification with and possibly the reproduction of the character’s emotional state in a realistic way. The best way to gain this understanding is to spend time with the people you’ve identified in the user requirement brainstorm. At the very least try to imagine being that person, then being that person in the act of using the software or system you’re designing.

Those trained by Strasberg often tried to experience all sensations as the character would and often used personal experience on stage to identify with the emotional life of the character and portray it.

Stella Adler, an acting coach whose fame was cemented by the success of her students Marlon Brando and Robert DeNiro, broke with Strasberg and developed another form of Method acting. Her technique is founded in the idea that one must not use memories from their own past to conjure up emotion, but rather use circumstances from their imagination. She also emphasized, like Sanford Meisner, the all-importance of “action” within the theater. She often preached “we are what we do, not what we say.”

Sound familiar? Those of us working in the user experience field often comment, “it’s what users do, not what they say.”

Putting The Method to practice
The following are some of my techniques for method acting with personas. This can be done with a team of one (you), or a team of many, depending on how many personas you have and how many people are on your project team:

* Your project team is your troupe of actors.

* In larger teams, your lead designer becomes the director, and the other project team members are the actors.

* The primary persona is the character sketch for your lead actor (if you have more than one primary persona you’ll need several leading—or possibly “supporting”—actors). Because I work in small teams of 2-5 people, the director and lead actor role are usually given to the lead designer (the person who’ll call the shots for the design of your software, website, intranet, or device).

* Assign roles for the secondary personas to other members of your team—those not so involved in the core design process. You can call on these people as you need them to do a “reality check” on your designs.

* It’s the responsibility of the actors to “become” the personas. They should read the persona profile as a starting point and if possible meet with and observe users represented by the persona to get inside the head of their assigned persona.

* At your design meetings, the actors consider how decisions will affect their particular character. Questions for the persona can be directed straight to the actor. This process can become fun and enable better teamwork, depending on how enthusiastically your actors embrace The Method.

* You can expect both good and bad actors, but The Method gives the personas life, rather than keeping them locked away on paper. A bad actor is still better than a hole in your plot. (In software design, a hole in your plot is when the user experience breaks because a personas requirements have been overlooked.)

* Over time, your actors should get to know their persona profiles so well that acting becomes second nature. That means they become a user advocate—not as an outsider, but an insider.

Method acting is just one technique to better enable user-centered design and is not intended to replace observational usability testing, but it can (and should) work in unison. For each observational user test, your actors will gain even more insights to the real world and can refine their method.

You can’t beat real customers for creating an authentic user experience, but then again, actors do a pretty good job most of the time!

References
This article borrows some material from Wikipedia, Method acting.

As most of us know by now, customer personas and scenarios are vehicles for helping an organization continuously keep their customers in their line of sight. Traditional segmentation identifies and categorizes a current or potential audience based upon common characteristics, including demographics, attitudes, behavior, transactions, frequency of interaction, spend, and more. They are discovered by “doing the math,” which may include data aggregation, cluster analysis, factor analysis, and other statistical methods applied to large sample sets. And then segments are given catchy names like Savvy Skeptics, Active Balancers, Indulgent Nutritionist, or Trade-Uppers. When done right, segments are statistically derived from the analysis and synthesis of quantitative data and are a solid foundation for customer understanding.

We create personas to build upon that platform by bringing the individuals within those segments to life. These are prototypical, but fundamentally real, stories of the multidimensional lives of specific customers. Of course they can also be about employees, partners, competitive customers, the press, and others, but for simplicity and consistency, let’s call them customers. These are specific customers with names and faces, but they also have an underlying implicit business agenda-that is they may be “the most profitable customer three years from now” or “the customer that we want to align with our brand,” or “the customer that shops for a product online and then purchases it in the store.” Their stories include topics such as demographics and psychographics, but also include mindsets, motivations, perceptions, personal quotes, actions, desires, measurable attributes and more. Their stories are crafted from real-world business intelligence, the sources of which may range from online surveys to channel-specific transactional data to descriptions given by in-store sales associates.

This report discusses how the Arc Worldwide’s Experience Planning group uses storytelling and multidimensional customer-based stories to provide relevance, direction, and resonance in today’s business planning landscape.

We feel, as do many of our professional peers, that they are a vital tool to provide guidance to and inform decision-making within an organization. Quite often, they are equally useful as a long-term, internal organizational tool. In our design and development culture and process, they are more than just a step in the product, application, or service development process. We have seen them deeply effect the planning of numerous organizations including those involved in product development, service development and delivery, marketing, communications, and customer service, to name a few. The decisions that customer personas and scenarios inform may include new product and service pursuits, details of product and service strategy, marketing strategies, customer relationship management frameworks, media placement and more. Personas and scenarios tell honest stories that are sculpted from diverse and comprehensive sets of data. These stories place the customer and their wants, needs, emotions, and behaviors at the center of a roadmap that charts current and future businesses success.

Within our personas and scenarios, the people and their stories are not arbitrary. They are stories of the lives of our client’s current and potential customers, and they serve as comprehensive guides to how our clients should interact with those customers, in the moment or over a lifetime, to profit their business. Three years ago, personas and scenarios were “a process step” in our iterative, user-centered development process, whereas today they are the platform upon which many of our insights are communicated, and our solutions are modeled. Over the past few years, they have risen in importance and become a primary tool for communicating data analysis, strategic business frameworks, new product and service concepts, and cross-channel brand experiences. We gauge this positive change by the frequency by which they are requested by internal team members and our clients, as well their prolific use by both.

The customer at the center
The best product and application design strategies are created when a team first gains direct understanding of the people who will use the end product-those people that will actually interact with applications, products, and environments to achieve desired goals-and then shapes strategies and solutions around those individuals (or groups or companies). An understanding of the customer is at the heart of every good business. That understanding should inform the company’s product and service development, its marketing strategy, its sales strategy, its mergers and acquisitions, its positioning within the marketplace, and even its organizational structure.

All business decisions impact customers. Customers have real lives, real challenges, and real desires. Businesses have day-to-day and long-term goals of revenue generation, profit margin, market penetration, market, and brand value. We use customer observation, empathy, measurement, and ultimately understanding and predictability to spark new ideas and provide comfort and/or reassurance with strategic and tactical business decisions. The ROI of business decisions ought to be a reflection of satisfying both business and customer desires in mutually beneficial ways. Customer-centric discussions, strategy and results continue to increase their prevalence in the boardrooms. Personas are a clear, comprehensive, human way to tell those stories.

Most importantly, identify who your customers are
Segmentation may identify who your customers are, but companies must also work to prioritize those segments. Through the combination of quantitative and qualitative methods that explore attitudes, behaviors, expectations, and trends, we are able to recognize patterns in people’s thoughts, feelings, and actions. From those patterns, we are able to identify their potential value to the company, their spending trends over time, and their potential to connect with a brand messages for many years. Our experience has been that, by adding these dimensions or attributes to the personas and scenarios, they can be used to inform change within various parts of a business including product planning, budget allocation, marketing strategy, customer support and more. Some examples of these attributes could include a brand campaign with media messaging strategy or a planned change in the company’s enterprise-wide development platform.

Brands must stay flexible in their ability to shape their meaning and offering to appeal to the right customers at the right time. This requires brands to have a conceptual breadth and dynamic nature such that they can configure themselves according to a customer’s needs as that customer interacts with diverse channels or touch-points. Industries such as retail, financial services, automotive, consumer packaged goods, and travel and leisure are continuously testing new brand messages and launching new brands to better fit with changing customers, market shifts, and social and cultural trends.

An evolution of personas and scenarios
The use of personas and scenarios is shifting to reflect the diversity of customers’ lives within the greater context of today’s business landscape. This human-centered process of planning and informing decision-making is being embraced by companies large and small. Every week we read articles about the way personas are used within an organization and their impact, from retail chains redesigning stores to reflect customer behaviors, to hotel chains designing services for different types of travelers, to financial service offerings that are simultaneously tailored to your lifestyle and specific life stage. On the surface, these are customer stories that illustrate mindsets, emotions, needs, tasks, and channel usage. They are communicated through narrative stories, task flows, charts of data, imagery, functional lists, and often personal quotes and resonant anecdotes. Below the surface, they are the stories of a company-how that company wants to be perceived, the experiences they want to enable, who they want to serve, and what constitutes their success. Brands, product and service offerings, customer service and cross-channel experiences demand to be crafted through a lens of whimsy, insight, pressures, perception, and unwavering consumer expectations.

Personas and scenarios can effectively tell stories of change over time. They can tell stories of what brand experiences customers have today, what we would like their experiences to be tomorrow, and “hey, what if?” These scenarios are not guarantees, but well-informed predictions of the future business-customer interaction and relationships.

Beginning a few years ago and continuing into the future, the use of personas and scenarios within our Experience Planning group and global marketing solutions company will continue to broaden in dimension, usefulness, and most importantly, business impact. The storytelling techniques that we use to communicate and predict the thoughts, emotions, and behaviors of customers as they experience and interact with a company are useful in a breadth of business contexts. The following is a list of shifts or evolutions that we have experienced in our application of personas and scenarios to the business landscape. They continue to grow in complexity, vision, and usefulness in various business contexts.

The storytelling of business change

Product-focused > Business-focused
In the past, personas and scenarios have been used by single product, application or platform groups. Today, beyond product development groups, they have found their way into marketing, customer service, human resources, information technology, and sales. Many of our clients use them to introduce new employees to “their customers.” From poster-sized wall hangings to coffee mugs, these stories solidify an organization’s focus on the right customers. Part of the persona development process includes the design and development of an implementation and usage plan as well as a measurement and validation schema. We often refer to them as “living stories” that change and evolve in response to the dynamics of the business, the marketplace patterns of behavior.

User task-oriented > Customer lifecycle-oriented
Personas and scenarios are often used to illustrate or test a set of tasks that a user will attempt to accomplish using a system or product. They illustrate a user’s key interactions over time, showing how the relationship between a customer and a brand evolve over time via different and evolving interactive experiences and an ongoing brand dialogue. They illustrate the stories of a single individual (or family) and the life stages and evolution that they will experience.

Software development tool > Strategy development tool
Personas and scenarios are commonly used as a software development tool to describe the user-system interactive application design. They serve this purpose sufficiently, but also encompass a framework to tell strategic product, audience, market, and business strategy stories, telling the stories of individuals and how their lives will change over a few years. In parallel, they tell the stories of how the company, its products, services and philosophy might also evolve over those same few years. For instance, our strategic personas often paint a picture of how a brand will shift in public perception and/or marketing position over time.

Tactical > Strategic
Personas can exist at feature levels, product levels, division levels, company levels, market levels, and cultural levels. They can tell stories of new business models, new paradigms of service and of cultural shifts. They can be used to depict a “day-in-the-life” of this year, next year, and five years from now. They can tell multiple stories that span a customer’s lifetime relationship with a company. They bring to life product opportunities that are realized in the cracks of market shifts and emerging cultural changes.

Use case tool > Business case tool
Traditional use cases, most used within software development, are detailed stories of user-system interactions and responses. We can apply these same principles to defining and communicating business cases. Scenarios tell stories of what happens when a specific button is pushed or when a valuable customer calls Customer Service. They tell stories of how an interface is used to find a local store and they tell stories about what happens when that customer walks into a retail store.

Single channel > Multi-channel
Most often, personas are applied to software or website interactions. Fewer, but still many, tell stories of interactions with kiosks, portals, mobile apps, IVRs and customer support personnel. We often tell stories that incorporate brand experiences with many channels, each with the intent to move the customer closer to a transaction. The principles and techniques that are used to tell the stories of multiple interactive channels can be equally effective when applied to retail environment design and direct marketing strategies.

Individual > Interconnected and community-based
Personas are still most often about a single individual. From customer observation, we recognize that purchase decisions often involve more than one individual, including a spouse, a friend, a family member, or a “significant influencer,” as we like to say (like a grandmother, clergy, or a coach). These relationships are critical to how customers perceive, react, and experience a brand. Beyond co-decision-makers and influencers are the issues of a customer community. The use and the role of consumer-generated content and brand evangelists (extreme advocates) must be clearly defined and meticulously planned. Online forums, blogs, owner’s clubs, and streaming interviews are just a few of the data sources that emerge on the web and via traditional publishing every few seconds. You should become aware of these sources, understand their impact and anticipate how customers will use them to inform their behaviors. Make those interactions part of your personas and scenarios.

New product concept > New categories of products
As a new product concept is brought to life, the development team often realizes that potential variations or expansions to the idea exist that can be applied to other products or industries. For example, as we designed a service look-up tool for the web, we realized that this was a platform and interactive tool that could be applied to many related place-based services. Scenarios tell stories of variations on or a deviation of an existing business model, or something entirely new. They tell stories of uncertainties that are grounded in the behavior and emotions of individuals, shifts in markets, and changing cultural values. Most business landscapes are mature, so you should push on them a bit with stories of unique, but obvious, variations that stem from user understanding. We often find it useful to include characteristics or behaviors in a persona that are disruptive or anomalies to the norm.

Anecdotal success > Success through measured business impact
Throughout the years, we have not seen much focus on the definition of how a feature or product is going to be proven successful. In most cases, we have prioritized a segment, and we know its value. All businesses have success measures which might include customer acquisition, revenue generation, share of wallet, brand perception, transaction through a channel, reduced operating costs, customer satisfaction, or something else. Sure, the personal stories of individuals resonate, but the stories of actual, predicted and measurable ROI are what let business executives sleep soundly at night. You should clearly define the measurable business attributes and goals that exist within the story of each persona. Design a continuous measurement, iteration, and validation strategy that is both tactical and strategic.

Associated with a product > Associated with multiple divisions of a company
Often, our persona actors are introduced to a company and they become part of the internal fabric of product and service planning. Customers don’t care if they’re interacting with a specific division of a company; what they do care about is the ease of interaction and quality of service and overall experience. Tell fact-based stories of how customers should effortlessly cross department and divisional boundaries. You’ll know you’ve done this well when someone recognizes and identifies by name a persona actor that you created for another division within the company two years ago.

Customer-focused > Customer service-focused
Personas are usually about a current or potential customer. We have found them to be a useful tool to model the dialogue and interactions of a customer and various Customer Service Representatives (CSRs). “A caller has requested to speak to an operator through the IVR via this path. This is their issue and, in most cases, the answer can found in one of these sections of the site.” What tools does the CSR use to resolve the customer’s issue? How should a CSR gently encourage and lead a caller to solely use the web next time? We typically spend one to two days at a Customer Service Center extracting a wealth of customer knowledge that exists, as well as directly listening to the dialogue of customer calls. Customer Service Centers are often the arms that embrace many current and future customers and carry them through the purchase, service, or ownership experience. The one-to-one customer relationships that are formed by a concierge or personal assistant are often the most impactful point of influencing customer perception and behavior. These individuals and their numerous daily interactions are the hub of customer empathy and understanding within a company. They deserve the same consideration and level of planning and strategy as any other marketing or sales channel.

Application-focused > Message, channel, frequency and media-focused
Arc Worldwide is part of a larger holding company and network of advertising agencies, channel marketers, and media planners. Agency Planners have traditionally provided the data and strategy that informs message development. Agency Creatives have crafted the messages and visual work used to present those messages to the public. Media Planners and Buyers create the strategies of when and where those messages should be delivered. Our personas and scenarios often complement, guide, and bring to life the work that these different groups do. The allocation of marketing and advertising budgets is quickly shifting from a past of majority allocation to mass media, to a future of majority allocation to one-to-one, multi-channel interactions. Personas can be used to show the predictive effects of more intelligent messaging, media, and channel experiences.

Static, one-time artifact > Living, dynamically shifting stories
Traditionally, personas have been created for one-time use, to inform the application design of a single product. They are created once and then used a few reports and presentations. On occasion, an internal set of personas is updated as financial quarters or even years pass, but this is the exception. We encounter many companies that have already “gone down the persona development path,” sometimes more than once, and didn’t realize any value from that activity. Our experience has been that personas are most useful and valuable when an organization declares that satisfying their needs and tasks is an operational imperative.

Imagine a future framework in which customer personas and scenarios are dynamically generated from live data. These stories can be accessed via an online portal by various internal and external marketing, sales, and product development teams. This online tool is a sophisticated information repository with an underlying construct of three layers-a data layer, a rules layer, and a presentation layer. Many companies have access to rich volumes of data from sales, marketing, and customer data sources. The data layer comprises feeds from various sources including survey data, transaction data, loyalty data, value measurements and more. The rules layer organizes the data itself and the data in relation to other data sources. The data comes to life in the presentation layer as it is converted into visual stories in the form of frameworks, diagrams, matrices, multi-dimensional personas, and experience models. These are rich and relevant stories about your target audience and the issues of their lives that may affect your business. Because of the dynamic nature of the data, these personas are living stories that change daily.

We aggregate this real-time data within this portal and bring it to life as visualizations of customers, channel usage, advertising and marketing effectiveness, and sales. From these snapshots come real-time planning insights and opportunities. The purpose of this portal is to provide an at-a-glance status of the profile of your audience and the various channels with which they interact with your brand. This portal uses various techniques of information visualization to demonstrate the effectiveness of these channels in accomplishing specific business and marketing goals. Aggregate views of current public opinion and press coverage add an additional dimension to the story. Also built into this tool is an application for scheduling and executing research studies with various representative customer groups. Tools and information are uniquely combined and delivered to you via a custom dashboard.

What better way to drive business strategies, including messaging, product and services offered, innovation explorations, media design, interactive dialogues, store design and much more? Our belief is that through the proper use of advanced technologies, every large brand could have a dynamic customer, market, and cultural reporting platform at the heart of its business decision-making engine.

Personas and scenarios applied
Over the past two years, the Arc Worldwide Experience Planning group has written dozens of personas and scenarios that span numerous verticals and diverse business models, goals, and strategies. Together with talented visual and information designers, we create compositions that juxtapose user, business, organization, marketplace, and product details in a way that clearly communicates connections, actionable insights, and opportunities.

Some of the industries and related business problems to which these methods have been applied include:

• Defining long-term ebusiness strategy based on how the company-patient relationship will evolve with each disease state (in the context of budget approval for multiple large-scale projects over a three-year period).
• Validating and bringing market data-driven segments to life (to demonstrate future reliance on and interaction with the financial service company’s emerging global intranet).
• Architect multi-channel user experiences and define effective customer purchase processes for a range of high revenue-generating products (to optimize category specific, multi-channel shopping processes).
• Planning and launching a new home entertainment product category, product, service, and brand; (telling stories of the customer relationship continuum from initial consideration, through service purchase, the out-of-box experience, installation, usage and customer service).
• Understanding how regional travelers plan trips and what channels and mediums they use to plan. (also clearly defined were the goals, considerations, and the types of information that are critical to their success and peace of mind).
• Increase brand awareness and penetration of a consumer package good in specific European markets (provide a framework to generate new ideas to increase product loyalty).
• Understand the interconnections and relationships between a union and its members.
• Tell stories of regional and local difference and opportunities around military recruiting (tied to emotions, values, behaviors, and the effectiveness of various messaging and media).

Whatever the industry, we craft user personas and scenarios to communicate clear, digestible plans and strategies that are embraced as useful and engaging throughout organizations. As mentioned, in many cases we introduce organizations to their customers for the first time. And in other cases, the introductions are broader, including a strategy for shifting market position or measuring business success.

Conclusion and recommendations
Amazon, Home Depot, Delta Airlines, Sears, Discover, Morgan Stanley, Microsoft, Toyota and many others have integrated customer personas and scenarios into their strategic planning process. They provide flexibility, adaptability and a real-world usefulness that many business strategy and forecasting techniques do not. Whether your client’s target audience is students, sales associates, doctors, online shoppers, future soldiers, insurance agents, financial advisors, or business partners, we recommend that you use personas and scenarios to capture their essence, apply it to business issues, and tell stories of future business success.

Arc Worldwide Experience Planners ensure that Arc’s products and services are informed and inspired by the attitudes and behaviors of customers while appropriate and innovative in supporting business objectives. With a holistic and relentless focus on creating engaging customer experiences that meet business needs, Experience Planners are highly skilled in activities frequently associated with behavioral market research, business process analysis, usability engineering, information architecture, and interaction design. Employing an iterative, user-centered development approach, Experience Planners create the blueprint for products and services that are at least relevant and efficient, at most delightful, loyalty-inciting, and life-altering. They invent and improve experiences across interactive media and real-world spaces: from in-store kiosks to websites; from personalization infrastructures to interactive games and mobile UIs. Experience Planning is part of Arc’s larger global Insights & Analytics group.

Parrish Hanna is VP, Director of Experience Planning at Arc Worldwide. Previously, Parrish served as President of HannaHodge, a groundbreaking user experience firm that he co-founded in 1998. For over a decade, he has spent the better part of each week planning better experiences for humans and refining the process to do so. He considers himself fortunate to have worked with brilliant people toward making the products of enlightened companies like Cadillac, Ford, Vanguard, Disney, Samsung, IBM, Sears, Intel, and Xerox easy and pleasurable to use. Parrish has a B.A. in Industrial Design, an M.A. in Human-Computer Interaction, and a handful of patents and industry awards. He’s a regular publisher and speaker on issues related to experience design.

“Alan Cooper popularized personas as a valuable design tool, but many people who adopted them failed to take into account the context of Cooper’s practice, which had fairly specific needs.”

How can something that feels so right be so wrong? Personas ought to be one of the defining techniques in user-focused design. Lots of professionals create them, yet too often the personas end up being too vague to guide a product’s focus. They often lack the detail to be useful in guiding low-level design trade-offs. And, as typically done, personas have been too narrowly focused. They often aren’t helpful in identifying the information a user needs or creates. Nor do they have much to say about the sensory and emotional aspects of user experience–the sorts of factors that cause consumers to lust after products like Apple’s iPod.

As a result, personas have unfortunately become more of a check-off item than a useful tool, and many personas get put on the shelf once they are written. So how did we get here?

Alan Cooper popularized personas as a valuable design tool, but many people who adopted them failed to take into account the context of Cooper’s practice, which had fairly specific needs. Cooper’s company most often dealt with enterprise clients who hadn’t yet bought into the value of user experience. As a consultant, he had a strong need to persuade internal development teams to pay attention to users, so, not surprisingly, he emphasized both the narrative and empathy-building aspects of personas.

Cooper’s goals for personas were to:

• Allow the development team to live and breathe the user’s world.
• Allow the team to filter out personal quirks and focus on motivations and behaviors typical of a broad range of users, while still relating to users as individuals.

These are good goals, but incomplete. Compounding the problem was that Cooper’s seminal The Inmates Are Running the Asylum talked at length about why personas were important, but didn’t provide many details about how create them. So people improvised, often with unsatisfying results.

My own frustrations with personas came as I tried to apply them to a different context. While Cooper mostly worked with enterprise clients, with developers and managers who were reluctant to consider users, I’ve usually had a hand in building the sites I design, even as an outside developer and consultant. Likewise, Cooper’s clients typically were developing internal applications where efficiency was main goal, so it’s not surprising that his approach was task-focused. But as I’ve argued previously, other types of projects are predominantly information-oriented and immersion-oriented–or some mix among the three.

Much of my own work has been on consumer-facing websites and interactive products where functionality was only part of the focus. When I was developing movie promotion sites, the studios obviously hoped the websites would “put butts in seats.” But people don’t visit movie promotion sites to find out where the film is playing. Nor–if they live outside Hollywood–to find out the name of the second assistant camera operator. People go to movie promotion websites to get a taste of the film.

The design challenges simply weren’t the same as Cooper’s. I needed a tool not just for creating empathy and filtering out quirks, but one that could:

• Guide strategic decisions about a product’s focus,
• Enable better tactical-level design decisions, and
• Help make inevitable design trade-offs.

In a sense, trying to build personas with sufficient actionable detail is similar to the problem novelists and screenwriters face when trying to understand motivations, making sure plots are clear. Good editors constantly pose questions to the writer to force them to reach that clarity. My toolkit is built on the efforts of others from a wide variety of fields, from HCI to branding to filmmaking. To help develop more “three-dimensional” personas, the toolkit contains more than a dozen pages of questions about:

• Biographic, geographic, demographic, psychographic background information
• The business’ relationship to the persona
• The persona’s relationship to product and business
• The persona’s specific goals, needs and attitudes
• The persona’s specific knowledge and proficiencies
• The context of usage
• Interaction, information, sensory, emotional aspects of the user experience
• Accessibility issues
• Relationships among personas

It also includes techniques for using personas to prioritize user interface components, as well as useful definitions for providing a common language to describe this prioritization.

My focus was on a tool for design rather than a tool for persuasion, so the questions– and resulting answers–are far too detailed for those outside the design team. But they’re necessary to enable a designer to not only make better tactical level decisions, but also to think more strategically about the product’s focus and help drive the product’s definition. The toolkit covers a wide variety of situations, so you should use the questions that are most appropriate to the context of your project. Similarly, not all the questions need to be–or should be–answered at once. The toolkit is designed to be used iteratively with questions being filled in over time as they become relevant to the design issues at hand. (However, it’s still a good idea at the start of the project, or at least at the start of each project phase, to identify the questions you think you’ll want to answer, so that you can begin gathering the necessary information.)

Let’s quickly review some of the basics of persona creation. When building personas, the first challenge is finding the information to build them. Obviously, it’s preferable to talk to and observe the users themselves, but that’s not always possible. In my opinion, any information is generally better than no information, and there are inevitably other sources of information. You can talk to user surrogates, such as domain experts, trainers, or immediate supervisors. There are “informants” who know about the users, such as people in the marketing, sales or customer support departments. For example, I once designed an extranet for a company’s board of directors. I couldn’t get access to the board, but their support staff was able to tell me all I needed about the directors’ behavior and computer skills. There are other indirect sources as well, such as manuals (especially those with notes written in them), site logs, customer feedback forms, surveys, etc. But one indirect source to be wary of is “ersatz” users–most commonly upper-level executives who think they understand their customers far more than they typically do.

After gathering information, I prioritize personas into the following types:

• Focal–These are the primary users who are the product’s target.
• Secondary–They also use the product and we’ll satisfy them when we can. But their needs can be sacrificed to meet the needs of focal users.
• Unimportant–Infrequent, unauthorized, or otherwise low-priority users.
• Affected–They don’t use the product but are affected by it. For example, one member of the family may do the research when buying a car, but the others–who are usually involved in the decision–will be affected by that person’s work.
• Exclusionary–We’re not designing for them. Period.
• Stakeholders–I’ve often found it useful to create mini-personas that represent their interests and involvement. These can range from advertisers to senior management to industry influencers to regulatory agencies. Stakeholders may–or may not–be something you want to put into writing. But stakeholder personas are often useful to formally create because they provide a good way of ensuring stakeholder issues get discussed openly. If you’re including a feature solely because it will get press coverage, it’s better to acknowledge this in the design process than to pretend that it’s there to satisfy a user need.

You probably want no more than a dozen personas, with at least one focal persona. But if there are more than three focal personas, you’re trying to do too much, and you need to subdivide the product or interface–for example, separating the “user’s” user interface from the “administrator’s” user interface. This is probably familiar ground. But I mention it because it’s critical to get team consensus on the relative priority of each persona in order to later prioritize specific design decisions.

What is your persona’s background?
At the broadest level, persona development starts with the biographic background, including:

• Geographic profile. Where do your personas live and work? What’s it like there? Why can this matter? It’s worth noting that some of the earliest non-U.S. internet adopters were the Scandinavian countries, Australia, and New Zealand. While geography may not be destiny, I suspect the rapid adoption was in part due to the long dark winters of the former and the geographical isolation of the latter.
• Demographic profile, such as age, gender, family size, income, occupation, education, etc., information that’s available from the marketing team. It’s frequently less useful for understanding the behavioral aspects of your persona, but can useful in rounding out a persona’s character. Politically, it’s a good way to get Marketing to buy in.
• Psychographics, which include social class, lifestyle traits and motivations, personality characteristics and attitudes. These can be important in understanding the proper tone and voice to give a product. For example, the PRIZM system developed by Claritas–based on the idea that people with similar tastes tend to live in the same neighborhoods–is eerily accurate in describing people’s likely interests based on their ZIP code (You can try it yourself here.) I’ve also found it to be a useful tool for adding in non-essential details that make personas feel more realistic.

What’s the relationship between persona, product and business?
Some of the key strategic questions are around the persona’s relationship with–and value to–the business.

• Is the persona a customer, an employee, a partner? A company will likely want to communicate different messages for its external sites than its intranet. An extranet may display different content for a preferred vendor than for other vendors. Similarly, a website might restrict certain information to only paying customers, while leaving other content available to all users.
• Conversely, what sort of relationship does your persona have with your product or business? Are they a heavy user or a non-user? If you’re trying to acquire customers from a competing product, then you need to understand the people who aren’t using your product. What’s your persona’s attitude toward your product, your brand and your company? What kind of relationship would your persona like to have–but doesn’t have now? Enterprise applications are often like arranged marriages–employees use them not out of love, but because they’ve been told to do so. Linux users have an undying “hate affair” with all things Microsoft, and Tivo users will tell you that it changed their lives. Where’s the relationship headed? If you’re MTV, you’d best recognize that your brand relationship is a passing fling; in a few years, today’s viewers will be wearing Dockers and watching VH-1. In contrast, you’d have to pry their Macs out of the cold, dead hands of many users with a lifelong commitment to Apple.
• What’s the persona’s value to the business? More zealous advocates of user-centered design seem to think any user is valuable, but that simply isn’t true. The 80/20 rule was discovered by an economist’s extensive analysis of businesses that discovered 20 percent of customers did account to 80 percent of revenues. It can be useful to think about what percentage of overall users (or overall revenue) a persona represents. It may not the critical factor in a persona’s priority, but if nothing else prepares you to answer questions from the business side of the project.

What’s the context around the product’s usage?
Focusing on the product being offered, what are the specific goals, needs and attitudes surrounding the context in which your personas will use the product? Crown Equipment Corporation realized that even warehouse workers want to be “cool,” which was the inspiration for the stylish exterior of its Wave rolling ladder replacement. The product has been a hit. Not only did it create significant jumps in efficiency because it allows one person to do the job of two, but companies using it saw big increases in job satisfaction and morale.

After thinking about what your personas are trying to accomplish, then look at what specific knowledge and proficiencies your personas have related to achieving that goal. A safe rule of thumb is that most users never pass the “advanced beginner” stage of expertise–nor do they really want to. This question also applies to more fundamental issues than computer skills. For example, there’s a company that provided computer-based HR training (sexual harassment policies, etc.) to hotel maids. Not all the maids spoke English, nor were all of them literate in their native languages. Needless to say, their language skills had a significant affect on the design.

It’s useful to get specific about the context in which the persona is using your product. For example:

• When and where do users perform a task? With whom?
• What’s the surrounding environment? Global navigation positioning systems for sailing are used at any hour of the day or night, in any weather condition.
• Are there device constraints? For example, designing for a mobile phone.
• Are there confidentiality needs? Accuracy needs? Audit needs?
• What are the operational and/or safety risks? Designing a hospital billing system has big risks–but far smaller than designing the hospital’s pill-dispensing system.
• Is there assistance and training available? Many of us work on websites where training is impractical, but in designing an air traffic control system it may be preferable to prioritize other concerns over learnability, since the users will be formally trained in its use.
• Are there legal and/or regulatory restrictions? If you’ve ever worked in financial services or other regulatory industries, you know how much these issues can affect the design.

What does the interaction look like?
Now that we’ve looked at the context around your persona’s usage of the product, let’s take a close look at the interaction with the product itself. How frequently does the interaction take place? Is it on a regular basis? Is it continuous or interrupted? Is it so intense that it requires the persona’s full attention, or is one of several interactions that your persona is doing at once? How quickly must the persona act? How complex and how predictable is the action? Who’s driving the interaction–your personas or outside factors? If you’re designing an air traffic control system, the interactions are highly complex, but generally predictable. The controllers are the ones driving the interaction with the pilots, but it involves continuous high-intensity focus with split-second reactions for hours on end. That’s a little different than the interaction with your average website. Admittedly, these questions overlap with task analysis, but answering them for each persona can help identify important similarities and/or differences in behavior among your personas.

What information is involved?
Many interactions also involve information–something that traditional task analysis can overlook in its focus on actions. So the next step is to look specifically at the characteristics of the information that your persona needs and/or manipulates as part of the interaction with the product. For example, at one extreme are call centers, where the operators are listening and talking with customers, while simultaneously reading and typing on their computer screens. If you were designing the call center’s software, you’d want to think about the volume and complexity of the information being used, how it flows to and from the operators, and what level of detail is needed at what times.

What makes the user experience memorable?
While interaction and informational aspects of user experience can be analyzed logically, the sensory and immersive characteristics of a user experience are inherently more subjective–but no less important. Products can survive in the marketplace initially despite being crude, ugly or dangerous if they provide enough value. But over time, as competitors match quality, style becomes the differentiator. (Or price–but only one product can ever be the lowest-priced.) What’s the mood or feeling, style or genre that’s appealing to your persona? What’s appealing? What’s pleasurable? What’s memorable?

Geek Squad–a boutique high-end computer-support company–is the master of the memorable experience. Does its black-and-white “Geekmobiles” and Men In Black-meets-computer nerd schtick affect the actual technical troubleshooting skills of its services? Nope. Does it make an impression? You bet. So much so that the company amassed a celebrity client list and was subsequently acquired by Best Buy, who is now launching the service in all its stores.

The Geek Squad experience was no accident. It was consciously created to overcome people’s adverse reactions to arrogant tech support workers. Not surprisingly, brand researchers have paid much attention to the emotional aspects of an experience. One researcher argues that aspects of five major personality characteristics:

• Sincerity
• Excitement
• Competence
• Sophistication
• Ruggedness

account for roughly 90 percent of brand differentiation. Regardless of whether the list is as specifically effective as claimed, it is worth thinking about what personality your product conveys and whether it’s something that’s attractive to your personas.

Likewise, what is your personas’ perceived experience of using your product? Does the product convey:

• Sense of adventure?
• Feeling of independence?
• Sense of security?
• Sensuality?
• Confidence?
• Power?

Strengths in many of these areas are what prompt Harley-Davidson’s customers to literally brand themselves with tattoos and jackets–and what kept the company afloat during the 1970s when the motorcycles themselves suffered severe quality problems.

With this level of detail in your personas, it becomes far easier to prioritize them. The toolkit provides three approaches for doing so.

This approach seems to pose numerous questions–and it does. As I mentioned previously, you only need to answer the ones that are most relevant, and not all at once. But it’s the details that will make your personas powerful.

George Olsen is senior interaction designer for Yahoo! Search. He has done award-winning work for a variety of companies, from dotcom start-ups to Hollywood studios to Fortune 500 companies.

Spock: “The needs of the many outweigh the needs of the few.”

Kirk: “Or the one.”

–Star Trek II: Wrath of Khan

I recently had the pleasure of teaching a workshop on applying user-centered design methods to personal technology design in a European amusement park.

The workshop started out typically. We interviewed company management, mapped out the goals of the company, the context in which the project was being done and collected information about how people currently behaved in the park. We then identified several classes of users, created personas for them, and started creating scenarios using these personas.

Initially, the workshop progressed about as it would if we were going to be designing a piece of desktop software or a website, but the minute we started developing personas and scenarios, the unique nature of the park started to become clear. We first sketched out some personas, and that went fine. But once we began working with scenarios for a while, trying to create believable situations for these characters to behave in, we noticed something: all of our scenarios consisted of groups of personas interacting with the environment or with other groups of personas. That’s when we realized that individuals mostly don’t act alone in amusement parks. People rarely go alone and they don’t make decisions alone. Needs and desires are negotiated in a group, not expressed individually. People really fully embrace the experience only when they’re experiencing it with others. In this environment, individual personas and scenarios for them matter less than what happens to groups of people.

So we decided to see if we could make group personas. At first, there was some apprehension–what if the groups are so varied as to be impossible to characterize? But as soon as we started making them, only several different kinds of personas made sense and it became a straightforward extension of Alan Cooper’s original persona technique. Here’s how we did it.

Individual descriptions
We had started by describing individual personas, so we had the building blocks of groups, and we used those personas as the basis of our subsequent work. Those personas were based on several visitor categories that we defined based on the park’s operators’ knowledge of their audience–the statistics they had and their personal experience with the park:

• Teenagers
• Young adults
• Pre-teens
• Young parents
• Grandparents

We decided to leave the profiles broad, rather than going into detailed persona building, and described each group along some criteria appropriate to the problems the park was trying to solve. Young parents, for example were described thus:

• Age: 25-35
• Children: 2
• Budget: $75-100 per day (in the park, not including tickets) per parent
• Technology: cell phone (6-24 months old), digital camera, video camera, computer at home, internet connectivity in the office
• Desires: have fun with kids, let kids run around in safe place
• Needs: to have fun, too; place to change diapers; place to sit down; to buy food/drink

Of course, this only scratches the surface of how young parents in an amusement park can be described–we could have defined different criteria based on gender, culture (this park has sizable populations of visitors from as far as Poland), etc.–but time was limited and it was enough to get us started creating group personas.

Rough outlines
Before fleshing out the group personas, we decided to make some rough outlines of the clusters of people one might find in the park. Based on what we had heard from the park staff and additional interviews we conducted with a couple of friends-of-friends who had visited the park as tourists, we came up with four different groups to focus on, and tried to give them distinctive names:

• The Teen Posse
• Young Parents, Young Kids
• The Extended Family
• College-age Friends

We also defined some axes along which we could define the group. Again, we chose to pick out those qualities that we felt would be valuable in answering the park’s questions, rather than trying to describe every detail. Thus, the “Young Parents, Young Kids” general description looked like this:

• Number of people in group: 5
• People in group: 2 adults, 2 kids ages 3-10, grandparent
• Time spent in park per day: 6 hours
• Number of days visiting park: 2
• Season: August

The level of detail at this stage needed to emphasize the group as a whole and make it different from the other groups, without burdening it (and ourselves) with descriptions that didn’t affect the end experience. We didn’t describe the individual members of the group, and included as few constraining specifics as possible. Such details and idiosyncrasies would come in the persona, which we did next.

Iterative persona creation
We developed each persona in several passes, both to refine the persona until it had sufficient believability and because this was the first time any of us had developed group personas, so we naturally ended up over-describing certain aspects and under-describing others. The process was roughly as follows:

• a rough sketch, where we quickly outlined the persona, determining its composition and adding some defining details
• a detail brainstorm, where we added as many details as we could, even if they were silly, contradictory or redundant
• editing, where we cut out everything we thought was irrelevant to addressing the project focus, and clarified overlapping ideas
• preliminary scenario writing, during which we “exercised” the personas by walking them through some examples in which they interacted with the park and some of the design ideas on the table
• tuning, where we adjusted the personas based on what we had learned from the scenarios

After a couple of days of doing this for 2-3 hours per group persona, we had four fleshed-out group personas and some scenarios that we felt were typical examples of groups who visited the park and how they would behave. These we used to examine the problems the park was experiencing and our proposed solutions.

Example: The Ancona Family, a secondary persona
Note: this persona is significantly modified from what we developed in the workshop.

Back story
Luisa and Giorgio, a couple in their mid-30s, have decided that the family needs a vacation. It’s mid-August and they’re spending time with Luisa’s parents, Maria and Carlo, at their home outside of Rome. Mauricio and Laura, their children, are getting bored and cranky and clearly need a break from hanging out at the grandparents’ house. Giorgio suggests they spend a weekend at an amusement park with water rides before they go to Rimini for the traditional week on the beach. Maria, Luisa’s mother, will come along. She’s always willing to help out with the kids.

Demographics
Luisa and Giorgio are in their mid-30s. They live in Rome. They’ve been married for five years. Giorgio is a mechanical engineer and Luisa is a full-time parent and also works part-time at her parents’ grocery store.

Mauricio and Laura are their 7- and 4-year-old children.

Maria is Luisa’s mother. She is in her late 50s. She lives outside of Rome with her husband, Carlo. They own a small grocery store, where Maria manages, in addition to being a full-time homemaker.

Technology use
The park was interested in developing wearable or portable technology for people to use as they’re being entertained, so we included a range of technologies in our description, rather than just focusing on computer and software experience, as we would have if this was a piece of software or a website.

Luisa and Giorgio have mobile phones. They’re very comfortable sending text messages, and typically send 3-5 to each other per day. Luisa sometimes uses hers to play video games and she texts one of her friends almost every day. Luisa’s phone is newer than Giorgio’s and has a camera.

They have a two-year-old computer at home, which Giorgio and Luisa use to send email (they have a dialup internet account) and which the kids use to play video games and watch DVDs.

Giorgio has a faster internet connection at his office.

They have a digital video camera with them, which Luisa bought for Giorgio for his last birthday.

Maria doesn’t have a mobile phone, but she’s comfortable using one.

Luisa and Giorgio have taught Mauricio how to call the emergency number on a mobile phone, but he’s otherwise not used one even though he understands in principle how they work.

Goals
Group goals are a negotiated combination of individual goals. In a family trip, most of the long-term goals are set by the parents, and most of the short-term goals are set by the kids.

Mauricio has one major goal: to ride the big roller coaster over and over again. He’s never been on one, but he knows about it. He’s also very interested in the dinosaur area.

Laura has never been to an amusement park before, so she doesn’t know what to expect, but her parents told her about the costumed mascots and water rides and she’s excited to see those.

Giorgio:

• Have fun with his kids
• Wants to use his new video camera
• Wants to ride the roller coaster

Luisa:

• Wants to spend time with Giorgio and her kids
• Wants to ride the ferris wheel

Maria:

• Talk to her daughter
• Spend time with her grandchildren

Combining these, we get a set of general goals:

• Ride the big roller coaster
• Avoid boredom
• Spend time together

Needs
In our example, goals are individual but they affect the whole group, whereas needs are mostly group-wide. This may be a product of our process, or it may point to a general case of how group personas work.

• Find each other
• Find the bathroom
• Be entertained while waiting in line
• Get food/water
• Rest for Maria, while kids are being entertained

Purchasing profile
Since selling stuff is a key amusement park revenue stream, we decided to do a short profile of what the group is likely to purchase throughout the day.

• Ice cream, bought by Maria, as a treat for the kids
• Soda in a theme cup, requested by Laura, bought by Giorgio
• Lunch for everyone, bought by Luisa and Giorgio
• Disposable camera bought by Luisa
• Sunscreen, bought by Luisa
• T-shirts for Mauricio and Laura, bought by Giorgio

Example: Ancona family scenarios
Having developed a general group persona, the next step was to develop some scenarios using the persona in order to test it and further refine it.

Day narrative
We began with a general narrative of what happens during the day. Here’s an abbreviated version of the first day:

6:00 AM: kids wake up
8:00 AM: breakfast at Maria and Carlo’s home
9:00 AM: family leaves for park
10:30 AM: arrive at hotel near park, check in
11:30 AM: leave for park
12:00 PM: arrive at park, buy tickets, go in, start getting oriented
12:30 PM: orientation chaos: where to go? what to do? Negotiation and prioritization.
12:45 PM: Giorgio and Mauricio head for roller coaster. Luisa, Laura and Maria start looking for a place where Maria can wait with Laura while Luisa joins her husband and son.
1:00 PM: Giorgio and Mauricio arrive, get in line.
1:15 PM: Luisa and Maria find picnic area where Maria can wait.
1:30 PM: Luisa joins Giorgio and Mauricio.
2:30 PM: Luisa, Giorgio and Mauricio get to the front of the line and ride the roller coaster. Everyone is very hungry.
2:45 PM: Group reunited, start looking for lunch.
3:00 PM: Lunch bought at stand near picnic area.
Etc.

Where are Giorgio and Laura?
Using this structure, we started thinking about technological solutions: what problems are encountered? How can the information technology we know the family has or has experience with affect the situation? How can the park benefit?

Business problem:
People complain of getting lost when trying to reunite when groups separate.

Scenario:
Laura really wanted to go on the water flume ride, but since everyone gets soaked while on it, the rest of the family doesn’t really want to go. Giorgio and Luisa agree that he’ll go, while she and Mauricio and Maria go to the ferris wheel. Since everyone gets soaked, Giorgio doesn’t want to take his mobile phone and leaves it with Luisa. Now, how will they meet up again? They don’t know how long the lines at the various rides are. How will they know when to meet? If the water ride line is as long as the roller coaster and the ferris wheel has no line, then Luisa, Maria and Mauricio may end up waiting hours for Giorgio and Laura to get back.

Potential solutions:

• Wait-time kiosks. If there are kiosks scattered around the park that tell people how long the lines at the rides are, then the family can estimate how long the whole process will take and pick a time and place to meet up again.
• RFID bracelets/ride check-in. Everyone gets a wrist bracelet when they buy their ticket. Assume that each bracelet has an RFID (radio frequency ID) tag in it and people’s IDs are linked
• Waterproof mobile phone bags. Watertight bags provided by the park for people waiting in line for water rides. These allow people to coordinate and communicate using the tools they’re familiar with.

Using the group persona, we were able to explore and evaluate how well these solutions worked, both for the Anconas and for the park. The low-tech solution, the bags, is cheap and requires the minimum investment by the park in new technology and by the Anconas in learning a new system, but it’s not without problems. What if Giorgio, who’s quite attached to his phone, doesn’t trust the bag?

What we learned
This exercise was incredibly helpful when we started designing technology to support people’s experience in the park.

Groups are not individuals, though they sometimes act like them.
As the persona is developed and as scenarios are written, the focus shifts from the individuals in a group to the group as a whole. The group is rarely treated as an entity identical to an individual, but it often behaves as one. So when the Anconas move around the park, they’re often moving as a group. Where they go may be heavily influenced by one person’s desires (Mauricio’s desire to ride the big coaster), but the decision is made collectively and they act as a group.

Group descriptions should have moderate detail, but not too much.
While it’s not necessary to describe either the group or its members in deep detail, some description is important. In fact, describing groups as groups is actually tough: we just don’t have that many axes along which we typically describe small groups: we can number the members and collect aggregate demographic information, but that’s about it. We had to invent a lot of the categories we used on the fly.

The design goal drives the persona description.
Remembering that this was an amusement park and that we were going to be designing ways in which the park could support and encourage the use of personal technology really helped focus the persona development process. It narrowed the directions we explored and how we spent our time fleshing out ideas. There were times when we’d go too far into describing the persona and clearly enjoying the storytelling aspect too much, which was fine and often useful, but then the design goal allowed us to edit what we had produced so that it was most relevant.

Imperfection is important.
We found we had a tendency to tell stories where everything goes right and technology saves the day and makes everyone happy. Though this made us feel good, it’s not realistic, and the exercise of examining where our ideas could fail, where they could be misunderstood and misused, was quite helpful.

This is a really useful tool for realistic idea generation.
When given a broad mandate, this technique allowed us to narrow the space of all possible uses of technology from what was merely possible to what seemed like it would be actually useful and valuable. It defined the space in which we could create innovative ideas and to understand where services that bridged technologies made sense and where they didn’t. It also allowed us to see the problems with some of the ideas.

Extending traditional techniques to groups is possible and valuable.
This was the first time I tried this technique. Frankly, I kind of invented it on the spot and my workshop participants ran with it, but the process of taking a known technique and stretching it to a new set of problems proved quite valuable, both in terms of helping us solve the problems we were tasked with and in terms of understanding what I know about individual personas.

Extending to other kinds of experience design.
So what does all of this amusement park stuff have to do with software and websites? It’s directly applicable to software that’s used by groups. Entertainment, education, and collaboration software is often used by two or more people simultaneously (and not in the sequential “I edit this, then I give it to you to edit” model, but simultaneously). It’s difficult to imagine teleconferencing software without thinking about two groups—one at either end of the connection—using it; sometimes these are groups of executives, sometimes they’re technical collaborators, sometimes they’re mixed. Each of these different groups has a different set of needs and expectations from the software, and each can be modeled as a group persona, rather than as individual users.

In the most general sense, as our tools become more social, as information processing and ubiquitous computing pervade our environment, so should our techniques to model their users. Group personas are a small and easy step.

Bibliography

Cooper, Alan. The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How To Restore the Sanity. Indianapolis, IN: Macmillan, 1999.

Cooper, Alan, et al, Newsletters on Personas.

Kuniavsky, Mike. Observing the User Experience: a Practitioner’s Guide to User Research. San Francisco, CA: Morgan Kaufmann, 2004.

Olsen, George, Persona Toolkit (.pdf), February, 2004.

Disney Trip Report Archive, 27 July, 2004.

Mike Kuniavsky is the author of Observing the User Experience: A
Practitioner’s Guide to User Research (Morgan Kaufmann), and has been
developing commercial websites since 1994. He is a founding partner of
Adaptive Path, one of the world’s premier user experience consulting
companies. Previous to co-founding Adaptive Path, Mike was the
interaction designer of HotBot, the award-winning search engine, and
creator of the Wired User Experience Laboratory, where he served as chief
investigator.

He is currently an independent consultant, focused on ubiquitous
computing and on the ways that such technology changes everyday objects
and experiences. His blog is www.orangecone.com.

At this time, Microsoft had just released Internet Explorer 5 (IE 5) for Windows and we were anxious to use its improved standards support and DHTML in our application to make the interface as whizbang as possible. By limiting our audience to IE 5, we decided we would be able to deliver the most robust application, one that was sure to impress potential users and customers. Later, we told ourselves, we’d go back and build out versions with support for Netscape and Macintosh. So we set to work building the coolest web application we could, taking full advantage of the latest wizardry in IE 5 for Windows. Development was chugging along when Alan Cooper’s “The Inmates Are Running the Asylum” was released and I picked it up. When I got to the chapter discussing the use of personas, I was intrigued. Though I was confident in our approach, creating personas sounded like a useful exercise and a way to confirm we were on track.

Discovering Personas

Cooper’s personas are simply pretend users of the system you’re building. You describe them, in a surprising amount of detail, and then design your system for them. Each cast of personas has at least one primary persona, the person who must be satisfied with the system you deliver. Since you can’t build everything for every persona (and you wouldn’t want to), the establishment of the primary persona is critical in focusing the team’s efforts effectively. Through the use of personas, the design process moves away from discussions that are often personal in nature (“I’d want it to work this way.”) or vague (“The users like to see all the options on the home page.”) . It becomes a series of questions and answers based on a concrete example from which the team works (“Mary, the primary persona, works from home via dialup four days a week, therefore downloading an Access database isn’t an option.”). In our case, the development of personas helped us recognize that the target audience we’d chosen, web development teams, wasn’t as homogenous as we first assumed. Not everyone who’s involved in web development is gaga for DHTML or CSS—some people on the team might not even know what those acronyms stand for, a simple fact we’d failed to consider up until this point.

Our team stopped working to discuss personas and Cooper’s approach and we agreed it sounded important enough to devote some time to it. As we sketched out our various personas (a project manager for a large company whose corporate standard was Netscape 3, a web designer who worked on a Mac, an independent consultant who worked from home), it became apparent we had made some bad assumptions. Not only were the personas not all like us—our personas wouldn’t even be able to use the system we were building for them! We’d been so blinded by our own self-interest we failed to realize we were building a useless team product. Sure, it would have been great as an example of what we hoped to build, impressive to any engineer or web developer, but a manager might not be able to access it. We were cutting ourselves off from the people who would most likely make the decision to use the tool—and no project team would signup for Pyra because an entire project team couldn’t use it.

We were a month away from releasing the beta version of Pyra at this point, but we knew what needed to happen. We had to go back and redo our application to work for Netscape and IE, for Windows and Macintosh, and in doing so, we needed to reevaluate our tool using our personas (specifically our primary persona) rather than ourselves or the mythical “user” to guide our decisions. So that’s what we did, pulling out all our beloved DHTML and remote scripting so our 37-year-old project manager persona could access the application from her home office in Seattle on a Saturday afternoon. Though the rework delayed our beta release by two months, it resulted in a tool our potential customers could use immediately.

Learning hard lessons
Through the process of developing personas, the mistakes we’d made became clear to us:

Mistake #1: We chose flashy technology over accessibility.
We allowed the geeky part of our personalities, with its lust for the newest and greatest ways of doing things, to overwhelm the decision-making process. Though there was a sense at the beginning that we needed to support other platforms, we let our desire to use the newest “toys” change the priority of doing so. This is a common mistake programmers and engineers make but one which can be avoided through the use of personas. Interestingly, when we redid Pyra based on our personas’ needs, we didn’t lose any of the previous functionality. We only changed how it was done, e.g., reverting to less elegant page reloads rather than DHTML client-side changes. The previous version had only been impressive to fellow geeks like ourselves, but we hadn’t realized that. More importantly, the essential quality of the tool was never lost, but by redoing it, it become available to many more people.

Mistake #2: We assumed users would be more impressed by a robust interface they couldn’t use than by a less elegant application that they could use.
Again, our technical hubris blinded us into thinking that potential customers would be impressed by how we built our functionality, not by what the underlying features were. We let our wants come between our product and our users.

Mistake #3: We thought we were the primary persona.
While we shared common goals with our some of our personas, and though one of the personas we developed was very similar to the members of our team, none of us were the primary persona. This crucial distinction between primary personas and secondary personas forced us to realize the interface we designed shouldn’t be driven by our wants or needs, even as members of a web development team. Defining a primary persona prevented us from releasing our original tool with its accessibility failures.

Less than a month after the beta release of Pyra, we released a second tool, Blogger. Though we didn’t create formal personas for Blogger users, the experience we gained by using personas infused our company’s approach to building web applications. Any time the word “user” was mentioned, questions flew: “What user? Who is she and what’s she trying to do?” Our work with personas increased our awareness of our audience and their varying skill levels and goals when using the application. The use of personas helped move all our discussions about the application, not only those related to the interface, away from the realm of vagaries and into tangible, actionable items. (“It should be easy to create a new blog.” “Easy? Easy for whom?” “It should take less than a minute to get started.” “It should take less than a minute for my grandmother to get started,” etc.) We developed a system of familiar, conversational personas on the fly, focusing on the primary persona without going through the formal process.

In retrospect, some of this sounds like common sense, and yet time and time again I find myself looking at an interface and making assumptions based on how I’d like it to work. Like a recovering substance abuser, it’s a constant challenge for me to refrain—I can always imagine that I’m the user. Even if your budget or timeline doesn’t allow for the development of formal personas, you can still benefit through the use of informal “conversational” personas, like we did while building Blogger. It takes discipline to break the old assumption habit but the more I use personas, the easier it becomes. I’ve carried the lessons I’ve learned through their development with me for the past three years to other projects and engagements; the use of personas resulted in a fundamental shift in the way I approach not only interface design but application architecture as a whole.

For more information:
Alan Cooper, The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. SAMS, 1999.

The way you communicate the personas and present your deliverables is key to ensuring consistency of vision. Without that consistency, you’ll spend far too much time arguing with your colleagues about who your users are rather than how to meet their needs. Let’s start with a review of what we know about personas, and why they are useful.

Personas are user archetypes created primarily to be design targets
Personas are almost always based on patterns and findings you gather during interviewing. You use them to prevent problems such as the “elastic user”—the user that morphs from grandmother, to John Doe, to your CEO, depending on the day. Having a stationary target in a non-stationary world is a first step to creating a holistic, useful and usable product.

As a first step to documenting your personas, make sure you’ve done the preliminary work. You created multiple personas, fleshed out to the same level of detail. For most projects, each persona has at least a first and last name, age, goals, background story, a telling quote, email address, job title and a photograph. Some projects may require more characteristics to highlight specific areas of importance

Depending on the project, you identify various persona characteristics or facets relevant to the design (more on this later). Finally, give each persona a designated status: primary, secondary, supplemental, negative, etc.

These designations help prioritize your design efforts. In later design stages, you will create scenarios for a design that satisfies mainly the needs of your primary. Status designation also helps to minimize feature creep; requests are easier to reject or incorporate when you’ve already decided who the product is and isn’t for (e.g., it shouldn’t be added if it is for your negative persona, if it is only for your secondary it can be hidden away from the primary areas).

Marlena, an interaction designer using personas
As an example, let’s watch Marlena go through the process of preparing and documenting personas at her company. Marlena is an interaction designer at DigitalMail, a provider of HTML email marketing software for managing customer relationships. Adam, also an interaction designer, is working closely with Marlena on designing the next version of DigitalMail’s flagship product, DigitalMail Reach.

Marlena and Adam have conducted interviews with marketing managers and assistants, webmasters, graphic designers, and sales professionals at companies that have already used or are likely to use Reach. After their research and a few intense whiteboard sessions, they identify patterns that help them flesh out their personas. Now Marlena and Adam have to check in with the heads of product management and engineering and with the CEO of DigitalMail before they can start designing for their personas.

Use structure to help others reach your conclusions
In order to get her co-workers on board, Marlena knows she needs to carefully manage their first impressions. Having had some experience sharing personas before, she knows she has to provide detailed written documentation for those who don’t attend the meeting and for later reference. All the design documents she will produce from this point forward will incorporate the personas to help focus the design

Marlena starts by documenting their research. She then creates about a page for each persona, including all the information mentioned above (name, goals, age, background story, etc.) except the persona’s designation. Instead, she uses the designation to order the persona pages with the primary being appearing on the first page of personas section.

After her personas section, she adds the persona designations and the reasoning behind the status designations. Marlena also adds a section with summary information (picture, goals, name) about each persona, so readers can compare and contrast the personas. Finally, she adds a page containing a diagram that shows how each persona is involved in using the product.

Depending on your project and research, you’ll uncover characteristics of your personas that are relevant to the design of the product. Each persona may have a different information—sharing need or a particular role in relation to the product (e.g. consumer, creator or approver of content).

Marlena and Adam discover a common process among their interviewees—marketing usually initiates the email campaign; the graphic designer creates the design and integrates the marketing copy; and the webmaster checks the HTML. At various points in the process, multiple people will use Reach for particular tasks. This is central to the design, therefore, Marlena creates a diagram that communicates this key distinction. She also mentions it in the narrative about each persona.

Marlena then creates her PowerPoint by simply summarizing her document. She structures the information in her presentation in the same order as her documentation, so her audience can follow the same process she followed and reach the same conclusions.

She’s found that audiences do not generally understand persona designations until she explains the entire persona set. Seeing them all on one page to compare goals and summary information is key, so the audience can be confident that all bases are covered. Marlena wants her personas to be representative of the actual patterns in her user population, and conveyed succinctly so they are useful.

Thanks to Marlena’s meticulous work habits and Adam’s presentation skills, the meeting with their executives goes well. With minor adjustments, management agreed that they should design for the primary persona while keeping in mind the needs of the secondaries. Everyone who is working on the next version of Reach will read the deliverables, and Marlena and Adam will give another presentation to a wider audience of team members. They also suggested to the executives that they start using the names of the personas instead of the word “user” to avoid miscommunications.

Marlena and Adam are satisfied, but they know there will be more challenges to understanding the personas as they begin to do more detailed work with coworkers, so they do some more documentation work.

Know, sell, use and help others use your personas
Four weeks later, after Marlena and Adam have reached some high-level conclusions about how the product will function, they schedule a meeting with key engineers to verify the feasibility of their design. They want engineering to know the skill sets needed to implement the design so that they can plan for additional hiring, skills development and resource allocation.

To provide quick reminders to colleagues who aren’t so versed in the personas, Marlena created a persona “placemat”—a laminated sheet that contains the same summary information and diagram found in the last two pages of her persona deliverable: the goals, names, and pictures. She easily created the placemat by tweaking what she already had in the persona document.

They start the meeting by reiterating the primary persona (Kathy, the marketing manager) as well as the secondaries (Charles, the graphic designer, and Patrick, the webmaster). Tom, an interface engineer, shows up 10 minutes late, just as Marlena is discussing the preview functionality she foresees needing.

Marlena: Kathy wants to preview the message in Outlook. If there are any potential compatibility problems she wants to know, but she really doesn’t care what they are. Patrick will want to do the same with Outlook and all the other major mail clients. He will also want to know specifically what the compatibility problems are and even tips on how to fix them if the product can’t just do it automatically.
Tom: Wait. Which one is Patrick again? And why won’t Kathy want to see what exactly is wrong and how to fix it?

Marlena knows she has about 15 seconds to explain who Patrick is and maybe 45 more seconds to explain why Kathy doesn’t want all that functionality before Tom and the other engineers get impatient. Marlena takes out a laminated persona placemat and hands one to Tom, then hands other copies to the rest of the attendees.

Marlena: Patrick is the 26-year old webmaster. He’s responsible for making sure the emails reach and are readable by all the recipients. On the placemat you’ll see two of his goals are “Be knowledgeable” and “Make sure code doesn’t break.”
Tom: (looking back and forth between the placemat and Marlena) Oh… right and why doesn’t Kathy care?
Marlena: Well, Kathy, our primary persona, is the marketing manager and she mainly cares about the message contents and design. She just wants to insure her marketing messages are conveyed. She is busy and depends on Patrick for technical concerns. If you turn over the placemat, you’ll see a process diagram showing that she barely previews. Patrick is mainly involved in the tail end of the process.
Tom: Oh, okay. Uhm, sorry for interrupting. Go on.

Marlena knew from experience that even though people may read (or skim) the documentation, they need quick reminders of the personas and the relevancy of their stories. After all, she and Adam spend their entire days thinking about what Kathy, Charles and Patrick want and how to give it to them. (In fact, Marlena hasn’t yet shared with Adam that she had a dream about Patrick the night before.)

Even though the placemats provide a good reminder, after this meeting, she and Adam realize they need to do more. They are going to create posters with pictures and summary information of the primary and secondaries and they will be hung around the office.

Marlena offered these other tips for documenting and sharing your personas:

• Tie your personas to your research, showing your audience that you’ve personified the patterns you’ve found because that makes sense for design.
• Less is more. Get to the heart of the persona.
• When presenting, talking about your personas, or referring to them in writing, communicate as though they are real people, people that you know. Express it like you are talking about a friend. Remember, you want your audience to like (though not necessarily agree with) the personas. There is little motivation to try to understand or design for people you hate.
• Reuse persona pictures often—people feel connected to them and remember faces easily.
• In your persona description, focus on their regular daily activities.
• Be creative in the ways you communicate them and use multiple methods—posters, t-shirts and sock puppets have been known to work—but don’t get too cute.
• Use good communication guidelines, for example make the primary persona picture largest.

Documenting personas keeps your design on track
Now that you have a better idea of how to document your personas, remember that documentation isn’t the point of your work. It is simply an important step on the way to designing and building better products. Also, what is described above is a cookie-cutter approach towards documenting your personas. Each project will have different documentation requirements to make different points, but the underlying principles stay the same. As a designer, it is up to you to determine how much persona detail is sufficient and how to set up the personas and their presentation so that you pre-empt confusion and questions. You also need to provide a quick way to familiarize newcomers to the persona set, and find ways for your colleagues and clients to keep focused on the personas throughout the project.

For More Information: “The Inmates Are Running the Asylum” By Alan Cooper “Perfecting your Personas,” Cooper Interaction Design By Kim Goodwin “Personas: Matching a Design to the Users’ Goals,” User Interface Engineering By Christine Perfetti Robert Reinman’s 1999 AIGA Conference presentation, “User Personas”

The ideas above were impressed upon Elan when he used to work for Cooper Interaction Design. These days he consults independently (though with other former Cooperistas) for companies that don’t have the liberty to screw up their products. When he’s not designing, he can be found playing volleyball, improvising or improvising as a volleyball (you try that sometime)….

]]>