Personas

011 min

The problem Personas solve

A planning meeting for a subscription app that books fitness classes shows the problem. The product manager says the user wants a fast checkout. The designer says the user wants to browse many classes. The engineer says the user wants fewer notifications. Each of them describes a different person, and each is certain they know what "the user" wants.

Alan Cooper, the software designer who developed personas, called this the elastic user: a user whose description changes to suit whoever is speaking. A second, related risk exists. People who build products often design for someone like themselves without noticing. This is called self-referential design, and it produces a product that fits the team better than its customers.

A persona addresses both problems. It writes down one specific person, and the team agrees to design for that person. Later sections return to the same meeting to show what changes.

022 min

Where Personas came from

The first persona was a private habit before it was a method. This began in the early 1980s. Alan Cooper, a software designer, interviewed several people from the audience of a program he was building and then pretended to be them while he tested ideas. He then spoke as one of those users and judged each idea the way that user would.

Cooper later moved from writing software to advising clients, and he needed a way to show them what his interviews had taught him. He turned the habit into a written description of a typical user. His 1999 book, The Inmates Are Running the Asylum, brought the technique to a wide audience of software teams.

From design inspiration to a claim about real people

Cooper meant personas to inspire design. The method has since changed. Chapman and four colleagues made this point in 2008. Personas were first a tool for inspiring designers, but today they are more often treated as information about real groups of users. Two Microsoft researchers, John Pruitt and Jonathan Grudin, helped bring about that change. In 2003 they described three years of using personas on Microsoft products and said they had extended Cooper's technique with ongoing research and usability testing. They argued that personas help most when they add to other methods and do not replace them.

The shift matters because the two ideas need different proof. A tool for inspiration succeeds when it helps a team think. A claim about real people can be checked against data, and a later section shows what that check found.

032 min

What a persona contains and why it works

Today a persona is written as one person, and each part of the description has a job. It usually has a name, a photograph, a short biography, goals, habits and the setting in which the person uses the product. The persona is not the same as the one-page document that shows it. The persona is the understanding drawn from research, and the document is one way to share that understanding.

The name and photograph exist so the team remembers the persona. Every other detail has to be useful for design. A favorite sport tells a payroll team nothing, but the person's routine on payday tells it a lot. The test is simple: if a detail would not change a design decision, remove it.

Age, job title and income are not the most useful parts of a persona. NN/g argues that a persona should hold behaviors, attitudes and goals, not only age and job. The details that guide design are goals, habits, attitudes and the problems the person meets. A persona with only demographic details is a marketing segment with a name added.

Personas work because people reason about specific people more easily than about averages. A team can ask what a named person would do next and use what it already knows about how people behave. Writers on the method point to several human abilities behind this: telling and hearing stories, predicting another person's thoughts, and taking on a fictional character's feelings. A persona also gives the team a shared vocabulary. Instead of each member holding a different idea of the user, everyone points to the same name.

Why a persona works better over months

Pruitt and Grudin noted that a film can use a stereotyped hero or villain because the audience meets that character for only two hours. A television series cannot, because viewers follow its characters for years and a stereotype would become boring. A product team works with its personas for months, so a persona can carry more nuance than a one-time scenario can. A team that uses a persona that long will also notice any gaps in it.

042 min

How a Persona is built

A persona is only as good as the research behind it. A team observes and interviews people from the group it cares about, using field studies, user interviews or surveys. It looks for patterns in what those people say and do and groups similar people together. Each group becomes a description of one person who represents it. NN/g adds that building personas as a team makes the team more likely to believe in them and use them.

Some teams cannot do research first. A proto-persona, also called a provisional or assumptive persona, is written from what colleagues who know the customers already believe. Charles Kreitzberg, a usability consultant, built these from conversations with sales and support staff and treated them as drafts to correct with interviews later. The risk is that a proto-persona repeats the team's own beliefs. Label it as an assumption and replace it when real data arrives.

A product also needs a limit on how many personas it has. Kreitzberg suggests three or four for most projects and advises a team to stop and reconsider if it reaches five or six. One persona is usually the primary persona. The team decides for that person first and then tests the decision against the others.

Choosing which segments become personas

Microsoft's teams began from large market segmentation studies. Microsoft's teams fleshed out only their highest-priority segments into personas, using field studies, focus groups, interviews and more market research. They chose segments by market size, past revenue and strategic position, and they kept the set to between three and six personas for a product. A persona therefore usually stands for a segment that matters to the business, and not simply for an interesting person.

062 min

How teams use Personas to decide

Back in the planning meeting, the team now has three personas: a part-time fitness instructor, a student who attends twice a week, and a studio manager. The product manager no longer says what the user wants. They ask what each persona would do on the checkout screen, and the argument becomes a question the team can discuss with evidence.

Teams usually pair each persona with a scenario. A scenario is a short story of one persona pursuing a goal in a real setting, such as the instructor booking a room between classes. It shows where the product helps and where it gets in the way, without fixing what the screen looks like. Ambrose Little describes the story as the reason behind the person's goal and the scenarios as the steps that follow from it.

Scoring features against personas

Pruitt and Grudin describe a matrix that scores each feature against each persona. Pruitt and Grudin weighted each persona's score for a feature by the share of the market that persona represents. A persona gives a feature -1 if it confuses or harms them, 0 if they do not care, +1 if it has some value and +2 if they love it. The table is their own abstract example.

Features 2 and 4 become high priorities. Feature 3 has a negative sum because the largest persona is harmed by it, so the team should probably drop it. The scores come from the team's judgment, so the matrix organizes an argument and does not settle it.

Personas keep their use after design starts. NN/g lists three: guiding expert reviews, choosing whom to recruit for usability studies, and sorting analytics data by user group. Teams keep personas in view with posters and handouts, and Microsoft sent a weekly "persona fact" email from a real address for each persona. Personas are also revised as research and the market change.

071 min

Persona spectrums

Personas can also be built to show how one need appears in different circumstances. Microsoft's Inclusive Design toolkit does this. A product built for someone with one arm can also work for someone with an injured wrist or a parent carrying a baby, and the toolkit calls this range the Persona Spectrum. The same need appears as a permanent limit, a temporary one and a situational one. A team that solves it for the permanent case often helps the other two. This turns a persona into a way to look for shared needs, and it reminds a team that an accessibility need can affect many more people than a single label suggests.

081 min

Personas vs. nearby concepts

Several related concepts are mistaken for personas or used in their place.

Marketing and design use the same word for different things. NN/g warns that many so-called personas are marketing segments that stop at demographic details. A design persona is built to show how someone uses a product.

092 min

What the evidence shows for Personas

Whether personas improve a design is a separate question from whether they are popular. Frank Long of the UX consultancy Frontend wrote in 2009 that very little research had measured their benefit, and he ran a study to add some. The students came from the National College of Art and Design in Dublin. Nine student teams worked for five weeks on the same product brief. Three teams received only the brief and image boards. Three also received a persona with a photograph and written scenarios. Three received an illustrated persona with storyboard scenarios. Long then scored each finished design against Nielsen's usability heuristics.

The three teams with only the brief averaged 2.67, the three with a photograph persona averaged 5.67, and the three with an illustrated persona averaged 10.33. Long concluded that the persona teams understood user needs better.

The advantage faded by the end of the project

The gap in grades between the persona teams and the control teams was largest during research and concept work, and shrank before the project finished. Long read this to mean that the control teams found many of the same problems, only later. The persona teams found them sooner. Three limits apply. The students were handed a ready-made persona, so the study does not test how to build one. The designs were checked against a list of heuristics and not tested with users. And the sample was nine teams in one class.

102 min

When Personas fail

The same research that supports personas also shows where they fail.

The practical rule follows from all of this. Keep the details that change a decision, label what is assumed, check the persona against real people, and use it to organize discussion and not to replace research.

?4 questions

Questions people ask

§10 sources

Sources