User Persona Template: How to Create Personas That Actually Influence Design

Walk into almost any product team and ask to see their personas. What you will find, almost without exception, are beautifully formatted documents with stock photos, fictional names, and bullet points that tell you someone is a 34-year-old marketing manager in Bristol who enjoys yoga and "wants to feel confident about her finances."

That persona will not help anyone make a single better design decision.

This post is a user persona template for the version that actually works -- what it contains, what research feeds it, how to write it, and how to use it so that it stays relevant past the first sprint.

What a Persona Is and What It Is For

A user persona is a synthesised representation of a segment of real users, built from research. It captures shared patterns in how a group of people approach a problem: what they are trying to accomplish, what they currently do, where things break down, and what they assume about how the world should work.

The operative word is synthesised. A persona is not a transcript. It is not a survey respondent. It is a model built by identifying patterns across multiple research sessions and distilling them into something the whole team can reference and test decisions against.

Its purpose is alignment. Left to themselves, product managers, engineers, and designers will each hold a different model of who they are designing for. Personas make that model explicit and shared. When someone says "would Alex actually do this?" and the whole room knows who Alex is, the meeting gets shorter and the decision gets better.

A persona is a communication and alignment tool. It is not a research output in itself, and it is not a substitute for ongoing research. It is a snapshot of what you understood at a point in time, and it should be updated when that understanding changes.

The Problem With Most Personas

Most personas fail for predictable reasons, and being direct about them will save you from repeating the same mistakes.

They are built from assumptions, not research. A team gets together for a workshop, fills in a persona template from gut feel and collective intuition, and calls it done. This is a proto-persona (more on those later) treated as if it were evidence-backed. The result is a document that reflects what the team already believed, which means it will never challenge a bad assumption.

They are full of demographic details that do not affect design decisions. Age, location, job title, relationship status, hobbies -- these fill up persona templates because they make the document feel like a real person. But ask yourself: does knowing that your user is 35 rather than 45 change any design decision you will make this sprint? If not, that detail is noise. Noise crowds out signal.

They are too vague to be actionable. "Sarah wants to feel confident about her finances" is a sentiment, not a design input. What does she currently do when she checks her balance? What breaks down in that process? What does she assume the product should tell her? Vague aspiration statements make personas feel human but useless.

They are used as project deliverables rather than living design inputs. A persona gets created, presented, added to a Confluence page, and never opened again. For a persona to be useful, it needs to be visible in the workspace, referenced in design critiques, and updated when research reveals something it got wrong.

What Research Should Feed a Persona

A persona is only as good as the research behind it. The core inputs are:

User interviews are the primary source. One-to-one conversations with real users surface the goals, behaviours, mental models, and frustrations that should sit at the heart of every persona. If you have not conducted interviews yet, read UX research methods before building any persona. Without this foundation, you are writing fiction.

Behavioural data -- analytics, session recordings, heatmaps -- gives you patterns at scale. If your interviews surface a hypothesis about how users navigate a flow, behavioural data can confirm whether it is an outlier or a widespread pattern. It also catches behaviours that users do not mention in interviews because they have normalised them.

Surveys provide quantitative context. Once you have identified themes from qualitative research, a survey can tell you how prevalent each theme is across your wider user base. This helps you decide which persona represents the largest segment and therefore should be the primary design target.

The key principle: personas should reflect patterns in behaviour, goals, and pain points -- not in demographics. Two users can be demographically identical and behaviourally opposite. The behavioural dimension is the one that actually determines how they will interact with your product.

What a Good Persona Actually Includes

Here is what belongs in a persona that will be genuinely useful:

Name and photo. Not because the fictional name matters, but because it gives the team a handle. "What would Marcus do?" is a faster and more memorable reference than "what would the primary persona in segment two do?" Use a fictional name and a photo that is not a stock-photo cliche. The goal is memorability, not decoration.

Role or context. What situation brings this person to the product? This is not necessarily a job title. It might be "someone making their first significant financial decision without professional advice" or "a team lead trying to onboard a new designer quickly." Context matters more than credentials.

Goals. What is this person ultimately trying to accomplish? Keep these functional -- rooted in what they actually want to do -- rather than aspirational. "Complete the application before her lunch break" is a goal. "Feel empowered about her career" is a marketing tagline. Aim for two to three goals that directly shape design decisions.

Behaviours. How does this person currently approach the problem? What tools or workarounds are they using? What does their existing process look like? This is one of the most valuable sections because it reveals where your product is inserting itself into an existing workflow -- and therefore what friction it is replacing and what it must match or beat.

Pain points. Specific frustrations with the current experience, not general dissatisfaction. "The form times out if she leaves to check her documents" is a pain point. "Finds the process stressful" is not. Two to three specific, observable frustrations give designers something to target.

Mental model. What does this person already know or assume about how this type of product should work? Mental models shape how users interpret your interface before they have read a single word of copy. If your user assumes that "save" means "publish," any design that treats them as separate actions will cause confusion -- regardless of how clearly you label things.

Representative quote. A verbatim or carefully synthesised quote from research that captures the person's perspective in their own voice. This is the fastest way to bring a persona back to life in a design critique. "I just need to know the number, I do not care why it is that number" tells you more about a user's relationship with financial data than three paragraphs of analysis.

What NOT to include: hobbies, family details, tech-savviness scores on a five-point scale, and lengthy backstories. These are not design inputs. They are padding that makes a document look thorough while making it harder to use. Include demographic context only if it directly affects a design decision -- for example, if your product is primarily used on low-spec mobile devices, noting that your persona does not own a laptop is relevant. Their relationship status is not.

Behavioural Personas vs Demographic Personas

This distinction is worth spelling out clearly because it is where most teams go wrong.

A demographic persona looks like this: "35-year-old marketing manager in London, uses Instagram daily, intermediate Excel user, has a gym membership."

A behavioural persona looks like this: "Someone making high-stakes decisions with limited time who distrusts tools that require extensive setup before delivering value."

The demographic version tells you who the person is. The behavioural version tells you how they will approach your product. Only one of those descriptions helps you design a better onboarding flow, decide how much explanation to put before the first meaningful action, or choose between a guided wizard and an open canvas.

When you are building a persona, check every field you include against this question: does this change a design decision? If the answer is no, cut it.

How Many Personas?

Most projects need one to three primary personas. One is often not enough -- a product that serves meaningfully different user segments with different goals and behaviours cannot be accurately represented by a single model. But more than three and the team stops using them. People can hold roughly three distinct user models in their heads during active design work; beyond that, personas become a reference document rather than a design tool, and reference documents do not get consulted in the moment.

Anti-personas -- explicit descriptions of who you are not designing for -- are underused and often more valuable than additional primary personas. Defining the edge-case user you are intentionally excluding from the primary design target keeps scope honest. It prevents features being added to serve someone the product was never meant to serve well, and it gives you a principled answer when a stakeholder says "but what about users who..."

The Persona Template: Section by Section

Rather than a downloadable file you fill in once and file away, here is what each section of a well-constructed persona template should contain and why.

Header: Name, photo, and a single sentence that captures the user's core context. This sentence is the persona's thesis. "Alex is a mid-career professional retraining for a new field who needs to demonstrate new skills quickly, without disrupting his current income." Everything else in the document should support or elaborate that sentence.

Goals (2-3 bullets): Functional goals, written as outcomes. What does this person need to have achieved by the time they leave your product? Keep them specific enough to test against. "Get an answer she trusts in under three minutes" is testable. "Have a good experience" is not.

Current behaviours and workarounds: How is this person solving the problem today, before your product exists for them? What tools are they cobbling together? What steps are they doing manually? This section should make the team feel the friction the product is replacing.

Pain points (2-3 bullets): Specific, observed frustrations -- ideally ones you can quote back to a research participant. The more concrete these are, the more directly they can drive design decisions.

Mental model and assumptions: What does this person expect before they have used your product? What analogies are they drawing from other experiences? Where is their mental model likely to collide with how the product actually works?

Representative quote: One or two sentences in the user's voice. Pull it from a real interview transcript or synthesise it carefully from multiple sessions. This is the section that should make the team feel they have met this person.

Secondary -- key demographic context: Only include demographics here that have a direct bearing on design decisions. Screen size, device type, connectivity constraints, and language context are often relevant. Age and postcode rarely are.

Proto-Personas vs Research-Backed Personas

A proto-persona is built from team assumptions before any research has been conducted. It is used to align everyone on initial hypotheses: who do we think we are designing for, and what do we think they need?

Proto-personas serve a genuine purpose. Starting a project with a shared, explicit set of assumptions -- however unverified -- is better than starting with implicit and divergent ones. They also give you something concrete to challenge when research begins.

But they must be clearly labelled as assumptions. A proto-persona should carry a visible marker -- "unvalidated" or "based on assumptions" -- so no one mistakes it for research-backed insight. As you conduct interviews and gather data, update the proto-persona to reflect what you actually found, or discard it entirely if the research reveals you were designing for the wrong person. Never present a proto-persona to stakeholders without making its unverified status explicit.

The failure mode to avoid: a proto-persona built in a workshop at the start of the project that quietly loses its "proto" label by sprint three, and is thereafter treated as evidence without anyone having done the research to support it.

Personas in the Broader Design Process

Personas sit at the foundation of the UX design process. They inform the problem framing that happens before ideation, they guide the prioritisation decisions that happen during design, and they provide the reference point for evaluating whether a solution actually serves the people it was built for.

A persona you cannot use to evaluate a design decision is not a persona -- it is a character profile. The test is simple: can you hold up a proposed design next to a persona and ask "would this work for this person?" and get a meaningful answer? If not, the persona needs more work.

If you are newer to the discipline and want to understand where personas sit in the wider picture of what UX design involves, what is UX design covers the foundations of the field.

---

On the Beginner UX Design and Intermediate UX Design courses at UX Academy, you build personas from real user research conducted on actual client briefs -- not invented scenarios. You interview real people, synthesise findings into a research-backed persona, and use it to drive design decisions through the rest of the project. That process -- learning to move from raw interview data to a document a whole team can use -- is what separates a designer who understands personas from one who just knows the template.