Persona
A persona is a fictional but realistic profile that represents a key group of users, built from research rather than imagination. It describes the group's goals, needs, behaviors, frustrations, and context in the form of a specific person, so a product team can design and make decisions for someone concrete instead of a vague, generic "user."
How a Persona Works
Nielsen Norman Group defines a persona as a fictional yet realistic description of a typical or target user. A useful persona usually includes:
- A name, photo, and short description that make it memorable
- Goals and the tasks the person is trying to complete
- Pain points, concerns, and needs
- Behaviors and patterns of product use
- Relevant context, such as role, environment, or skill level
- A representative quote taken from research
Personas are built by grouping people with similar attitudes, goals, and behaviors found in research such as interviews, field studies, and surveys. NN/g describes three types that differ in rigor:
- Proto personas (lightweight) are created in a short workshop from what the team already knows, with no new research. They are fast but built on assumptions.
- Qualitative personas come from small-sample research, such as interviews with a few dozen people at most, segmented by shared goals and pain points. NN/g recommends this type for most teams.
- Statistical personas start from qualitative themes and then validate them with a large survey and statistical clustering.
Every detail should earn its place. Hobbies or favorite brands that do not affect design decisions add noise and can introduce stereotypes.
Why Personas Matter
People relate more easily to a concrete person than to aggregated statistics. A shared persona lets a team ask "Would Priya understand this screen?" and get a consistent answer, instead of each person quietly designing for themselves.
Personas also help with scope. When a feature request arrives, the team can ask which persona it serves and how important that persona is to the strategy. They connect to other artifacts too: empathy maps often feed persona creation, and personas give context to user stories and roadmap decisions.
The main risk is invention. A persona that is not grounded in evidence turns the team's assumptions into something that looks authoritative. Every attribute should trace back to user research, and personas need revisiting as the market and the product change.
Persona Example
A team building an internal expense tool interviews employees across departments and finds two main groups. One travels often and submits many small expenses from a phone between meetings. The other files a few expenses a year from a desk and forgets the rules each time.
The first persona, "Daniel, regional sales manager," cares about speed: photograph a receipt and submit it in seconds. The second, "Priya, research scientist," needs guidance: clear policy hints and examples. A single design optimized for one would frustrate the other, so the team builds a fast mobile capture flow for Daniel and a guided desktop form for Priya.
Persona vs. Jobs to be Done
A persona describes who the users are. Jobs to be Done describes the progress people are trying to make in a given situation, whoever they are. The two approaches answer different questions and are often used together.