Theory
Design for a person, not an average
Your research on FestConnect produced a pile of findings: ages, tech levels, frustrations, goals. Useful: but hard to DESIGN against. "The average user is 19.5, moderately tech-savvy" describes NOBODY. No real person is average.
So good teams do something clever: they turn the research into a CHARACTER. Meet Rahul, 18, first-year, Gujarati-medium, cracked phone, terrified of making a mistake on a form. Suddenly the team is not designing for an average: they are designing for Rahul. That character is a persona.
Theory
Persona, formally
A persona is a fictional but realistic character representing a key user group, built FROM user research (not from imagination).
The crucial word is FROM research: a persona is not a made-up daydream, it is a synthesis of what you actually LEARNED, given a human face so the whole team can hold it in mind.
Purpose: make abstract users concrete, memorable and empathisable, so design decisions get tested against a real-feeling person ("would Rahul understand this button?") instead of a faceless statistic. It also ALIGNS the team on exactly who they are building for.
At a glance
What a persona contains
| Element | Purpose | Rahul (FestConnect) |
|---|---|---|
| Name + photo | Humanise, make memorable | Rahul Patel, first-year |
| Demographics + context | Ground the person | 18, Gujarati-medium, budget phone, hostel wifi |
| Goals | What they want to achieve | Register for Garba Night quickly, without errors |
| Needs | What the design must provide | Simple steps, clear labels, forgiveness for mistakes |
| Pain points | Frustrations to solve | Fears filling forms wrong; small text hard to read |
| Quote | Capture the mindset | 'Please do not let me mess this up.' |
Theory
FestConnect needs at least two
One persona is rarely enough, because products serve different USER GROUPS with different goals. FestConnect has (at least) two:
- Rahul, the first-year STUDENT: goal = register easily; needs simplicity and reassurance
- Priya, the fest ORGANISER: goal = see who has registered, manage events, export lists; needs powerful overview tools and speed
Designing only for Rahul gives a lovely registration but a useless admin side; designing only for Priya gives a powerful dashboard that terrifies first-years. Products usually have a small set of 2 to 4 primary personas: enough to cover the real user groups, few enough to stay focused.
Quiz
What crucially separates a good persona from a made-up character?
- A good persona has a more creative backstory
- A good persona is built FROM real user research; a made-up one comes from imagination
- A good persona must be a real, named individual the team knows
- There is no difference; personas are always fictional guesses
Show the answer
A good persona is built FROM real user research; a made-up one comes from imagination
The line between a useful persona and a dangerous one is EVIDENCE: a good persona synthesises real research findings (Rahul's fear of forms came from watching real first-years), while an imagined one just encodes the designer's assumptions in a human costume: worse than no persona, because it FEELS trustworthy while being fiction. Option A prizes creativity, which is beside the point (and risks irrelevant detail). Option C over-corrects: a persona is a REPRESENTATIVE archetype, not one literal individual. Option D collapses the distinction the lesson exists to draw. Personas are fictional characters grounded in factual research.
Think first
Build a persona in five steps
You have interview notes from 12 FestConnect users. Outline the steps to turn them into personas. Think about it as grouping, then tap.
Show the answer
1: Gather the research (the 12 interviews, plus any analytics). 2: Find patterns: look for recurring goals, behaviours and frustrations across the notes. 3: Group into segments: the patterns cluster into a few distinct user TYPES (nervous first-years; busy organisers). 4: Flesh each out: give each cluster goals, needs, pain points, context: from the DATA, not invention. 5: Humanise: add a name, photo and quote so the team remembers and empathises. The output: 2-4 research-grounded personas like Rahul and Priya. The discipline is that every trait traces back to something a real user actually showed you.
Watch out
Persona slips
Inventing personas from imagination: a persona not grounded in research is just your assumptions wearing a face: the very trap UCD warns against.
Stereotyping: 'old people cannot use phones' is lazy and often wrong; base traits on evidence, not clichs.
Irrelevant detail: Rahul's favourite movie does not help you design a form; include only what informs design (goals, needs, context, pains).
One persona for everyone: cover the real distinct groups (student AND organiser), but keep the set small (2-4).
Theory
But where does the research come from?
Personas are only as good as the research beneath them, and the single richest source of that research is TALKING to users: the interview. Next lesson teaches how to conduct one WELL: how to ask questions that reveal truth instead of flattery, and how to avoid corrupting the very answers you came for. Then Unit 2 closes with usability testing, watching users actually USE the design.
Summary
Key takeaways
- A persona is a fictional but realistic character representing a key user group, built FROM user research.
- It makes abstract users concrete and memorable, so the team designs for a specific person (Rahul) not an average.
- Contents: name + photo, demographics/context, goals, needs, pain points, sometimes a quote and scenario.
- Ground every trait in research; a made-up persona just encodes assumptions.
- Products usually have 2-4 primary personas covering distinct user groups (FestConnect: student Rahul + organiser Priya).
- Build them by gathering research, finding patterns, grouping into segments, fleshing out, and humanising.
- Memory hook: design for a person you can picture, not a statistic no one is.