In UX design, what is a persona for, and what makes one evidence-based rather than decorative fiction?
answer
- a decision tool, not a portrait
- patterns across many participants
- goals and behaviours over demographics
- every attribute traces to a source
- dated, revisited and actually cited
basics
~20 sA persona is an archetype of a user segment that lets a team argue design decisions against real goals and behaviours. It is evidence-based when each attribute traces to patterns seen across research participants and it actually changes decisions.
solid answer
~50 sA persona compresses research about one user segment into a named archetype — goals, behaviours, context, frustrations — so a team can ask “would this person succeed here?” instead of arguing from personal preference. What makes it evidence-based is **provenance**: it is synthesised from patterns seen across several participants, each attribute can be traced back to observations, and segments are split by **goals and behaviours** that genuinely differ, not by age or job title. Decorative personas are the opposite: invented in a workshop, padded with a stock photo, hobbies and a favourite brand that change no decision, and never revisited. A quick test on a smart-home app persona: delete each detail in turn and ask whether any design call would change — if none would, that detail was decoration. Real personas are dated, name their sources, and get updated when new evidence contradicts them.
go deeper
Recall that a persona is a decision tool built from research patterns, and tell goals-and-behaviour content apart from decorative demographic detail.
Explain how segments are separated by behavioural variables, why each attribute must trace to observations, and why an averaged persona misleads a team.
Show how you would audit an existing persona set: trace sources, delete-test details, merge personas that make the same choices, and check whether decisions cite them.
Weigh what keeping personas alive costs against the decisions they steer, and decide when a lighter artefact or a jobs framing serves the organisation better.
## What a persona is for A **persona** is a named archetype that stands in for a segment of users who share goals, behaviours and constraints. Its job is not to describe a customer beautifully; it is to give a team a shared, concrete answer to “who are we designing for?” so that arguments move from “I would want…” to “would *this* person succeed here?”. Alan Cooper's goal-directed design popularised the tool for exactly that reason: without a defined user, “the user” becomes **elastic** — each person stretches it to fit the feature they already favour. A persona earns its keep when it **changes decisions**: which scenario the default flow optimises for, which capability is cut, which edge case is promoted to a first-class path. ## Where the evidence comes from An evidence-based persona is **synthesised**, not imagined. How the underlying studies are planned and run is a discipline of its own; what matters for the artefact is provenance: - it is built from **patterns across several participants**, not from one memorable interview; - segments are separated by **behavioural and goal variables** that actually differ — how much control someone wants, how much setup effort they tolerate, who else lives with the system — not by age bands or job titles; - each attribute can be **traced** to observations, quotes or data, ideally with a note of where; - it states its **date and scope**: which research, which market, which product version. For a smart-home control app, research might reveal two genuinely different patterns: a **household configurer** who enjoys building automations and tolerates setup friction, and a **household member who lives with the automations** but never chose them and mainly wants a reliable manual override. Those two differ in goals and behaviour, so they produce different design decisions — who is told when a schedule changes, whether an override is one tap away, how much a scene exposes. ## What goes in, and what earns its place | Element | Earns its place when… | Is decoration when… | |---|---|---| | Goals | they differ from other personas and drive priorities | they are generic (“wants an easy life”) | | Behaviours and context | they constrain design (a renter who cannot rewire, a shared home) | they are lifestyle colour | | Frustrations | they are observed, with some sense of frequency or severity | they are guessed | | Demographics | they correlate with a design-relevant constraint | they are there to look realistic | | Name and image | they aid memory without stereotyping | they anchor the team on appearance | | Quote | it is a real, representative quote | it is invented copy | ## Failure modes that turn personas into fiction - **Workshop-invented, presented as research**: assumptions dressed up with a photo and a confident layout. - **The averaged persona**: blending every participant into one “typical” user who resembles nobody and whose needs contradict each other. - **Demographic padding**: age, hobbies and favourite brands that change no decision and invite stereotypes. - **Persona sprawl**: a dozen personas, so every feature finds a sponsor and nothing is prioritised; naming a **primary persona** whose needs set the default is the usual discipline. - **Frozen personas**: written once and never revisited while the product and its users change. - **Shelfware**: a poster nobody cites when decisions are actually made. ## A test you can run on any persona 1. **Trace**: pick three attributes and ask where each came from. “We assumed” is an honest answer only if the persona is labelled provisional. 2. **Delete**: remove each detail in turn and ask whether any design decision would change. If none would, the detail is decoration. 3. **Distinguish**: compare two personas side by side; if they would make the same choices in the product, they are one segment. 4. **Use**: find the last three contested decisions and check whether the persona was cited in any of them. 5. **Date**: check when it was last revised against new evidence. ## Keeping them honest over time Personas decay as the product, the market and the user base shift. Teams that keep them useful attach sources and a review date, merge or retire personas that stop differing, and fold in contradicting evidence from support, analytics and new studies rather than defending the original. The same discipline applies on the web, on native mobile and on a device's own companion app: the persona describes people and their goals, not a platform. Honest personas are allowed to be wrong; they are not allowed to be unexamined.
- How many personas should a product carry, and why does the number matter?As many as there are genuinely distinct goal-and-behaviour patterns, which is usually a handful. Too many and every feature finds a sponsor, so nothing gets prioritised. Teams commonly name one primary persona whose needs set the default experience and treat the others as constraints the design must not break.
- Should a persona carry a name, a photo and an age?Only as far as they help. A name and image make a persona memorable and easy to cite, but a photo and demographics can anchor the team on appearance and invite stereotypes. Keep a demographic detail when it maps to a design-relevant constraint, such as renting rather than owning the home; otherwise many teams drop it or use a neutral illustration.
- What is the “elastic user” problem, and how does a persona address it?When “the user” is undefined, each person stretches it to justify the feature they already want, so debates never converge. A persona pins the user down to specific goals and constraints, so a proposal can be tested against a shared reference rather than against whoever argues loudest.
A persona is like a wanted poster drawn from several witness statements: useful because every feature traces to what someone saw, and dangerous if the artist simply draws a face they like.
saying these in an interview costs you the question
- A persona is mostly a demographic profile with a name, photo and hobbies.
- A persona written in a workshop is research-based if the whole team agreed on it.
- More personas are always better because they cover more of the user base.
- Averaging every interviewee into one persona produces the most representative user.
- Once a persona is published it is finished and never needs revisiting.