Persona
Organize a user role, goals, working context, difficulties, and decision criteria while keeping research evidence separate from assumptions.
Use a persona when a broad audience label is too vague to guide a product decision. Describe patterns relevant to the task rather than adding a biography for decoration. Distinguish the user from the buyer and other market segments.
Interview and observation notes, the task being studied, and the limits of the sample. Identify which statements come from evidence and which need further checks.
A task-focused representative profile with supporting evidence, explicit assumptions, and a design question to test.
How to use it
- Define the user task and research scope. Look for recurring responsibilities, behaviors, and difficulties across the supplied evidence.
- Describe a representative role and relevant working context. Mark the profile as synthesized; avoid unsupported age, interests, or personal traits.
- Connect goals, current behavior, difficulties, and decision criteria to evidence. Record gaps or assumptions in the evidence field.
- Use the profile to compare design options, then test the important assumptions with similar users. Revise it when evidence differs.
Keep its limits in mind
A persona is a synthesized profile, not a real individual or a measurement of the whole market. A fictional teaching example is not real user research. Shared goals among a few interviewees do not establish market size, willingness to pay, or universal behavior.
Focus a review tool on a project manager's work
Fictional example: Yunqiao studies 12 small design studios through 12 interviews and 8 observations of review work. Feedback is scattered and versions are confused. Lin Lan is a synthesized project-manager profile in a 12-person studio, not one identifiable research participant. All study data is invented for teaching.
On a small screen, scroll across the diagram to read it.
A task changes the design focus: The profile makes gathering review feedback and tracking versions more relevant than simply adding another chat feature. That is a design direction based on this fictional study, not a proven improvement.
Keep the quantities separate: Twelve studios were studied; twelve people work in the representative studio. Eight review observations inform the example, while three similar-role users are proposed for a future prototype test. None of these figures describes market prevalence.
Next step: Invite three people in similar roles to try the review prototype. Check whether the profile's assumed goals, obstacles, and decision criteria fit their actual tasks.
Three reasons to pause before writing a persona
Begin with the product decision the profile should inform. A useful description might help choose what a client-review prototype must let a project manager accomplish. Record the task, relevant context and available evidence before inventing a name or biography. Distinguish a research synthesis from an assumption-based character so readers know how much confidence to place in it.
Pause when the profile is mostly demographic decoration without a task connection. Pause when one memorable interview has become a statement about every customer. Pause when a user’s needs are being presented as the buyer’s budget or purchasing authority. Each problem requires different evidence; adding a photograph or another adjective does not resolve it.
Keep attributed observations, reported preferences, editorial synthesis and unanswered questions separate. A participant saying that version tracking matters is not the same as observing successful tracking. A fictional case can illustrate that distinction, but it cannot provide evidence about actual customers. Do not publish identifying research details without the relevant permission.
Choose a person, a task journey or a market question
These views can share source records, but their conclusions differ. Select the view that makes the current uncertainty inspectable. Do not ask a persona to supply a market estimate or treat an imagined emotional state as an observed fact.
| Method | Material | Useful output |
|---|---|---|
| Persona | Task-relevant patterns with traceable sources or labeled assumptions | A bounded synthesis to challenge in design |
| Customer journey map | Attributed events across one person’s task | Touchpoints and experience gaps |
| Empathy map | What people said or did, with interpretation labeled | Questions about their perspective |
| STP | Market boundaries, alternatives and segment evidence | A target and positioning hypothesis |
Worked case: keep the study summary separate from the character
This continues the fictional Yunqiao case. The teaching summary gives 12 design studios, 12 interviews and eight observations of review work. It describes scattered feedback and version confusion, but supplies no transcript, issue-by-participant counts or interview–observation overlap. Do not claim that eight of twelve people experienced a problem simply because those two totals appear together.
Lin Lan is a synthesized project manager in a 12-person studio. The studio headcount is not the number of interviews. Following three to five projects daily describes the profile’s scenario, not an average calculated across all studios. The three similar-role users are a proposed future prototype test, not three more completed interviews. Keep all four quantities attached to their own objects.
The analysis below turns the supplied summary into a design question without inventing frequency or buying behavior. A clear review decision by the agreed date is the goal; gathering comments is an activity that may support it. Traceable versions and responsible people are criteria to explore, not a guarantee that a new interface will prevent confusion.
| Profile element | Supplied material | Implication / limit |
|---|---|---|
| Goal | A clear client review decision by the agreed date | Inspect how a decision is recognized |
| Scenario | Follow 3–5 projects daily | Test switching between projects; prevalence unknown |
| Pain | Feedback in chat, email and image comments; confused versions | Inspect source and version references |
| Criteria | Easy client start; traceable versions and people | Propose tasks that reveal these needs |
| Evidence boundary | 12 studios, 12 interviews, 8 observations | No issue frequency or market share supplied |
Use the profile to propose a test, then revise it from responses
The conclusion is a design focus on obtaining and tracing review decisions, rather than automatically adding more chat. It is a hypothesis within an invented study. The team should invite three people in similar roles for the proposed prototype work, explain the purpose and verify that their actual tasks fit. Three participants are a case-specific plan, not a universal validation threshold.
Prepare a draft task: find the current version of a project, inspect conflicting comments and explain who still needs to give a decision. Ask the participant to show what they would do and why, without prompting them to praise a one-link solution. Record the task conditions, observed actions, help required, unresolved work and their own explanation separately. No completed prototype or test results are supplied here.
At review, compare each observation with the profile’s claims. Preserve contradictions, including someone who delegates review or uses a different definition of “done.” Revise a goal, split a pattern or leave a claim unresolved when the evidence warrants it. Keep the previous profile and explain the change. A successful task in a prototype would support that limited task under its test conditions; it would not establish market demand, willingness to pay or that every design studio works like Lin Lan.
Check your work
- The profile distinguishes a user role from a purchaser or decision maker unless research supports combining them.
- Each meaningful claim has an interview, observation, or explicitly labeled assumption behind it.
- Study participants, organization count, and people in the representative workplace are different quantities.
- The profile explains a task and its obstacles, rather than relying on demographic stereotypes.
- A planned prototype test is not a completed validation or evidence of market demand.
Framework references
References explain the framework and its scope; they do not validate the fictional example's results.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.
Practice with an example
Use historical teaching material from 2015, explore continued-use and refill premises in a fictional project, and prepare one assumption and test for your own business.
What Nespresso illustrates about business model dependencies →