The Story’s the Thing

by:   |  Posted on

This is an excerpt from “UX Storytellers”: 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.

Personas and the Role of Design Documentation

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

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

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

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

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

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

The Origin of Personas

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

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

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

I was writing a critical-path project management program that I called “PlanIt.” Early in the project, I interviewed about seven or eight colleagues and acquaintances who were likely candidates to use a project management program. In particular, I spoke at length with a woman named Kathy who worked at Carlick Advertising. Kathy’s job was called “traffic,” and it was her responsibility to assure that projects were staffed and staffers fully utilized. It seemed a classic project management task. Kathy was the basis for my first, primitive, persona.

In 1983, compared to what we use today, computers were very small, slow, and weak. It was normal for a large program the size of PlanIt to take an hour or more just to compile in its entirety. I usually performed a full compilation at least once a day around lunchtime. At the time I lived in Monterey California, near the classically beautiful Old Del Monte golf course. After eating, while my computer chugged away compiling the source code, I would walk the golf course. From my home near the ninth hole, I could traverse almost the entire course without attracting much attention from the clubhouse. During those walks I designed my program.

As I walked, I would engage myself in a dialogue, play-acting a project manager, loosely based on Kathy, requesting functions and behavior from my program. I often found myself deep in those dialogues, speaking aloud, and gesturing with my arms. Some of the golfers were taken aback by my unexpected presence and unusual behavior, but that didn’t bother me because I found that this play-acting technique was remarkably effective for cutting through complex design questions of functionality and interaction, allowing me to clearly see what was necessary and unnecessary and, more importantly, to differentiate between what was used frequently and what was needed only infrequently.

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

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

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

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

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

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

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

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

It’s not about the documents

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

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

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

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

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

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

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

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

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

2. Documentation as a substitute for physical production.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Playing the role

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

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

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

Antonella goes on:

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

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

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

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

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

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


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

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

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

Building a Data-Backed Persona

by:   |  Posted on

Incorporating the voice of the user into user experience design by using personas in the design process is no longer the latest and greatest new practice. Everyone is doing it these days, and with good reason. Using personas in the design process helps focus the design team’s attention and efforts on the needs and challenges of realistic users, which in turn helps the team develop a more usable finished design. While completely imaginary personas will do, it seems only logical that personas based upon real user data will do better. Web analytics can provide a helpful starting point to generate data-backed personas; this article presents an informal 5-step process for building a “persona of the people.”

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.

Long Live the User (Persona): Talking with Steve Mulder

by:   |  Posted on
“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.”

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

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.

icon acrobatDownload Chapter 3, The User Is Always Right (PDF)