User persona · User research · UX
How to create a user persona from real research
By T. Krause
A persona made up in a meeting is a guess with a name. Here is how to create one from research instead, followed through six made-up interviews, a page of notes that each have evidence behind them, and one product argument it settles.
To create a user persona, start with research on real users, such as interviews, support tickets or analytics. Group people who share goals and habits, and turn each group into one page with a name, a role, goals, frustrations, habits and a quote from your research. Then cut every detail that wouldn't change a product decision, and use the page the next time your team disagrees.
Nielsen Norman Group, or NN/g, says in its guide to personas that a persona is "a fictional, yet realistic, description of a typical or target user of the product". Both halves of that definition matter. The person is made up, and everything you say about them has to come from real people.
We make Prompt Board, and our user persona template opens on Nina, the practice manager you'll meet below. A sheet of A4 works too.
Two questions for every note
Before any example, here's the test we use. Each note on a persona has to pass both questions.
Would this still be true if your product didn't exist? A persona describes someone's work and life. "Loses an evening a week to the staff schedule" passes. "Loves our calendar view" fails, because it describes your product and it only tells you what you already hoped.
What decision would this change? NN/g's rule is direct: "if it would not affect the final design or help make any decision easier, remove it." Its example is a favourite wine, which is useless on an intranet persona and useful for a marketplace for sommeliers.
From six interviews to one page
Everything in this section is invented: the software team, the six interviews, the evidence, Nina and her quote.
A small team wants to build scheduling software for health practices. They interview six practice managers, visit their practices, and write what they find on sticky notes. NN/g's article on persona types suggests interviewing 5 to 30 users for this kind of persona, so six is at the low end, and the team knows that.
Group what you heard
NN/g's method is to identify characteristics from the research and group them into clusters: "they will begin forming clear characters". On an affinity map, the team's notes fall into two groups.
| Group | What sets them apart |
|---|---|
| Do-it-all, 4 of 6 | Handle schedules, supplies and billing questions themselves |
| Specialist, 2 of 6 | Larger practices, where someone else handles billing |
The groups differ in what people have to do, rather than in age or practice type. The first group is larger and has the scheduling problem the team wants to solve, so they write that persona first.
Fill the page
These are the notes on the sample board. The evidence column is the part that doesn't appear on the board, and it should still exist somewhere your team can find it.
| Note | Evidence from the four |
|---|---|
| Goal: schedule done in an hour | Three said it takes a whole evening now |
| Goal: no surprise invoices | Three described a supplier bill they hadn't expected |
| Frustration: three tools for one job | Two showed the team a spreadsheet, a calendar and a group chat |
| Frustration: staff call in sick by text | All four read the team a message like this |
| Habit: plans on Sunday evening | Three said so, and one showed the file's history |
| Habit: uses her phone between patients | Seen on all four visits |
The Profile frame adds a name and two sentences: "Nina, 41. Runs a dental practice with 12 staff. Plans staff schedules, orders supplies, handles billing questions." The quote comes from one interview: "I want Monday to start without a phone call about the schedule."
Every note passes the first question, because Nina's Sunday evenings and text messages don't depend on the team's software. All of them could shape what the team builds.
Cut the rest
The first version had more on it. Here's what the team removed.
| Removed note | Why |
|---|---|
| Would love a drag-and-drop calendar | Describes a solution. The goal behind it is already on the page. |
| Drinks oat-milk lattes | True of one manager, and it decides nothing |
| Busy | True of everyone they met, so it can't settle an argument |
| Wants to be paperless one day | Only one person said it, and nothing they'd build depends on it |
The name stays even though it decides nothing directly. NN/g says a name and photo "aid memorability", and being remembered is a persona's main job. Age is a closer call. NN/g lists it as a common detail, and our sample board keeps "41", but nothing in this team's decisions depends on it, so we'd delete it from a real persona.
Use it in an argument
One developer wants to build a desktop drag-and-drop planner first. The designer wants a phone screen for swapping a shift when someone calls in sick. Each has reasons, and they've gone round this twice.
They read the page. Nina plans on Sunday evening, and "Schedule done in an hour" argues for the planner. But her quote is about Monday's phone call, and two notes point at the same moment: staff call in sick by text, and she's on her phone between patients. The team chooses the phone screen first, and the planner goes next.
The persona didn't prove that the team was right. It gave them a reason both people could accept, and it told them what to test first. NN/g warns that reviews based on personas shouldn't take the place of testing: "But don't let this replace user testing!"
Three ways to build one
NN/g separates personas by the research behind them. Our template works for all three, as long as you say which one you've made.
| Type | Built from | Fits when |
|---|---|---|
| Proto | What the team already believes | You need a shared starting point today |
| Qualitative | Interviews and site visits | NN/g's choice for "most teams" |
| Statistical | A survey shaped by earlier interviews | You've got a large user base and the budget |
If all you've got is a proto persona, write "Draft, not researched" in the title. That stops anyone treating the team's beliefs as findings, and it reminds you to go and talk to people.
Where personas get criticised
Personas have serious critics, and it's worth knowing what they say. Wikipedia's article on personas in user experience reports that Chapman and Milham argued "there is no procedure to work reliably from given data to specific personas", and that Steve Portigal said their "appeal comes from the seduction of a sanitized form of reality". We've read Wikipedia's summary of those arguments rather than the original papers.
We take that as a warning about false confidence. Two teams given the same interviews could draw different groups. Keep the evidence column, change the page when new research disagrees with it, and treat Nina as a summary of what you know, rather than as a real person you can quote in a meeting.
Where personas came from
Wikipedia credits Alan Cooper with proposing the user persona. It says that "Beginning in 1983" he used an early form based on informal interviews with seven to eight users, and that his 1999 book The Inmates Are Running the Asylum popularised the technique.
That credit has been disputed. In a 2003 post, Victor Lombardi responded to a column by Cooper by pointing to Bruce Tognazzini's 1992 book Tog on Interface, which Lombardi says discusses the technique, and to a 1989 conference paper by Laurie Vertelney that Tognazzini cites. Lombardi also gives 1998 as the book's date, where Wikipedia gives 1999. We haven't read those books or the paper, so we'll leave you with the disagreement.
Frequently asked questions
What should a user persona include?
A name, a role, a short description of their day, goals, frustrations, habits and one quote from your research. NN/g also lists context, such as how often they'd use the product and on which device. Include anything that helps with a decision, and nothing else.
How many user personas do you need?
NN/g doesn't give a number. It talks about "a few individuals, if using multiple personas" and warns against keeping so many that they become unwieldy. We'd write one page per group that would make you build something different. If two pages lead to the same decisions, merge them.
What is the difference between a persona and an empathy map?
A persona summarises a type of user on one page. An empathy map captures what one person or type says, thinks, does and feels, and it's often made right after interviews as a step towards a persona.
What is the difference between a persona and an archetype?
Mostly presentation. NN/g says that "Personas are presented as a single human character, whereas archetypes are not tied to specific names or faces." The research behind them can be the same.
What is the difference between a user persona and a customer persona?
The format is the same. The questions differ if the person who buys isn't the person who uses, such as a clinic owner who pays for software that a practice manager runs each day. In that case, write one page for each.
Write your own
Collect your research first, even if it's only five conversations. Open the user persona template, overwrite Nina with your own group's notes, and keep the evidence for each note somewhere your team can find it. Then follow one person through their week with a customer journey map.