What is a persona, and how do you create one?

In short

A persona describes a behaviour pattern you see in user research as if it were a single person. Nielsen Norman Group (NN/g) defines a persona as “a fictional, yet realistic, description of a typical or target user”.

The presentation is fictional: name, photo, perhaps an age. The content has to be real. What the person wants to get done and where they get stuck comes from research.

User persona, UX persona and user profile are often used to mean the same thing. Marketing teams write personas too, but with a different aim.

Kim Flaherty of NN/g explains this with a banking example. The marketing persona helps communicate the product’s value to potential customers. The UX persona guides interaction design; that is the one this guide is about.

What a persona is good for, and what it isn’t

A persona makes sure the team looks at the same picture of the user. The sentence “The user wants this” creates a different person in every head. The sentence “Linda can’t do that while customers are standing in front of her” ties the discussion to a concrete situation.

The NN/g persona article names further jobs. A persona holds back design that tries to serve everyone. It helps with expert reviews, with recruiting test participants and with splitting analytics data into segments.

I use it most often in a heuristic evaluation. If I start without asking whose eyes I am looking at a screen through, I project my own habits onto the user. The persona puts the answer to that question on the table from the start.

The persona is one of the practical tools of user-centred design. It carries what you learned in research to team members who weren’t there. That way, engineering and sales talk about the same person.

What it isn’t good for

• It doesn’t replace a user test. NN/g says so explicitly too. The persona tells you what to test; only a usability test shows whether a screen works.
• It doesn’t say how many of your users resemble this person. A persona from interviews carries no proportions. If you want to know that, you need a statistical study.
• It doesn’t decide on its own. The persona is a point of reference. Whether a feature gets built is still decided by the business goal and the data.

What goes into a persona

The NN/g list is long: name, age, gender and photo, a short tagline, job and experience with the product. Then come the context of use, behaviour, goals, concerns and a quote that shows the person’s attitude.

I split this list into two groups. The first changes design decisions; the second makes the persona easier to remember.

• What changes decisions: context, goal, obstacle, behaviour, experience with the product. Someone who has to use a product puts up with a bad screen, but hates it.
• What helps memory: name, photo, tagline, quote. With these, the team remembers the persona like a person. NN/g recommends not making the tagline too witty, or the persona won’t come across as a serious tool.

The context of use is the line most often skipped. NN/g opens it up with a few questions: how often, and on which device, is the product used, by choice or because the job requires it? The same person is a different user at an office desk than on a phone on the bus.

Page Laubheimer of NN/g also talks about the archetype in a 2022 article. The archetype presents the same research without a name or photo, with a label that describes the behaviour. Instead of a person’s name, something like “issues invoices for several clients”.

The content is the same; only the presentation changes.

Types of personas

In another article from 2020, Laubheimer divides personas into three types. They differ in the data they are based on and the effort they take.

Proto-persona (lightweight persona)

No new research is done. In a workshop, the team writes down what it knows or assumes about users.

According to Laubheimer, the workshop takes 2 to 4 hours. Each participant writes 2 to 5 drafts, and the group combines them into 3 to 6 personas.

The benefit: the team’s unspoken assumptions become visible. These assumptions become hypotheses that are later checked with research. The article also names the risk plainly: proto-personas are often wrong and can become an echo chamber that reflects the team’s wrong assumptions back.

Qualitative persona

It is based on exploratory research such as interviews, usability tests or field studies. Laubheimer recommends interviews with 5 to 30 users. You start with 5 people per group and keep going until new interviews bring hardly anything new.

The interview notes are split into themes, then you look for overlapping patterns within the themes. The article recommends this type as the best balance for most teams. The weakness: it can’t say how many users each persona represents.

Statistical persona

First, qualitative research finds themes; then a large survey follows using those themes. Laubheimer calls for at least 100, ideally 500 or more responses. The responses are grouped with clustering methods.

That way you can measure each persona’s share of the user base. The article considers the method expensive and time-consuming, though. Also, the results are often very similar to the qualitative personas.

Which one to choose

If you have no data at all, you can start with a proto-persona. Just write “assumption” on it, and check it with interviews at the first opportunity. For most teams, the qualitative persona is the right goal.

The statistical persona needs a large user base and someone who knows statistics. If the question “What share of our users is this group?” drives an investment decision, the cost is justified.

Creating a persona step by step

The steps below apply to the qualitative persona. An MVP team can follow the same order as a large company. What changes is the number of interviews.

1. Write down the scope. Which decision is the persona needed for? A persona for all of a bank’s products isn’t the same as one just for the bill-pay screen. Flaherty writes that a persona that doesn’t match the project’s goal and scope is of no use.

2. Gather the existing data. Support tickets, analytics, notes from sales, old test recordings. They tell you what to ask in the interview. They aren’t enough to build the persona on alone.

3. Talk to users. Talk to people who really use the product or will use it. Don’t aim your questions at the product’s features, but at the person’s work and where they struggle with it.

4. Split the notes into themes. Write the observations from each interview on separate cards. Then group similar cards: goals, obstacles, context, tools used.

5. Find patterns. People with the same goal who get stuck in the same place form a group. Demographic details such as age or city aren’t the basis for grouping. Laubheimer also writes that clusters aren’t formed by demographics.

6. Write the persona. One page per group. Start with context, goal, obstacle and behaviour. Name and photo come right at the end. NN/g recommends removing every detail that doesn’t affect a decision.

7. Add the source. Note under the persona which research it is based on. Whoever opens this page a year from now should know what they can rely on.

8. Involve the team. Work on a draft with the team before you present the persona. Flaherty sees a persona created away from the team as the biggest obstacle.

A warning about the made-up persona

The persona I see most often was written in a meeting and put on the wall without anyone talking to anybody. It has a nice photo, a quote and a list of hobbies. None of it comes from research.

A persona like that isn’t harmless either. It tells the team what it already believes, back as “This is what the user is like”. It is used like evidence that ends the discussion, yet there is no evidence.

If you can’t do research, write a proto-persona and call it that openly. Writing “Assumption, not confirmed” on the card is enough. The real problem is passing off a proto-persona as a qualitative persona.

A persona example

The persona below is fictional. It isn’t based on any real research; I wrote it only to show how to write a persona. The product is a web app that small businesses use to send invoices.

Fictional example

Jason works at a small accounting firm

Context

He issues invoices for several clients on the desktop computer in the office. At month end the work piles up, and during the day he is often interrupted by phone calls.

Goal

Send each client’s invoice with the right company details in one go.

Obstacles

When switching between clients, he loses track of whose screen he is on. The error message doesn’t say which field is wrong.

Behaviour

Before sending, he downloads the invoice as a PDF and checks it. Because he doesn’t fully trust the app, he also keeps a spreadsheet.

What he says

“An invoice to the wrong company is like a payment to the wrong person. Undoing it costs me a day.”

Underlying research

None; fictional example. In a real persona, the number and dates of the interviews would go here.

As you can see, this persona has no age, hobbies or marital status. They don’t change any decision on the invoice screen. The real design hint is in the obstacles: a heading that always shows which client you are on, and an error message right at the field.

The quote isn’t decoration either; it shows how Jason weighs the cost of a mistake. That justifies a summary screen before the “Send” button. Whether such a screen fits the user’s mental model is, again, something you see in testing.

If I used this card in a real project, I would change the source first. I would talk to a few people who work at accounting firms and write next to each obstacle the interview it came from. A line that didn’t come up in any interview, I would strike from the card.

Try it: persona generator

The core of a persona is four lines: who, in which context, what does the person want to get done and where do they get stuck. I add one more line: where does this information come from? Fill in the fields below with your own research notes.

Persona generator

Fictional example

Linda, owner of a neighbourhood pharmacy

Context

At the counter, on her phone; she often orders while customers wait in front of her.

Goal

Order an out-of-stock medicine before the customer leaves the pharmacy, and tell her the delivery time.

Obstacle

Search doesn’t recognise the abbreviated name of the medicine. To scan the barcode, she has to fetch the pack from the shelf.

Underlying research

Fictional example. It isn’t based on any real research.

This is an example card. With JavaScript, you can fill in the fields yourself and copy the text.

Linda is a fictional character and doesn’t come from any real research. Change the fields, and the persona card updates as you type. An empty field is marked as empty on the card. The Copy text button puts the card on the clipboard as plain text.

You can copy the card and paste it into your team document. Please don’t leave the “Underlying research” line empty. If it is empty, what you have is a proto-persona.

How to use the persona

A persona that is written and put in a folder is of no use. In Flaherty’s words, such personas collect dust on a shared drive. There are a few ways to bring the persona into day-to-day work.

In design discussions. When the question “Who will use this?” comes up, use the persona’s name. “Can Jason see on this screen which client he is on?” opens a clearer discussion than the word “user”.

When recruiting test participants. NN/g recommends using the persona to recruit test participants. Derive the screening questions from the persona’s context and experience. For Jason, you look for someone who issues invoices for several clients.

In expert reviews. In a UX audit, I go through the flow through the persona’s eyes. The same screen can be no problem for experienced users and a dead end for someone coming for the first time.

In analytics. NN/g also recommends splitting analytics data by persona group. If a group’s behaviour drifts away from the persona, Flaherty says that is a signal to review the persona.

Flaherty names further signals. They include the business changing direction, a new group joining the user base and test participants behaving differently from the persona. If new kinds of questions reach support, look at the persona again too.

Common mistakes

Writing the persona without research. The made-up persona from above. The team’s assumptions hide behind a photo.

Starting with demographics. “35, female, Chicago” is a marketing segment. For design, what counts is what the person wants to do and where they struggle.

Adding unnecessary details. Favourite TV show, the dog’s name. NN/g writes that details like these crowd out the important ones.

Writing too many personas. If a new persona comes out of every meeting, none gets used. Stick to the groups that really separate design decisions.

Creating them away from the team. According to Flaherty’s article, this is the biggest obstacle to personas being adopted. According to the same article, 90% of the value of personas comes from having them and believing in them.

Never updating. Products and users change. In Flaherty’s 2016 survey of 156 UX practitioners, those who updated their personas quarterly or more often rated their impact highest.

Getting hung up on the photo. According to Laubheimer, a face on the persona can quietly exclude users who don’t see themselves in that face. If you use a photo, don’t make it the basis for design decisions.

My note

When I open the persona file for the first time while working with a team, I look at a single line: where does this come from? Usually there is no answer. Then I put the persona aside and ask the team for the last five support tickets.

A good persona is short. A persona that doesn’t fit on one page is, to me, one nobody reads. If the goal and obstacle are filled in and the hobbies line is empty, you are on the right track.

The persona is also a brake on designers thinking they are the user. I have that tendency too, and the persona reminds me of it at the table.

My advice to small teams is simple. Start with five interviews, write a single persona and check it in the next test. Instead of waiting for a perfect set, work with a draft whose mistakes you can show quickly.