User persona template: personas from interview evidence, not guesses

The form is the easy part of a user persona template. What makes a persona useful is the evidence behind each line, so this one adds what a blank form leaves out: where each answer came from.

Seven of the eight fields below come with the interview question that fills them, and every line gets a grade: seen, said or guessed. If sales and support keep telling different stories about your users, our product discovery services run those interviews with your team and turn them into decisions you can build on.

What is a user persona?

A user persona is a fictional profile of one type of user, built from research. The person is invented, but the goals, behaviours and pain points come from real people you studied.

The U.S. government's Digital.gov guide to user profiles describes personas as fictional, research-based representations of user types. It says they help teams make design decisions grounded in real goals, behaviours and pain points. So a persona is not a job title, a market segment or a picture of the customer you wish you had.

Alan Cooper made the case for personas in software design in his book The Inmates Are Running the Asylum (Sams, 1999). The contents of the 2004 second edition include the section "Personas End Feature Debates". A shared persona lets a team argue about one specific user instead of a vague idea of "the user".

The user persona template, field by field

This user persona template has a name and eight fields. Each field pairs a prompt with the evidence that fills it, and seven add the interview question that finds it, because the decision is one for your own team. Use the table as your research plan first and as a form second.

Then grade every line, because the grade is what keeps guesses out of the final version.

• Seen. You watched it happen, or your usage data shows it.
• Said. A participant told you, but you have not watched it.
• Guessed. It is a team assumption that nobody has tested yet.

Seen outranks said for a simple reason. Wendy Stengel of the Library of Congress said in a Digital.gov post that you should look at what people do more than what they say, because people are not the most reliable lenses onto their own behaviour.

Here is the blank version. Copy it into your own document, one copy per persona.

Persona name:
Role:
Goal:
Context:
Behaviour today:
Pain points:
Workarounds:
Their words (a real quote):
Decision this persona changes:

For every line, add:
Source: interview, observation, ticket or usage data
Grade: seen, said or guessed
Last checked: date

User persona interview questions to ask

The strongest user persona questions ask about the last real time something happened, not about opinions or future plans. A past event gives you behaviour you can check, while a hypothetical gives you a guess.

This is the same rule as the interview step in our product discovery process. Keep adding people in a group until the answers start to repeat.

Goals and context

• Tell me about last week in your role.
• When did you last need to do this, and what started it?
• What were you trying to get done?
• Who else was involved?

Behaviour and workarounds

• Walk me through the last time you did this, step by step.
• What tools or files did you have open?
• What did you try before you settled on this way of working?

Pain points and stakes

• What was the hardest part of that?
• What happened the last time this went wrong?
• What have you spent time or money on to fix it?

Skip "would you use this?" and "do you like this idea?". Those questions test your idea, and a persona describes the person. When you have a prototype to show, switch to usability testing questions.

How to build a persona from interview evidence

Start with your assumptions, test them against interviews and usage data, then group what recurs into a small set of user types. The steps below adapt Digital.gov's guidance, with a grade added to every line.

1. Write a proto-persona. Digital.gov describes this as a way to collect your assumptions and hypotheses into an outline you can verify. Grade every line guessed.
2. Gather what you already hold. Read support tickets, sales notes, surveys and analytics. These sources often settle the easy lines before you book a single call.
3. Interview and observe. Talk to people in each group and watch them work where you can. One Library of Congress team ran more than 20 contextual interviews plus an extensive survey for a single platform, and most startups can start far smaller.
4. Sort for patterns. Group your interview notes in an affinity map, then mark frequently observed goals, motivations, behaviours, pain points and potential harms, such as lack of consent. Keep the outliers too, because they can point to a need nobody has named.
5. Challenge the groups. Digital.gov suggests three "who" questions: who is included, who is overlooked and who is deciding who is included.
6. Write it and link the research. Fill in the template and give each persona a name. Link each one to its research, so anyone can challenge a line that reads like a stereotype.
7. Keep updating it. Digital.gov's advice is to keep updating personas as your users change, so revisit the grades after each round of research and change whatever the new evidence contradicts.

User persona examples: one filled in

This invented example shows a persona for a bookkeeping product, with a source and a grade on each line. Only the structure carries over, because your own persona has to come from your own interviews.

Notice what the evidence removed. An early draft said Dana reconciles inside the app. The usage data showed that she exports to a spreadsheet, so that line was replaced.

Two grades are worth a second look. Her pain point stays said, because a support ticket reports a problem nobody watched. The last line is still guessed, which tells the team exactly what to test next.

For real user persona examples, Digital.gov's post on personas points to published sets from the National Archives and the Library of Congress, plus a persona template from the U.S. Department of Agriculture.

User persona vs buyer persona

A user persona describes who uses the product, and a buyer persona describes who decides to buy it. In many business products these are different people with different goals, so you may need both.

The split is an old one: the second edition of Cooper's book has a section titled "It's a User Persona, Not a Buyer Persona". In our bookkeeping example, Dana uses the product every month, while the firm's owner approves the purchase. The main difference is who each persona describes and what you build it from.

Persona, proto-persona or archetype: which do you need?

Use a proto-persona to list assumptions, an archetype to group shared behaviours and a persona when a team needs one character to design for. A user scenario then puts any of them in a real situation. Digital.gov says archetypes focus on behaviours rather than individuals. For an early product, that is often enough.

Digital.gov's time estimates are in the table, as of October 2026, and it gives none for a proto-persona. It does not say whether they cover the research itself, so budget your interviews separately. Pick the lightest format that fits the decision in front of you.

Why personas fail, and how to keep yours useful

Personas fail when nobody can trace them to research or when they stop changing. Keeping a source, a grade and a date on every line deals with both.

• Filler details. Digital.gov lists demographic information such as gender and age as part of a persona. We leave it out of this template unless it changes a product decision.
• Stereotypes. A line with no source is often a stereotype, so grade it guessed until someone can point to the research.
• Recognizable people. Digital.gov advises against a photo of someone you interviewed who may be recognized. Keep quotes anonymous for the same reason.
• Too many personas. Cooper's book has sections titled "Design for Just One Person" and "Primary Personas". Pick the persona whose needs decide the next release.
• Stale personas. The date on each line shows what needs checking next.
• No decision attached. If a persona changes nothing in your roadmap, it is decoration. The decision field makes the point before anyone files it away.

How we run the interviews behind your personas

We recruit and run the customer interviews, then hand you the notes and the patterns we found, so each line of your persona can point to something a user said or did. That research runs alongside a product discovery workshop with your team, and it pairs with idea validation when you still need to prove the problem is worth solving.

The work is led by Roger Grekos, our Co-Founder for product, project and scale. Every engagement is under an NDA, and the IP is always yours.

Frequently asked questions