When to use it
Once you have done the research. Personas synthesize data that exists; they are not the starting point, they are the result.
With no research, what you are building is a proto-persona — the team's hypothesis about who the user is. That is legitimate and useful, and it should be called by its name. The problem starts when a proto-persona is presented as a Persona and the team begins deciding on assumptions believing it is deciding on evidence.
Do not confuse them with marketing segments or with the data team's segmentation either. Those group by who buys and how much; a Persona groups by how someone behaves and why. They can coexist, and it is worth spelling out the difference, because that is the first question the business side asks.
Before you use it
Group by behaviour, not demographics. Two people of the same age in the same district can behave in opposite ways. Demographics only earn a place if they change the behaviour.
Motivation is the field that pays off most. Of everything on the card, the one that unblocks the most decisions is why this person does what they do. If you only have time to polish one, polish that.
Three or four, maximum. With more, the team does not use them: choosing between seven cards costs more than looking at none. They are ranked primary, secondary and tertiary, and that ranking is what settles design ties.
Consider an anti-persona. It is not one more persona: it is the person the product explicitly does not serve. You write it so you can name it when someone asks for a feature that only helps them. It does not count towards the limit of four.
Every claim with its evidence. A field with no backing is an assumption, and it gets marked as one. That is what lets you defend them when someone asks where it came from.
Building them is not the work; getting them used is. It is the most expensive mistake with this deliverable, which is why the template carries the adoption plan inside it.
Everything in brackets gets replaced. The worked example downloads separately, as a second file.
The document
One card per persona, repeated as many times as you have, up to four.
Study: [study name] Sources: [n interviews, survey of n, analytics for (period)] Date: [DD/MM/YYYY] · Next review: [DD/MM/YYYY]
How these differ from the segmentation you already have
[In two sentences: what the business or data segmentation groups by, and what this groups by. They do not compete.]
[Fictional name] · [primary / secondary / tertiary / anti-persona]
[Photo or illustration. An archetype, not a real person: do not use the face of someone in your sample.]
"[A verbatim quote from a session, not invented. The one that best sums up how they see the problem.]"
Motivation
[Why they do what they do. What they are trying to achieve, in their terms and not the product's.]
Evidence: [where it comes from — P1, P4, P7; or the survey question]
Needs and pain points
- [Need] · evidence: [ ]
- [Pain point] · evidence: [ ]
- [Pain point] · evidence: [ ]
Observed behaviours
- [What they do, specifically and with its real frequency] · evidence: [X of N participants]
- [What they do] · evidence: [ ]
Context
[Where and when this happens: device, moment, who with, how much time, what interruptions.]
What sets this persona apart from the others
[How you would recognize them in conversation. This is the field that keeps the four cards from ending up alike.]
Scenario
[A concrete situation, in three or four sentences, where this persona runs into the problem. Without naming screens or buttons.]
Assumptions with no evidence
[What the team believes but did not measure. It goes here and not above, and it gets reviewed at the next update.]
Adoption plan
Without this the card is a poster: it may look beautiful stuck on the wall, but nobody is going to use it. It gets filled in before you present them, not after.
Presentation · [date]
The order that works: what they are and why they were built · how you arrived at them · how they differ from the existing segmentation · the personas, primary and secondary, and what distinguishes them from each other · next steps.
Questions to expect
| Question that will come up | Prepared answer |
|---|---|
| Does this replace [team]'s segmentation? | [ ] |
| How many people did this come from? | [ ] |
| How often are they updated? | [ ] |
| [ ] | [ ] |
After the presentation
| Action | Owner | Date |
|---|---|---|
| Applied workshop with [team] | [ ] | [ ] |
| Permanent home in [where] | [ ] | [ ] |
| Review which initiatives used them | [ ] | [ ] |
Signal that they were adopted: [what you will be able to observe in three months if this worked — that they turn up named in a ticket, in a design discussion, in a prioritization call].
Method note and limitations
Built from [n] interviews and [quantitative sources]. The patterns describe behaviours observed in the sample, not proportions of the population.
These personas do not incorporate an inclusion lens — gender, disability, background, and other characteristics that make someone unique and change their relationship with the product. They are a first step on variability, not a complete map of it.
They expire. Review on [date]: if the product or the market changed, the card describes someone who no longer exists.
The filled-in version
The same document written end to end as a case: an invented study on the transfer flow of a retail banking app. It shows you the level of detail each field expects before you face the empty version. It downloads separately.
Invented reference case. The bank, the study and the people do not exist. The evidence figures are written so you can see how a claim gets cited, not because anyone measured them. If you reuse this file, replace all of it: an example left inside without saying so is exactly the defect this template asks you to flag.
How to read it. Notice what is missing. There is no district, no marital status and no phone brand, because in this study none of the three changed the behaviour. The only demographic fact that survived is Marisol's age, and it survived because it explains where her way of double-checking comes from.
Study: Transfer flow redesign · retail banking mobile app Sources: 14 in-depth interviews, survey of 380 customers with an active account, analytics from March to August Date: 12/09/2026 · Next review: 12/03/2027
How these differ from the segmentation you already have
Commercial segmentation groups by income and number of products held: it says what a customer is worth. These cards group by how someone behaves in the face of the risk of getting it wrong when moving money, which is what decides the design of the flow. A high-income and a mid-income customer can land on the same card. They do not compete: the first says who is worth selling to, the second says how it has to work.
Marisol Fuentes · primary
Archetype illustration, not a participant's photo.
"I check three times before I tap. If I get the account wrong, I don't know who I'd complain to."
Motivation
She wants to finish the transfer knowing it reached the right person. She is not after speed: she is after confirmation. She has kept the books of a small company for 22 years, and there a payment error surfaces weeks later and she pays for it in her own hours. She brings that rule to the bank.
Evidence: P2, P5, P9, P11 describe repeated checking without being asked about it. In the survey, 61% list "check the details before confirming" among their two most important steps.
Needs and pain points
- Needs to see the recipient's name, not just the account number, before confirming · evidence: P2, P5, P9, P11, P14
- Is bothered that the receipt arrives by email and does not stay in the app · evidence: 9 of 14 participants raise it unprompted
- Does not understand what a transfer sitting "in process" means, or how long that lasts · evidence: P5, P9; 34% of the survey report having called the contact centre about this
Observed behaviours
- Transfers to the same group of 5 or 6 recipients, nearly always the same ones · evidence: 11 of 14 participants; median distinct recipients over 6 months is 7
- Sends a small test amount before a first transfer to someone new · evidence: 6 of 14 participants
- Makes large transfers from the computer, not the phone · evidence: 8 of 14; in analytics, 71% of transfers over CLP 500,000 come from web
Context
Almost always at night, at home, phone in hand with the TV on. Sometimes with someone beside her asking whether she has paid yet. The phone is her work phone and her home phone at once, and it runs out of battery before eight.
What sets this persona apart from the others
Marisol is the only one who verifies after confirming: she goes back into the app to see whether the transfer shows up. The other cards trust the success message and close.
Scenario
It is Thursday night. Marisol has to pay a new supplier before Friday or the delivery falls through. She has the account number in a WhatsApp photo of a handwritten note. She is not sure whether the 6 is a 6 or an 8. It is eleven o'clock, there is nobody to ask, and the payment cannot wait until Monday.
Assumptions with no evidence
- We believe the test transfer would happen less often if the recipient's full name were shown, but we did not measure it: no participant used a flow that showed it.
- We believe using the computer for large amounts is about trust and not screen size. Both explanations appear in the interviews and we did not separate them.
Ignacio Vergara · anti-persona
Who we are not designing for. This card does not describe a customer to serve better: it describes the customer whose requests, if granted, break the flow for everyone else. It is written precisely so it can be named in a meeting.
He works across three platforms, moves money between instruments several times a week, and asks for the same thing in every open-ended survey: real-time charts, scheduled orders and an API. Each of those adds a step or a screen to the flow Marisol walks at night with the TV on.
Why this card exists: he shows up in 3 of 14 interviews and is the loudest profile in the feedback channels, so his voice weighs more than his size. Without the card, the prioritization discussion treats him as "the advanced user" and ends up justifying features nobody else asked for.
What it does not mean: that he is not a customer, or that he does not matter. It means this app is not where he gets served.
Adoption plan
Presentation · 26/09/2026
The order that works: what they are and why they were built · how we got to them · how they differ from the existing segmentation · the personas, primary and secondary, and what distinguishes them · next steps.
Anticipated frequently asked questions
| Question that will come up | Prepared answer |
|---|---|
| Does this replace the Business Intelligence segmentation? | No. That one says what a customer is worth; this one says how they behave when transferring. They are used together and answer different questions. |
| How many people did this come from? | 14 interviews, 380 survey responses and six months of analytics. The cards describe patterns in that sample, not percentages of the customer base. |
| How often do they get updated? | In March, or sooner if the transfer flow changes. The date is written on the card. |
| Why is there no young persona? | Because age did not separate behaviours in this sample: what separated them was tolerance for irreversible error. If that difference shows up, we add one. |
After the presentation
| Action | Owner | Date |
|---|---|---|
| Application workshop with the Transfers team | Head of Research | 03/10/2026 |
| Permanent home on the Product wiki, linked from the board | Research | 03/10/2026 |
| Review which initiatives actually used them | Research | 20/12/2026 |
Sign they were adopted: that in December "Marisol" shows up written by someone outside the research team — in an acceptance criterion, a design comment, or the justification for a priority.
Method note and limitations
Built from 14 in-depth interviews, a survey of 380 customers with an active account, and six months of analytics. The patterns describe behaviours observed in the sample, not proportions of the population.
These Personas do not incorporate an inclusion lens — gender, disability, origin, and other characteristics that make someone unique and change their relationship with the product. This is a first step on variability, not a complete map of it.
They expire. Review on 12/03/2027: if the product or the market changed, the card describes someone who no longer exists.
A worked example
On a retail project, the attributes that paid off were not the generic ones but these four, in this order:
Motivation — what they want and why they are acting. It turned out to be the most relevant aspect of all: identifying the driver and how it tied to their relationship with the company.
Relationship with the company — needs, pains and expectations towards it specifically, not towards the category in general.
How they differ from other profiles — how you would recognize them if you saw or talked to them.
How they buy — the concrete behaviour that separates them from the rest.
The final presentation was organised in five blocks: what Personas are and why they were built, the methodology, the difference from the internal business-intelligence segmentation, the detail of the primary and secondary ones, and next steps. That third block — the difference from the segmentation that already existed — is the one that prevented the most questions.
The full process, with its eight stages and what went wrong at each, is in Cómo construí(r) las User Personas (in Spanish).
This account lives here only. The example that downloads is a different one, invented, and sits further up.
Check before using it
- Does every claim carry its evidence, or are there unmarked assumptions?
- Are there four or fewer?
- Are they grouped by behaviour rather than demographics?
- Does "what sets this one apart" say something different on each card?
- Is there any demographic detail that does not change behaviour? Delete it.
- Is the photo an archetype rather than the face of someone from your sample?
- Does the adoption plan have owners and dates, or is it empty?
- Did you set a review date?
Grounding
The steps, the common mistakes and the card fields come from this site's User Personas entry.
The example's attributes and the presentation order come from Cómo construí(r) las User Personas, and the adoption plan from Cómo promover la adopción de las User Personas, which tells what worked and what did not on a real case. Both are in Spanish.
Personas are built from what comes out of the sessions: the research plan declares them as a deliverable and the interview guide collects the material.