01 / UNDERSTAND
What are user personas?
User personas are concise representations of patterns in people’s goals, behaviours and circumstances. They help a team carry research into design decisions without returning to every interview each time. A persona represents a useful pattern, not a real individual or every person in a group.
Build the profile from evidence relevant to the service. A name or photograph may aid recognition, but neither explains what someone needs. If a profile starts from team assumptions, label it a proto persona and plan how to investigate it.
Why use personas?
Teams can agree that a service should be “simple” while imagining different users. Personas make those assumptions discussable: simple for whom, doing what, under which constraints?
Use the profiles to compare consequences. An option that speeds up a familiar task may make an unfamiliar decision harder. The useful output is a reason for a design choice, not a memorable fictional biography.
When to use personas
USE IT WHEN
Research suggests distinct goals or behaviours that change what the service must support.
Several teams need a shared reference when making product decisions.
A design discussion keeps returning to an undefined “typical user”.
When to choose another method
Start with User Interviews when the profiles would mostly reflect assumptions.
Use a Customer Journey Map when sequence and touchpoints are the main question.
Use direct usability research to evaluate a design. Personas do not test it for you.
What you’ll need
Define the service, the people in scope and the decision ahead. Gather interviews, observations and other relevant evidence. Keep source identifiers and context with each account, respecting participants’ privacy. Include contradictory cases. A profile needs a traceable basis, not a prescribed number of demographic details.
What belongs in a persona?
Keep the elements that help answer your question and support a decision.
What the person is trying to achieve in the situation you are designing for.
What shapes their options, including time, access, support and prior knowledge.
What they do, how they decide and the workarounds they use.
What must be possible, and what currently makes it difficult.
The accounts behind the pattern, conflicting cases and remaining assumptions.
What the team should support differently, and how that proposal will be tested.
02 / PUT IT INTO PRACTICE
How to create user personas
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Set the scope
Name the decision the personas should inform and who is in scope.
For course enrolment, focus on choosing and joining a course, not the learner’s whole life.
02
Prepare the evidence
Extract relevant goals, behaviours and constraints from individual accounts.
Keep account identifiers and distinguish reported behaviour from your interpretation.
03
Compare patterns
Group accounts by differences that could change the design. Look for exceptions.
Compare uncertainty about course fit with certainty about the module needed.
04
Draft the profiles
Write concise profiles using the same fields. Omit details that do not help the decision.
Use “Exploring a new subject” rather than an invented lifestyle biography.
05
Challenge the distinction
Check each claim against sources and ask where a person could fit more than one profile.
A returning learner may need exploratory support in an unfamiliar subject.
06
Apply and review
Use the profiles to compare options, then plan research to test your decision.
Evaluate course comparison and direct lookup with people in both situations.
Example: choosing an evening course
Illustrative scenario, not research findings: a team is redesigning enrolment for evening courses. Two candidate patterns emerge from invented accounts: Maya, who is comparing unfamiliar subjects, and Luca, who is returning to complete a known qualification. Both names and profiles are fictional.
Maya needs to judge fit, prerequisites and realistic time commitment. Luca needs to find the correct module and check whether its timetable is workable. Both may be confident online; age does not explain this difference.
The team proposes clear comparison information alongside a direct route to a named course. It must test whether those routes help real learners. The profiles do not establish how many people need either route, or whether the same person changes approach between courses.
Two people, different enrolment decisions
Fictional persona examples. Names, situations and behaviours are invented, not research findings.
Maya
Exploring a new subject
- Context
- Works full time and is considering an evening photography course.
- Goal
- Choose a course she can realistically attend and complete.
- Behaviour in this scenario
- Compares beginner courses, checks prerequisites and looks for weekly workload.
- Friction
- Course descriptions do not make the expected starting level clear.
- Need
- A useful comparison of fit, workload and prerequisites.
- Design direction to test
- Test whether course comparisons help her judge fit before applying.
Luca
Returning for a known module
- Context
- Has completed an introductory course and wants its next module.
- Goal
- Find the correct continuation and confirm a workable timetable.
- Behaviour in this scenario
- Searches by module name and checks dates before reading general course information.
- Friction
- Similar module titles make the continuation route uncertain.
- Need
- A direct route to the right module, with eligibility and dates.
- Design direction to test
- Test whether a continuation route helps him choose the right module.
Interpretation / A person is not a permanent category.
Maya could use Luca’s approach for a familiar course. Test the situation and the decision, not a demographic stereotype.
03 / BELOW THE SURFACE
Below the surface: a person or a situation?
A useful persona can become misleading when a temporary situation is treated as a permanent identity. In the course example, a returning learner may behave like an explorer when changing subject. Calling them two fixed types could encourage the team to show each person only one route.
01 / DECISION
What changes?
Which design requirement differs between the profiles?
02 / CONTEXT
What is contextual?
Could the same person move between these patterns?
03 / EVIDENCE
What would disprove it?
Which contradictory account would make you revise or merge a profile?
Ask whether the distinction changes the decision. If both profiles need the same information in the same order, separate personas may add little. If the difference depends on familiarity with a particular course, model that condition explicitly rather than assuming a lifelong trait.
Try each design against both situations and record what breaks. Prefer a service that lets someone change approach over one that guesses their identity. This is an editorial test of the profiles’ usefulness, not a validated segmentation framework. Revisit the distinction when research contradicts it.
User Personas template
Use the two page canvas to build one evidence based profile, then compare it with another pattern before making a design decision. The first page captures goals, context, behaviours, needs, evidence and implications. Below the surface asks whether the distinction reflects the person or the situation, what could disprove it and what to test next.
Download the PDF or open the editable version to complete its 18 fields in a PDF reader that supports forms. Save a copy for each profile and keep source identifiers with your claims.
Practical tips
Give profiles descriptive labels that point to a relevant goal or behaviour.
Keep evidence identifiers close to the claims they support.
Include accessibility and support needs when evidenced; do not infer them from age.
Review profiles when the audience, service or available evidence changes.
Common mistakes
Inventing a backstory and presenting it as research.
Making a profile for every demographic group.
Treating a qualitative pattern as a population percentage.
Using a persona to dismiss contradictory feedback or exclude people from a service.
What you’ll get
A compact set of research summaries the team can question and use. Each profile should connect a meaningful pattern to a design implication and its evidence. Keep unresolved questions visible, then test the resulting choices with people rather than treating the profiles as proof.