After user research you will have pages of notes and quotes. A team cannot carry all of that into every meeting. User personas pack the important patterns into short profiles of realistic user types, so everyone designs for the same people instead of for “the user” – a vague figure who usually looks like whoever is talking.
What a persona is (and is not)
A persona is a fictional but research-based description of a group of users who share similar goals, behaviours and frustrations. It has a name and a face so it is easy to remember, but every detail should trace back to something you learned from real people.
| A persona is… | A persona is not… |
|---|---|
| Based on patterns across several participants | A copy of one person you interviewed |
| Focused on goals, behaviours and pain points | A list of age, star sign and favourite film |
| A shared reference for decisions | A poster made once and forgotten |
| One of a small set (usually 2–4) | An attempt to represent every possible user |
Watch out: Personas made up in a meeting without research are called “proto-personas” or assumption personas. They can be a starting point, but label them clearly and replace them with research-based versions as soon as you can. Otherwise you risk designing around stereotypes.
What to include
Keep the persona to one page. Include only details that could change a design decision.
- Name and short description – e.g. “Karthik, the weekend traveller”.
- Context – where and how they use the product: device, connection, time pressure, language preference.
- Goals – what they are trying to achieve, in their own words.
- Behaviours – what they currently do, including workarounds.
- Pain points – what frustrates or worries them.
- A real quote from research (anonymised) that captures their attitude.
- Accessibility needs where relevant, such as low vision or using a screen reader.
A worked example: bus-ticket app
From eight interviews about intercity bus travel, two clear groups appeared. Here is one of them:
| Section | Persona: Karthik, the weekend traveller |
|---|---|
| Context | Works in Chennai, travels home to Madurai most weekends. Books on his phone during his commute, often on a crowded train with weak mobile data. |
| Goals | Get a window seat on a night bus at a fair price; be sure the booking went through. |
| Behaviours | Compares two or three apps; books on Wednesday for Friday night; takes a screenshot of every ticket. |
| Pain points | Payment fails but money is debited; boarding point details are unclear; refund rules are hidden. |
| Quote | “I just want to know the ticket is confirmed. Then I can relax.” |
The second persona, a parent booking for elderly relatives, had quite different needs: larger text, booking for someone else, and clear instructions to share on WhatsApp. Designing for both made the team add a “Share ticket details” option that helped Karthik too.
Steps to create a persona
- Review your research notes and affinity map from the previous lesson.
- Find the variables that split users into groups – for example, how often they travel and who they book for.
- Cluster participants who behave similarly on those variables.
- For each cluster, write goals, behaviours and pain points using real evidence.
- Give it a memorable name and choose a respectful, realistic photo or illustration.
- Review the draft with teammates who joined the research to check it rings true.
Tip: Behaviour matters more than demographics. Two people of the same age and city can use an app in completely different ways. Group people by what they do and need, not by who they look like on paper.
Related tools: empathy maps and journey maps
An empathy map splits what a user says, thinks, does and feels into four boxes and is a quick way to start a persona. A journey map follows one persona step by step through a task, showing actions, feelings and pain points at each stage. Journey maps are excellent for spotting where to focus – for Karthik, the moment after payment is the emotional low point.
Keeping user personas useful
Personas only help if people use them. Put them at the start of your Figma or FigJam file, refer to them by name in reviews (“Would Karthik understand this label on a slow connection?”), and update them when new research changes what you know.
Personas also shape the next step, information architecture, because the way your users think about content should decide how you organise it.