Most personas are fiction. They get sketched in a workshop from gut feel, given a stock photo and a clever name, and then ignored for the rest of the project. The problem isn't the format. It's that they were never built from evidence, so no one trusts them enough to act on them.
A user persona is a research-based archetype of a real user segment, capturing the goals, behaviors, and pain points that should shape your product and design decisions. This guide is about how to create user personas that earn that definition. We won't dwell on what user personas are or why they matter, since that ground is covered well elsewhere. The point here is the method.
One rule sits underneath everything that follows. A persona is only worth making if it changes a decision. If you can't name a decision it should influence, you're making decoration.
Here's the process, start to finish:
Research isn't just step one. It's the spine of every step that follows. Skip it and you get the fiction problem all over again.
Step 1: conduct user research and gather evidence
Everything downstream depends on this step, which is exactly why it's the one most guides rush. They say "do some research" and then spend the rest of the article on layout and color. The quality of your personas is capped by the quality of the evidence underneath them.
Use a mix of sources. Qualitative research tells you why people behave the way they do. Quantitative data tells you how common that behavior is. You want both:
- User interviews and contextual inquiry, where you watch and listen rather than ask people to predict their own behavior
- Conversations your support and sales teams are already having, which are a standing source of unfiltered user language
- Product analytics, which show what people actually do instead of what they say they do
- Surveys for scale, once you know what to ask
- Support tickets and CRM data, which surface recurring friction in the customer's own words
When you interview, ask about real, recent, specific experiences. "Walk me through the last time you tried to do X" beats "What features would you like?" every time. Focus on goals, actual behavior, and where things broke down. People are unreliable narrators of what they would do, and reliable narrators of what they did last Tuesday.
If you have no research yet, you can start with a proto-persona built from your team's existing assumptions. Just label it as a hypothesis to validate, not a finished artifact. Proto-personas and research-based personas serve different moments, and it's worth being honest about which one you're holding.
How much research do you need before building a persona?
Enough that you stop hearing new things. In practice, that's often five to eight interviews per segment you suspect exists. Around there, themes start repeating and new interviews confirm rather than surprise. That's saturation, and it's your signal you have enough to find a pattern.
Start with fewer if you need to, and keep going if themes are still emerging. B2B research often needs fewer, deeper conversations because the population is smaller and the roles are more defined. B2C usually leans harder on quantitative volume to confirm that a pattern holds across a large, varied base.
Step 2: identify patterns and segment your users
This is the step that separates a research-based persona from a decorated guess, and it's the one almost everyone glosses over. You have transcripts, notes, and data. Now you have to turn them into segments.
Pull the recurring goals, behaviors, and frustrations out of your raw material. Tag quotes, group the ones that echo each other, and name the clusters that emerge. This is affinity mapping, and it's where the path from quote to theme to segment actually happens. A single frustrated comment is an anecdote. The same frustration from a dozen people across several interviews is a pattern worth designing around.
Segment by behavior and motivation, not by demographics. Two users with the same age, income, and job title can belong to completely different personas if they're trying to accomplish different things. Two users who look nothing alike on paper can be one persona if they behave the same way and want the same outcome. Group by jobs to be done, and the segments tend to organize themselves.
- Groups by age, income, and job title
- Splits users who want the same outcome
- Merges users with very different goals
- Rarely changes what you build
- Groups by the job people are trying to get done
- Keeps users with shared goals together
- Separates genuinely different needs
- Maps directly to product and design decisions
Not every difference deserves its own persona. A segment earns persona status only when it would lead you to a different product or experience decision. If two clusters would result in the same roadmap, they're one persona wearing two outfits.
Step 3: decide what goes in the persona
Choose your fields before you fill them in, and choose them based on the decisions the persona needs to support. A template's default boxes are someone else's decisions, not yours. Start from what your team will actually use.
Lead with goals, motivations, behaviors, and pain points. Demographics are context, not the headline. A lot of persona guides warn against demographic over-focus and then put age and income at the top of the template anyway. Don't make that mistake. Age rarely changes what you build. The job someone is trying to get done almost always does.
Keep the layout lean and consistent across your set, so personas stay comparable. There are plenty of user persona templates and examples for specific contexts like B2B, SaaS, and e-commerce, and they're useful as starting points. Just don't let the template dictate what matters. The fields serve the decisions, not the other way around.
The core components of an effective persona
Here's what actually drives decisions, what's useful as supporting context, and what's just decoration.
| Field type | Examples | Why it's there |
|---|---|---|
| Decision-driving | Goals / jobs to be done, key behaviors, motivations, pain points, context of use, a real quote | These change what you build and prioritize |
| Supporting context | Role or title, relevant demographics, tools and channels used, success criteria | Useful background, but rarely the deciding factor |
| Decoration | Stock-photo backstory, hobbies, invented personal trivia | Looks rich, informs nothing, cut it |
The test for any field is simple. If it would never change a decision, it doesn't belong, no matter how complete it makes the persona look.
Step 4: fill in the components from your research
Populate every field from your synthesized research, not your imagination. Each claim in the persona should trace back to something a real person said or did. If you can't point to the evidence behind a trait, it's a guess, and guesses are how personas lose credibility the first time someone who knows the users reads them.
Goals and pain points should be specific and in the user's own language. Pull the representative quote straight from a transcript rather than writing one that sounds good. Real quotes carry a texture that invented ones never do, and they're what make a persona land in a room full of skeptics.
Keep each persona to a single segment. The temptation is to average two segments into one tidy "typical user," but that produces a person who doesn't exist and whose needs no real customer fully shares. Resist the blend. And resist fabricated precision, the made-up salary, the fictional morning routine. It reads as detailed and supports exactly zero decisions.
Step 5: make it memorable and shareable
The human layer matters, but it sits on top of the research and never replaces it. A name, a photo, a one-line bio, and a real quote make a persona easy to talk about. "Operations Olivia would never sit through that onboarding flow" is a sentence a team can actually use in a planning meeting. That's the job of the human layer: to make the evidence sticky.
Give the persona a realistic name and a representative image. Keep the bio to the few sentences that capture who this person is and what they're trying to do. More than that is throat-clearing.
Then make it a living artifact instead of a slide that dies after the kickoff. A persona stored in a deck on someone's drive is already on its way to irrelevant. Personas should live where the team works, stay shareable, and connect to the journeys and decisions they inform. Smaply keeps personas as structured, maintained records linked directly to journey maps, which is what keeps them in the conversation instead of in a folder.
Step 6: validate, then put your personas to work
A persona you haven't tested is still a hypothesis. Validate it two ways. Put it in front of colleagues who work with these users daily and watch whether they recognize the person. Then check it against fresh research and see whether new data keeps fitting. When reality and the persona disagree, reality wins, and you revise.
Run every persona through the decision test. For each one, name a specific recent or upcoming decision it should change. This single question does more to keep a persona set honest than any amount of formatting.
Then actually use them. This is where most guides stop, right at the moment the work starts paying off. Personas anchor whose experience you're designing for. They tell you whose journey you're mapping and whose pain points you're prioritizing. Feeding personas into journey mapping is the most direct way to put them to work, because a journey map without a clear persona behind it is just a generic flow that belongs to no one. Personas give the map a point of view.
Keep them current. Set a review cadence, often quarterly or twice a year, and refresh on triggers like a major product shift, a new market, or research that no longer fits. Personas are a living input to the broader practice of customer journey management, not a deliverable you finish and file. The moment they stop reflecting real users, they start quietly misleading every decision they touch.
How many personas do you actually need?
Most teams need three to five primary personas. That's enough to capture genuinely different needs and few enough that the team can hold them in their heads and actually use them. Once you pass five or six, people stop remembering who's who, and the set stops getting used.
A long persona list is usually a symptom, not an achievement. It means you segmented on attributes that don't change decisions. If two personas point to the same roadmap, the same priorities, and the same design choices, merge them. You're not losing nuance. You're removing noise.
It's also worth defining a negative persona, the user you're deliberately not building for. Naming who you're willing to disappoint sharpens every decision about who you're serving, and it gives the team permission to say no.
Common mistakes to avoid
The same handful of failures show up again and again:
- Assumption-based personas dressed up as fact. Built from internal opinion, never validated against a real user. The format looks legitimate, which makes it more dangerous, not less.
- Leading with demographics. Age and income up top, goals and behaviors buried below. It inverts what actually drives decisions.
- Too many personas. More personas feels more thorough. It usually means weaker segmentation and a set no one can remember.
- Treating personas as a one-time deliverable. Created once, never updated, slowly drifting from reality until they're actively wrong.
- Letting them gather dust. Built for a workshop, presented once, then never used in a real product, design, or journey decision. A persona that doesn't change how you work was a waste of the research that went into it.
Get the research right, segment by what people are trying to do, and tie every persona to a decision. Do that, and your personas stop being fiction and start being one of the most useful inputs your team has.
Frequently asked questions
What is the difference between a research-based persona and a proto-persona?
A proto-persona is a fast, assumption-based sketch built from your team's existing knowledge, used to align everyone early when you don't have research yet. A research-based persona is validated against real user data from interviews, analytics, and other evidence. Proto-personas are a legitimate starting point. The risk is mistaking one for the finished article and never going back to validate it.
How do user personas differ from buyer personas, ICPs, and segments?
A user persona describes who uses the product and what they're trying to accomplish with it. A buyer persona describes who makes the purchase decision, which in B2B is often a different person entirely. An ideal customer profile (ICP) describes the type of company or account worth targeting, not an individual. A segment is a statistical grouping of users by shared attributes. Personas humanize a segment by giving it goals, behaviors, and a face.
How often should you update your personas?
Review them on a regular cadence, commonly quarterly or twice a year, and refresh whenever something material changes: a major product shift, entry into a new market, or research that no longer matches the persona. Personas are living documents. The moment they stop reflecting real users, they start misleading the decisions that rely on them.
How do personas connect to journey maps?
Personas define whose experience a journey map represents. Each primary persona typically gets its own journey map, or its own view within a shared one, so that pain points and priorities stay tied to a specific, real segment rather than an averaged-out everyone. Without a persona behind it, a journey map is a generic flow with no clear owner. The persona is what gives the journey a point of view.
