Persona
A Persona is a research-based user type. It sums up goals, habits, and limits that appear again and again.
Another example
Interviews lead to “Mei, who runs a two-person shop and does most work on her phone.”
Main parts
- 01Research evidence
- 02Recurring goals and behaviors
- 03Meaningful constraints
Use it when
Create one when research shows a group with a clear pattern of goals and behavior.
Do not use it when
Never make up age, income, or a life story. A made-up profile isn't research proof.
Name used in code
research archetype Before you ship
Check the target user, wanted result, current baseline, evidence source, scope, owner, and success level. List assumptions, open risks, and the next test or decision.
Outcome: Use Persona to make a focused product decision backed by evidence. User context: Interviews lead to “Mei, who runs a two-person shop and does most work on her phone.” Product concept to apply: Persona. Why it fits: Create one when research shows a group with a clear pattern of goals and behavior. Do not use it when: Never make up age, income, or a life story. A made-up profile isn't research proof. Product framing: Name the target user and wanted result. Record the current baseline and evidence. Set what is in and out of scope, the limits, the owner, and the time frame. Decision quality: Keep facts, guesses, and unknowns separate. Record the options you did not choose and what evidence would change the decision. Acceptance criteria: The document names an owner, target user, measurable result, scope limit, evidence source, open risks, and next test. Evidence and limits (evidence boundary): No single official standard controls the whole term. Its meaning may change across teams, platforms, or frameworks. Unknowns to confirm: Target group, baseline, success level, owner, time frame, dependencies, and review schedule.
Check this request
Review the current use of Persona. Definition: A Persona is a research-based user type. It sums up goals, habits, and limits that appear again and again. Release checks: Check the target user, wanted result, current baseline, evidence source, scope, owner, and success level. List assumptions, open risks, and the next test or decision. Before changing code, report the evidence you found, gaps, severity, and the smallest safe fix.