User Persona Template, Built From Interviews Instead of Guesses

How many interviews and personas do you need?

A research-based persona needs 10–15 user interviews per user group, and interviewing stops once new sessions add no goals or frustrations you have not already heard.

That stopping point is data saturation: a further interview only repeats patterns you already hold. We set the interview count at 10–15 one-hour sessions per user group. The persona count we deliver per research program is 2–4, all from interview data, so a fifth cluster is a prompt to check whether two of them are really one.

Recruit on behavior, not demographics. A screener that asks how often people process invoices and who approves their work finds people who will split into clusters; one that asks age and company size does not. Write those behavior questions into the screener; in our program, participants are screened and scheduled in participant recruitment, a 3–6 day step of our 4–8 week program.

The primary persona is the one each main screen is designed for first; secondary personas must be served without breaking it. A negative persona is the user you deliberately leave out, such as an external auditor who opens the app once a year. Give each user group its own interview budget before you name a primary persona.

How do you turn interview notes into a user persona?

Turn interview notes into a user persona in six steps: tag, cluster, list behavioral variables, place each participant, name the clusters, then write and check every field.

Knowing how to create a user persona from interviews comes down to six steps of user research synthesis.

1. Tag every transcript. Mark each goal, behavior, frustration and workaround with the speaker's participant ID; our program does this in Dovetail.
2. Cluster the tags. Affinity mapping groups related notes on a board until themes appear.
3. List the behavioral variables. A behavioral variable is a range on which participants differ, such as "batches weekly" to "clears on arrival"; list every one your transcripts show, drawn from activities, attitudes, aptitudes, motivations and skills, and put the 5 that split participants most on the card's sliders.
4. Place each participant on each slider. Enter positions from 1 to 5 by participant ID in the CSV worksheet.
5. Name the clusters. Participants who sit together on 3 or more sliders form one persona, named after the role they share.
6. Write and check the fields. Fill each field of the user persona template from the cluster's evidence, add participant IDs, cut anything nobody said or did, then walk the team through the card.

The five variable categories in step 3 come from About Face, the interaction design book by Alan Cooper and his co-authors; the 3-of-5 clustering rule in step 5 is this template's own rule, not the book's. Step 4 is where the intro's two clumps appear: batch processors and exception chasers separate on four of the five sliders.

The email slider splits nobody: both groups chase approvers outside the app, so that frustration belongs on both cards. These steps sit inside the synthesis and readout step (4–7 days), the last of the 5 steps in our UX research process, and the research timeline for the full program runs 4–8 weeks.

Interviews capture what people say they do, so the key behaviors and tasks field gains most from watching people do the work in context, where our researchers observe 4–6 users in the real work setting. Open the worksheet and enter your first five participants before you name any cluster.

What does a finished user persona look like?

A finished user persona fits on one page and traces every line to user interviews, as this illustrative card for an invoice approval app shows.

Here is the same user persona template, filled in from 12 illustrative interviews with accounts payable clerks at mid-size companies. This user persona example is illustrative: the company, the people and the numbers are invented to show the method. The interviews produced two personas, Priya the batch processor (7 participants) and Marcus the exception chaser (5).

Marcus is the contrast. He clears each invoice on arrival, approves up to a spending limit and works only in the app; his frustration is a purchase order mismatch he must chase one invoice at a time. Side by side, the design implications split plainly: Priya needs bulk actions, Marcus needs fast single-invoice exceptions. Hold your own first draft against Priya's card and strike any line that no participant said or did.

Which persona fields drive design, and which are decoration?

An evidence field on a user persona template stays only if it changes a design decision; goals, context and frustrations from user interviews pass, while age and hobbies rarely do.

The test is one question per field: if this line changed, would a screen, a flow or a priority change? Psychographics, meaning values and attitudes, pass only when they shift behavior, for example a clerk who distrusts automatic matching and rechecks every total. Tech comfort passes when it varies as widely as it did for the Parents Connect community platform, which had to bridge the digital divide for parents with different levels of digital experience. The research base line is exempt, because it sources the card rather than describing the user, and a name passes when it is a first name the team can say; photos get their own answer in the FAQs.

The table sorts common persona fields by when to keep them and when to cut them.

Run the test on the personas you have now and strike every field that fails it before the next design review.

How do user personas feed journey maps and design reviews?

User personas feed design when each persona gets its own customer journey map, a named seat in design reviews and a ranked list of frustrations from user interviews.

Our research program pairs every persona with its own map, and our customer journey map template shows the lanes that persona fields flow into.

In design critiques, name the primary persona out loud: "would Priya bulk-approve this on a Thursday?" settles more than "would users like this?" For roadmaps, rank frustrations by participant tally first, so a problem heard from 6 of 12 participants outranks one heard from 2, then by the job's importance on the JTBD opportunity map. Roadmap advisors ask for the same cards: our UX consulting services page tells buyers to expect early requests for existing personas, journey maps and other past user research, since a consultant without user evidence can only guess.

A persona nobody cites cannot end a backlog fight, and leads who disagree about priorities with no shared personas are a signal to commission a UX research study. Add the primary persona's name to your design review agenda this week.

Why do teams stop using their user personas?

Teams drop user personas that never came from user interviews, blend two clusters, carry decorative fields or go stale, and each failure has a fix in the template.

• Assumptions shown as research. A proto-persona presented as a finding loses trust at the first question, so print the persona type tag.
• Averaged personas. A card that blends Priya and Marcus describes nobody, so split on the sliders in step 5.
• Too many personas. Seven cards hide which one is primary, so merge clusters back to 2–4.
• Demographics instead of behavior. Age and income give designers nothing to act on, so run the keep-or-cut test.
• No owner. A persona outside the review agenda turns into a poster, so give it a named owner.
• Stale personas. Old interviews describe old workflows, so refresh on a trigger, not a calendar.

Set the refresh trigger as a new user group, a new market or a new study, for example a product entering a market where users follow different workflows. Our startups industry page shows the trigger at an early stage: when a startup pivots from small businesses to mid-market buyers, its persona and onboarding both change, and designs stay low fidelity until interviews confirm who the new user is.

A user persona template is only as honest as the interviews behind each field, so check every card before it leaves your team.

Who should build user personas, your team or a partner?

Your team can build a user persona from user interviews it already holds; bring in a research partner when nobody has run 10–15 interviews per user group.

With recent interview recordings, use the template, the CSV worksheet and the six steps. With none, start with a proto-persona, label it as one, and plan interviews from its weakest fields.

A partner also earns its fee when the personas will decide a roadmap dispute, because the people plotting the dots should not be the people who wrote the roadmap, and when your interviews cover one user group but the product serves three.

When we run the study, the handoff includes 2–4 personas built from interview data, synthesized in Dovetail and walked through at a 90-minute readout, with 1 journey map per persona and a JTBD opportunity map. Budgets run $25,000–$60,000, and how the 4–8 week program is priced explains where a study lands in that range.

Start your first user persona template from the disagreements your team already has, because each argument about who the user is hides a behavioral variable nobody has measured. List each contested type as a proto-persona, and if your team cannot spare the hours for 10–15 interviews per group, send us the user types your team argues about. Every project begins with a free consultation and a fixed-scope proposal.

FAQs