Personas from Real Data: How to Build a Persona Your Team Actually Uses

A small team runs a delivery service for regional veg boxes. One afternoon, in a workshop, they create their first persona: “Lisa, 34, works in marketing, does yoga, buys organic and loves avocado toast.” Add a smiling stock photo taken in a farm shop. The poster then hangs in the office for months. In all that time, it doesn’t influence a single product decision.

Meanwhile, support keeps receiving similar messages. People cancel because they have no idea what to do with their third kohlrabi in a row. Others are annoyed because they forgot to pause deliveries before going on holiday, and a full box went bad on their doorstep. None of this has anything to do with Lisa and her avocado toast.

The example shows a common pattern. The persona didn’t fail because personas don’t work as a method. It was useless because it was built on guesses rather than data. This article walks you through how to build a useful persona from real data, which mistakes you can skip and how personas differ from the Jobs to be Done method.

What a persona is and what it isn’t

A persona is a fictional but research-based description of a group of people who use your product in similar ways. It usually gets a name and a few concrete details so the team can talk about a tangible character instead of “the users.” The concept goes back to Alan Cooper and became widely known through the book “The Inmates Are Running the Asylum,” published in 1998.

When you’re getting started, it helps to separate two things that often get mixed up:

• Target audience or marketing persona: Describes who a company wants to reach, often by age, income, location or interests. That’s useful for running ads.
• Design persona: Describes how people behave, what they want to achieve and where they get stuck. That’s useful for decisions about features, flows and copy.

This article is about the second kind. Why personas help teams in the first place, and where their limits are, is covered in detail in What Are UX Personas and Why Does Every Team Need Them?. Here, the focus is on the craft: how do you get from raw data to a persona your team actually works with?

Three types of personas

The Nielsen Norman Group (NN/g), a well-known UX consultancy and research firm, distinguishes three types of personas depending on how much research goes into them.

Proto-personas

Proto-personas come out of a workshop lasting two to four hours. Everyone involved sketches a few personas based on what they know, and the group then merges them. No new research is done. That’s fast and makes the team’s assumptions visible. The catch: proto-personas are often inaccurate and can cement wrong assumptions instead of challenging them. Lisa from the opening example is a proto-persona that was never labeled as one.

Qualitative personas

Qualitative personas are based on interviews, observation or usability tests. NN/g describes a range of roughly 5 to 30 interviews, conducted in rounds of about five, until hardly anything new comes up. The effort is manageable, and the result reveals motivations and needs that no statistic will show you. What these personas can’t do: tell you what percentage of your customers belongs to which persona.

Statistical personas

Statistical personas build on qualitative research and add a large survey whose responses are grouped using statistical methods. NN/g puts the minimum at 100 responses, ideally 500 or more. That takes a lot of work and statistical know-how. For most teams, it’s more than they need.

NN/g recommends qualitative personas for most teams, and that’s what the following guide is about. Proto-personas aren’t worthless, though: as a clearly labeled hypothesis that you later test with research, they can be a good starting point. That fits well with Lean UX, where assumptions are stated deliberately and then tested.

Step by step: from data to persona

Step 1: Clarify what the persona is for

Before you research anything, answer one question: which decisions should the persona make easier? A persona for designing subscription management needs different information than one for the recipe page.

In the veg box example, the answer could be: “We want to understand why people cancel within the first three months, and which features would help them stay longer.” This question determines who you talk to and what ends up on the persona. Anything that doesn’t contribute to it can go.

Step 2: Gather the data you already have

Most teams have more data than they think. It’s just scattered around. Take a look at things like:

• Support requests and emails: Which problems keep coming up?
• Cancellation reasons: If your cancellation flow has a free-text field, it’s a gold mine.
• App store or review site ratings: What do people praise, and what do they criticize?
• Usage data (analytics): Automatically collected numbers about what people do in your product, such as which pages they visit or how often they pause a delivery.
• Conversations with sales and support: The people there hear every day what’s on customers’ minds.

This data mostly shows you what happens. It rarely tells you why. In the example, the numbers might show that many cancellations happen after the fourth or fifth delivery. You’ll only find the reason by talking to people.

Step 3: Talk to real people

Interviews are the heart of a qualitative persona. Talk to people who fit the question from step 1: in the example, active customers, people who have canceled and a few who looked into the service but never ordered.

A few ground rules help:

• Ask about concrete past behavior. “Tell me about your last box. What did you do with what was in it?” gets you further than “Do you like cooking?”
• Observe if you can. In an article on developing personas, Kim Goodwin advises focusing on what people do rather than asking them what they want. A look inside the fridge on delivery day can reveal more than ten questions.
• Work in rounds. Do about five interviews, review the results and then decide whether you need more. When new interviews hardly add anything, you can stop.

You’ll find more on methods for getting to know people and their behavior in the glossary entry on user research.

Step 4: Find behavioral variables

This is the step many people skip, and the one that makes the biggest difference. Goodwin describes it like this: list every point where the people you interviewed differ in their behavior. These points are called behavioral variables. Most of them can be described as a scale with two ends.

For the veg box, the variables could look like this:

• Planning: plans meals for the whole week ahead ↔ decides spontaneously every evening
• Cooking confidence: cooks without a recipe using whatever is there ↔ needs instructions for unfamiliar vegetables
• Motivation: mainly wants to support local farming ↔ mainly wants to save time on grocery shopping
• Routine: at home every week ↔ often away, irregular schedule

Notice what’s missing from this list: age, job, gender, hobbies. Goodwin advises being careful with demographics, because behavioral variables usually matter more for design. Whether someone is 28 or 52 tells you little about whether they know what to do with a kohlrabi.

Step 5: Spot patterns

Take each person you interviewed and place them at the right point on each scale. This works well on a whiteboard or a digital board: one line per variable, one sticky note per person. Then look for people who sit close together on several scales. Goodwin describes these as people who “clump together” across multiple variables.

In the example, it might turn out that four interviewees plan their meals ahead, cook confidently without recipes and mainly want to support local farms. Five others decide on the spot, need guidance with unfamiliar vegetables and mainly want to save time. It’s this second group that shows up again and again among the cancellations.

These patterns become your personas. Check each one critically: is it really in the data, or are you seeing what you wanted to see? Goodwin explicitly warns against defining false patterns. A pattern based on a single person isn’t a pattern yet.

Step 6: Write the persona

Now write a short description for each pattern. Goodwin recommends telling it as a small story rather than a bullet list, keeping it short and making sure every element can be traced back to real data. These building blocks help:

• Goals: What does the person want to achieve, in everyday life and with your product?
• Typical situation: When and where do they come into contact with your product?
• Current solution: How do they solve the problem today, and what’s annoying about it?
• Obstacles: Where do they get stuck, and why?
• One or two real quotes from the interviews that capture the pattern well.

Here’s what the difference looks like in the veg box example:

Before (cliché): “Lisa, 34, marketing manager, lives in Cologne, does yoga, loves organic food and avocado toast. Wants to eat healthily.”

After (from data): “Sascha usually decides what to eat around 6 p.m. and isn’t in the mood for experiments by then. The box was a way to skip the weekly grocery run. Familiar vegetables get cooked right away, unfamiliar ones sit around until they wilt. Feeling guilty about that is the most common reason to think about canceling. Goal: cook something good in 20 minutes on stressful evenings without throwing food away.”

The second version has no age and no job, but it answers design questions right away. Do we need recipes with the box? Yes, quick ones that match what’s inside. Should people be able to exclude certain vegetables? Probably. Lisa wouldn’t have answered any of these questions.

How many personas do you need? As many as there are clearly different patterns, and no more. NN/g warns against creating too many personas: they should be easy to remember and clearly distinct from one another.

Step 7: Bring the persona into everyday work

A persona that sits in a folder helps nobody. To have an impact, it needs to show up where decisions are made:

• Present the personas together and explain which data they came from. That builds trust.
• Link them to concrete work. Note in tickets or user stories which persona a feature is meant for.
• Use them in discussions. “Would Sascha find this setting at 6 p.m.?” is a better question than “Is this user-friendly?”
• Connect them with other tools. A journey map, for example, shows step by step how a persona interacts with your product.
• Schedule a review. People and products change. Revisit your personas regularly, for example after every larger round of interviews.

Common mistakes and how to avoid them

Clichés instead of observations

The most common trap: the team fills gaps with whatever it imagines “the typical customer” to be. The result is characters like Lisa with her avocado toast or “the older generation that can’t handle technology.” Personas like these feel plausible because they match familiar images. That’s exactly what makes them dangerous. In an essay on personas, Indi Young warns that demographics can lead teams to assumptions, shortcuts in thinking and subconscious stereotypes.

The fix: every statement on the persona needs a source in your data. If you can’t back something up, cut it or mark it as an open question.

Too much demographics, too little behavior

Age, income, marital status and favorite brand fill up a persona quickly but rarely help with decisions. NN/g points out that demographics are troublesome for product and design decisions because they don’t provide behavioral or attitudinal data. Young suggests including demographics only when they’re genuinely tied to the behavior you’re studying. Age, for instance, is often better described as a phase of life (“just started their first job”) than as a number.

The perfect stock photo

A photo brings a persona to life, but it also steers attention. A flawless advertising shot invites people to judge the persona by appearance. That’s why some teams skip photos entirely or use simple illustrations. Young mentions that some teams drop names and photos altogether and work with descriptive behavioral groups instead. If you do use an image, choose one that shows a typical situation, such as someone at the stove after work, rather than a portrait.

Wishful customers instead of real ones

Sometimes a persona doesn’t describe who uses the product but who is supposed to. That’s legitimate if you’re trying to reach a new audience, but then it needs to be labeled as such. Never mix wishes and reality on the same persona.

False precision

“Uses the app 3.2 times a week” sounds precise, but with twelve interviews it’s made up. Goodwin advises against implying more certainty than the research supports. If your data is thin, label the persona as provisional and stick to a few goals and characteristics.

Made once, never looked at again

Personas go stale. When the product or your customers change, the persona from two years ago may no longer fit. Treat personas as a living document, not a final report.

Personas and Jobs to be Done

Sooner or later, anyone working with personas runs into Jobs to be Done, or JTBD for short. The method is sometimes presented as a replacement for personas. When you’re starting out, it’s worth knowing the difference.

What Jobs to be Done is

The basic idea of JTBD: people “hire” a product to get a particular job done in their lives. Instead of asking “Who are our customers?”, JTBD asks “What job should our product do for someone?”

The best-known example comes from the circle around Clayton Christensen, a professor at Harvard Business School. A fast-food chain wanted to sell more milkshakes. As part of a research project, someone spent a day observing who bought milkshakes and when. The result: 40 percent were bought first thing in the morning, mostly by commuters ordering them to go. The milkshake’s “job” wasn’t indulgence. It was making a long, boring drive more bearable, keeping one hand busy and staving off hunger until late morning. That led to very different product ideas than asking customers about the ideal qualities of a milkshake.

Where the difference lies

Put simply: a persona describes who someone is and how they behave. A job describes what someone wants to achieve, regardless of who they are. In the veg box example, a job could be: “When I get home tired in the evening, I want to cook something healthy quickly so I don’t end up ordering pizza again.” Very different people might share this job.

Page Laubheimer of NN/g considers the either-or framing a misunderstanding. According to Laubheimer, calls to abandon personas in favor of JTBD treat personas as purely demographic profiles. Well-made personas already contain goals, behaviors and obstacles, and those goals can be phrased as jobs. Laubheimer suggests noting the relevant jobs on each persona. At the same time, Laubheimer names a weakness of JTBD: because jobs are generalized across everyone, the emotional and social context easily gets lost, and with it some of the empathy.

What to take away as a beginner

You don’t have to choose. If your team already uses personas, phrase their goals as jobs and add them. If there’s resistance to personas in the team, perhaps because earlier posters hung on the wall without any effect, starting with jobs can be easier. Personas can follow later, once it’s clear that different people get the same job done in very different ways.

Conclusion

Back to the veg box team. With a clear question, a few analyzed support requests and around ten interviews, Lisa with her avocado toast would have turned into a persona like Sascha: someone who wants to cook something quickly at 6 p.m. and gets stuck on unfamiliar vegetables. That persona would have led straight to ideas that could prevent cancellations.

Good personas don’t need a big budget. They need data instead of guesses, behavior instead of demographics, and the discipline to write down only what you can back up. Add the jobs your personas want to get done, and your team has a tool that genuinely helps in discussions.

Checklist

• It’s clear which decisions the persona should help with.
• Existing data such as support requests, cancellation reasons and usage data has been reviewed.
• You’ve interviewed people who fit the question, in rounds of about five.
• Behavioral variables are noted as scales, and every interviewee is placed on them.
• Each persona is based on a pattern that shows up across several people.
• The persona describes goals, situations, current solutions and obstacles.
• Demographics are included only when they explain behavior.
• Every statement can be traced back to data, and anything uncertain is marked.
• Proto-personas are labeled as hypotheses.
• Relevant Jobs to be Done are noted on the persona.
• A date for the next review is set.

Sources

• Page Laubheimer, Nielsen Norman Group: 3 Persona Types: Lightweight, Qualitative, and Statistical (2020)
• Page Laubheimer, Nielsen Norman Group: Personas vs. Jobs-to-Be-Done (2017)
• Kim Goodwin, MarketingProfs: Getting from Research to Personas: Harnessing the Power of Data
• Indi Young: Describing Personas (2016)
• Carmen Nobel, Harvard Business School Working Knowledge: Clay Christensen’s Milkshake Marketing (2011)
• Wikipedia: Alan Cooper (software designer)