A user persona is a research-based representation of a key segment of your target users. It aggregates real patterns from user research into a single named character with specific goals, frustrations, behaviors, and context. Personas are used to keep design and product decisions grounded in actual user needs rather than internal assumptions.
A user persona describes the person who uses a product · their goals, workflows, and frustrations in the context of the product experience. A buyer persona describes the person who makes the purchasing decision · their evaluation criteria, budget authority, and procurement process. In B2C products, these are often the same person. In B2B, they are frequently different: the user may be an analyst and the buyer may be a VP of Finance. Both are valuable but they answer different questions.
Two to four primary personas is the practical limit for most teams. More than that and the personas stop driving decisions · teams struggle to prioritize when five different personas have conflicting needs. If you have more than four meaningfully different user types, use primary and secondary personas: focus design decisions on primary personas and check secondary personas before shipping. One persona is usually too few; it often represents a wishful average user that does not really exist.
A proto-persona is a persona built from team assumptions and existing knowledge rather than formal user research. It is a starting point, to be replaced as research comes in. Proto-personas are useful for getting a team to articulate their current mental model of the user before research begins · which surfaces disagreements and assumptions that can then be tested. They should be explicitly labeled as assumption-based and updated as real research data becomes available. Using a proto-persona as if it were a research-validated persona is one of the most common product mistakes.
Validate by recruiting real users who match the persona description and conducting structured interviews. Check whether the goals, frustrations, and behaviors in the persona match what real users describe. A persona is validated when you can interview 5-7 users matching the profile and find that the key patterns hold. A persona that does not survive contact with real users should be revised, not defended. The most useful personas are updated at least annually as your user base evolves.
A persona describes who your user is, and a job to be done describes the progress a person is trying to make in a particular circumstance. Personas group people by shared goals, behaviors and context. Jobs to be done centers on the situation and the outcome that lead someone to hire a product, and the same job can belong to very different people. Use them together: write the persona's two or three most important jobs into the persona itself, each phrased as a circumstance and the progress sought. That keeps design reviews anchored on why people act as well as who they are. Source: Clayton M. Christensen, Taddy Hall, Karen Dillon and David S. Duncan, Competing Against Luck (2016).