All

How to Create User Personas That Teams Will Actually Use

Philippe H.

August 26, 2026

Most user personas have a surprisingly short life.

They are created during a workshop, polished into a nice-looking slide, shared with the team, and then quietly forgotten. A few weeks later, people are back to making design and product decisions based on opinions, assumptions, and whoever happens to be speaking the loudest in the room.

That is not really a persona problem. It is usually a research problem.

A useful persona is not a fictional character with a stock photo and a list of hobbies. It is a concise, evidence-based picture of a real user segment: what they are trying to achieve, what gets in their way, how they behave, and what influences their decisions.

Done well, user personas can shape everything from UX design and product positioning to onboarding, copy, and roadmap priorities. Done badly, they become another document nobody opens.

This guide explains what makes personas useful, why they often fail, when a proto persona makes sense, how to build personas from real research, and how to keep them relevant after the initial workshop.

Why most user personas fail

Personas usually fail for one of three reasons.

The first is that teams confuse demographics with useful insight. A persona might say, “Sarah, 34, marketing manager, enjoys yoga and travelling.” It sounds specific, but it tells a designer very little about how Sarah evaluates a product, what makes her hesitate, or why she might abandon a signup flow.

Demographics can provide context, but they should not be the foundation of the persona. Behaviour is far more useful.

The second problem is the fictional-character effect. Adding a name, profile picture, age, and biography can make a persona feel more believable than the evidence behind it deserves. Once that happens, assumptions start being repeated as though they came directly from users.

The third problem is treating persona creation as a one-off exercise. Your product changes. Your market changes. Your customers change. A persona based on last year’s assumptions may no longer reflect the people using your product today.

If nobody owns the persona or revisits the research behind it, the document slowly turns into decoration.

The broader lesson is simple: good personas come from evidence. Raw Studio’s approach to using both qualitative and quantitative information in UX is explored further in its guide to using data to inform UX design. Research gives teams something stronger than opinion to design around.

What should a useful user persona contain?

A useful persona focuses on the things that can actually change a decision.

That usually includes the following.

Goals

What is the user genuinely trying to accomplish?

Write this from their point of view rather than your company’s. Someone probably does not wake up wanting to “use a project management platform.” They may want to stop chasing updates across five different tools or make sure their team knows what needs to happen before Friday.

Motivations

Why does the goal matter now?

There is often a trigger behind someone’s search for a new product or service. Maybe their current process has become too slow. Maybe their team has doubled in size. Maybe they have been asked to reduce costs.

Understanding that trigger gives the persona much more context.

Jobs to be done

What is this person effectively “hiring” the product to accomplish?

The jobs to be done approach is useful because it keeps the focus on outcomes instead of features.

For example, the job may not be “create automated reports.” It might be “help me show my manager what happened this month without spending Friday afternoon building a spreadsheet.”

That distinction matters.

Behaviours and context

How does the person currently solve the problem?

What tools are they using? Are they working on a desktop or phone? Are they researching quickly between meetings? Do they need approval from someone else before making a purchase?

Context often explains behaviour better than demographics do.

Pain points

Where does the current experience break down?

Be specific. “The process is frustrating” is vague. “They have to export three reports and manually combine them every Monday morning” gives the team something it can actually solve.

Real customer language

Include words and phrases taken directly from interviews, support conversations, reviews, surveys, or sales calls whenever possible.

This is particularly valuable for UX and marketing copy. Instead of guessing how users describe their problem, you can use the language they already use.

Raw Studio’s guide to UX writing goes further into using research and customer language to improve the way products communicate.

Objections and decision criteria

What makes the user hesitate?

What questions do they need answered before they feel confident enough to sign up, book a demo, or buy?

Understanding objections can influence everything from landing-page copy to onboarding and pricing.

Notice what is not at the centre of this user persona template: hobbies, marital status, favourite coffee order, or an elaborate fictional biography.

Those details are only useful when they change how the person behaves or makes decisions.

Research-based personas vs proto personas

Not every company has enough research to create a fully validated persona on day one. That does not mean you have to work without one.

There are two useful starting points.

A research-based persona is built using evidence from interviews, analytics, usability testing, surveys, customer support, sales conversations, and other sources of real user behaviour. These personas should guide important product, design, positioning, and roadmap decisions.

A proto persona, on the other hand, is a hypothesis.

It is created from what the team currently believes about its users and should be clearly labelled as unvalidated.

Proto personas can be useful for early-stage companies, new products, or teams entering markets where they simply do not have much user data yet. They give everyone a shared starting point while making the team’s assumptions visible.

The important part is not to mistake a proto persona for finished research.

A sensible process is often:

Proto persona → research → validation → research-based persona

Build the initial hypothesis quickly. Write down what you are assuming. Then use those assumptions to decide what needs to be investigated during interviews or testing.

Raw Studio has shared more detail on how it approaches user interviews in real product work, including the importance of setting clear research goals before talking to users.

A proto persona should have an expiry date. It is a starting point, not something to defend indefinitely.

User persona vs buyer persona

A buyer persona and a user persona can overlap, but they are not always the same person.

A buyer persona focuses more heavily on the person involved in evaluating and purchasing a product. Their concerns might include pricing, return on investment, security, procurement requirements, implementation time, or stakeholder approval.

A user persona focuses on the person who actually interacts with the product or service. Their concerns may be much more practical: usability, speed, workflow, clarity, and whether the product helps them complete a task.

In B2B products, these may be entirely different people.

A finance director might approve the purchase while an operations team uses the software every day.

Understanding both matters. If you only design for the buyer, the product may sell well but frustrate the people using it. If you only design for the end user, you may create something people love using but struggle to get approved.

Jobs to be done is a lens, not a replacement for personas

The jobs to be done (JTBD) framework asks a useful question:

What is this person hiring the product to do?

That often reveals something a traditional persona might miss.

Two people with completely different job titles, ages, or company sizes may still be trying to accomplish the same underlying job. A startup founder and an enterprise operations manager, for instance, could both be looking for a way to reduce the time spent coordinating work across a team.

This does not make personas unnecessary.

JTBD explains the outcome someone is trying to achieve and often the trigger that caused them to look for a solution. The persona adds the behaviour, context, language, objections, and constraints needed to design for that particular group.

The strongest UX research personas often combine both perspectives.

How to create user personas from real research

You do not need an enormous research programme to create something useful. What matters is being deliberate about what you are trying to learn.

1. Define the decisions the persona needs to support

Start with the decisions, not the template.

Is the persona meant to guide onboarding? Pricing? Website messaging? Product strategy? A redesign?

Knowing what you need the persona for keeps your research focused and stops the document becoming a collection of interesting but unusable facts.

2. Use the data you already have

You may already know more than you think.

Look at analytics for behavioural patterns and drop-off points. Review support tickets for repeated frustrations. Read sales notes for objections. Look through customer reviews, surveys, and previous research.

The goal is to identify patterns worth investigating rather than jumping straight into assumptions.

3. Interview real users

Interviews are where much of the context behind the numbers becomes clear.

Ask people about what they have actually done rather than what they imagine they might do.

Instead of:

“Would you use a feature that automatically generates reports?”

Ask:

“Walk me through the last time you had to prepare that report.”

The second question gives you behaviour. The first gives you speculation.

4. Use surveys to check how common the patterns are

Interviews are great for discovering patterns, motivations, and problems. Surveys can help you understand how widely those patterns apply.

If interviews repeatedly uncover three different pain points, a well-designed survey can help you understand which one affects the largest or most important segment of your audience.

If you are planning this stage, Raw Studio’s guide to getting useful insights from user surveys covers practical ways to structure the research without accidentally collecting unusable data.

5. Group people by behaviour, not biography

Once you have the research, look for recurring goals, behaviours, pain points, triggers, and decision patterns.

Do not automatically group people because they have the same age or job title.

The more useful question is:

Do these people make decisions in roughly the same way?

If they do, they may belong to the same persona.

6. Turn the findings into a simple persona

Keep the finished document short.

A one-page persona that people actually use is worth far more than a six-page document filled with detail nobody remembers.

Include the person’s goals, behaviours, jobs to be done, pain points, motivations, objections, context, and a small number of real quotes.

If you are looking at persona examples for inspiration, pay attention to the information they prioritise rather than their visual design. A beautifully designed persona is still useless if the underlying information is invented.

7. Validate and revisit it

Before treating the persona as finished, share it with the teams that regularly speak to customers: sales, support, customer success, research, and product.

Ask what feels accurate, what feels questionable, and what is missing.

Then revisit the personas periodically, especially after a major product change, market shift, or change in customer mix.

Personas and customer journey mapping work better together

A persona answers:

Who are we designing for?

A customer journey map answers:

What happens to that person as they try to achieve their goal?

Used together, they become much more useful.

The persona gives you the user’s goals, context, motivations, and frustrations. The journey map shows where those frustrations appear across specific interactions and touchpoints.

This is particularly valuable when different user groups move through the same product differently. Raw Studio’s article on UX strategies for B2B products looks at how personas and journey mapping can help teams understand the different needs of new users, power users, and decision-makers.

How many personas do you actually need?

Usually, fewer than you think.

For many B2B products, two to four strong personas are far easier to use than seven or eight lightly researched ones.

Every additional persona creates another audience the team is supposed to remember when writing copy, reviewing a design, or prioritising a feature.

Before creating another persona, ask whether the new segment would genuinely change a decision.

If two groups have similar goals, pain points, behaviours, and buying triggers, they may not need separate personas simply because their job titles are different.

Depth is more useful than volume.

Three well-researched personas that appear in weekly product conversations are far more valuable than ten polished PDFs nobody remembers.

How to keep user personas alive

Creating the personas is only half the work. The real value comes from using them.

Use personas in design reviews

Instead of asking only, “Does this screen look good?”, ask whether it works for the relevant persona.

What context are they in? What information do they need? What are they likely to misunderstand?

That changes the discussion from personal preference to user needs.

Use customer language in your copy

Pull real phrases from research when writing headlines, onboarding instructions, error messages, CTAs, and product descriptions.

If your customers repeatedly describe a problem in one particular way, there is usually little value in replacing it with internal jargon.

Use personas in roadmap decisions

When evaluating a new feature, ask which priority persona it serves and what real problem it solves.

This creates a useful defence against feature bloat.

A request coming from one loud customer is not automatically evidence of a widespread need.

Keep sales, marketing, and product aligned

Shared personas can help everyone speak to the same audience.

Marketing understands what brings someone in. Sales understands their objections. Product understands what they need after they sign up.

When those teams work from different assumptions about the customer, the experience becomes inconsistent very quickly.

The business value of better personas

The payoff from good persona work is practical.

Positioning becomes sharper because you are speaking to a specific audience with a specific problem.

Copy becomes more convincing because it addresses objections and motivations you have actually heard from customers.

Design becomes easier to defend because decisions can be connected to user evidence rather than individual preferences.

And product prioritisation becomes more disciplined because new features need to solve a meaningful problem for an important segment.

That is the difference between a persona that lives in a slide deck and one that earns a place in your product process.

Where to start

If your company already has a folder full of unused personas, you probably do not need to throw everything away and start again.

Start by asking what evidence each persona is based on.

Remove details that were guessed simply to make the document feel complete. Highlight assumptions that still need validation. Compare the personas with recent interviews, analytics, support conversations, and customer behaviour.

Then bring them back into actual decisions.

If you suspect that the problem goes beyond the personas themselves, a broader UX review can also uncover gaps between what your team assumes users need and what the experience actually delivers. Raw Studio’s guide to conducting a UX audit is a useful place to start.

If you are building personas from scratch, do not wait for perfect research. Create a lean proto persona, make the assumptions visible, and start validating the parts that matter most.

The goal is not to create the most impressive persona document.

It is to understand your users well enough to make better decisions.

Raw Studio helps teams turn real customer research into clearer product, UX, and business decisions. If your personas are built on assumptions, your team is struggling to agree on who you are designing for, or you simply want an outside perspective on your current UX, get a free strategy session and proposal from Raw Studio.