What is a user persona?
A user persona is a research-informed representation of a recurring user pattern. It helps a team discuss goals, context, behavior, and constraints when designing a product. Its value comes from explaining a decision, rather than supplying a stock photograph and an elaborate personal history.
Nielsen Norman Group distinguishes assumption-based proto-personas from personas developed through qualitative or quantitative research. An assumption-based draft can help organize questions, but it should not be presented as a finding from customers.
This guide builds a persona for a fictional SaaS called BriefRelay. The observation notes, participant references, and resulting persona are invented teaching material. They demonstrate traceability; they are not real interviews, a statistical sample, or claims about agency workers generally.
Download the evidence pack and blank template
The JSON pack contains six fictional observation notes, two tentative patterns, a completed example persona, explicit unknowns, and proposed design implications. The text template provides a blank structure and a review checklist. Both files are editable and available without registration.
Read the JSON in a text editor or another tool that preserves its IDs. Each persona claim points to observation IDs. Implications point to the claims they depend on, so a reviewer can move from a design proposal back to the underlying notes.
This structure does not validate the research automatically. In a real project, use references you are permitted to retain and share, and keep identifying details in an appropriately controlled research system. A planning artifact usually needs a source pointer and a useful observation, not a copy of someone's private files.
Start with a decision and a meaningful user role
The example decision is how to help an agency coordinator recognize which client intake needs attention. That is narrower than build for agencies. It names the person doing the work and the interface decision the team needs to investigate.
The coordinator prepares project intake and follows up on missing material. The agency owner may approve the subscription while rarely performing that workflow. Combining both into a single persona could cause the team to optimize a purchase message while overlooking the coordinator's daily task.
Choosing a target audience identifies a promising group to investigate. A persona synthesizes patterns within relevant research about using the product. Account segments, buyer roles, and user personas can overlap, but they answer different questions.
A job-to-be-done statement can explain the progress someone seeks in a situation. The persona adds recurring context and constraints relevant to design. Use each artifact only when it helps the team reason more clearly.
Collect behavior before writing the profile
The fictional notes describe recent tasks rather than preferred features. In O1, a coordinator moved between client threads to identify missing material. In O2, the same role kept a separate list because the intake status did not distinguish waiting on the client from waiting on the agency.
O3 describes an owner approving a subscription purchase; it belongs to the buyer context, not proof of the coordinator's interface needs. O4 describes a second coordinator pausing an intake while permission to share a document was unresolved. O5 records an example where a simple form was sufficient.
O6 records the first coordinator's question about whether a reminder had already been sent. This supports investigating status visibility, but it does not prove that automated reminders are the correct solution. The persona should preserve that distinction.
In real research, ask for concrete recent examples, the sequence of work, and what happened when it failed. The interview guide helps structure that conversation. Record counterexamples as well as repeated frustrations.
Synthesize a pattern without inventing precision
The example persona is called Intake coordinator. Its goal is to identify the next permitted action for each active intake. Its context includes several client conversations and an ownership boundary between agency staff and clients. These claims reference O1, O2, O4, and O6 in the pack.
The evidence is deliberately incomplete. The fictional notes do not establish how common this pattern is, which agency sizes share it, or whether coordinators would pay for a separate tool. The persona lists these as unknowns rather than filling them with a made-up demographic profile.
Use a descriptive role name when a decorative personal name adds little. Age, income, family status, and personality traits should not appear merely to make the page feel human. Include a characteristic when evidence connects it to the product decision.
There is no universal interview count that makes a persona valid. Consider how participants were recruited, which contexts are missing, whether patterns recur, and what decision the synthesis can reasonably support. A small qualitative study cannot establish a market percentage by itself.
| Observed pattern | Evidence IDs | Design question |
|---|---|---|
| Needs to see who is waiting on whom | O1, O2 | Would a clear ownership state help select the next action? |
| Cannot assume every document can be shared | O4 | How should unresolved permission block an action? |
| Wants to avoid repeated reminders | O6 | Can the coordinator see the last permitted reminder? |
| Some intakes need little coordination | O5 | Can a simple intake remain simple? |
Turn the persona into a testable implication
One proposed implication is a status view that separates waiting on client from waiting on agency, with the latest relevant action visible. That is a design hypothesis supported by the fictional pattern. It is not a direct customer instruction to build a particular layout.
Prepare a prototype task: identify which intake needs your action and explain why. Observe whether relevant participants can make the intended distinction without exposing information they should not see. Include a simple intake as a counterexample so the proposed interface does not add unnecessary work.
Record the decision after the session: keep, revise, investigate further, or stop. A persona that never affects a question or decision can become a decorative document. Link it to the usability study and the resulting product choice.
Review and retire personas as evidence changes
Name an owner and review the persona when the workflow, audience, or research changes. New evidence may split the pattern into two contexts or show that a previously important constraint no longer applies. Preserve the older version as a dated explanation of past decisions.
Check whether a reader can trace every consequential claim to evidence or an explicit assumption. Look for contradictory notes, missing participants, and unsupported claims about prevalence. Do not turn a buyer's budget constraint into a user's daily frustration without supporting evidence.
The downloadable pack was checked for valid JSON and resolvable observation and claim references. Its fictional labels remain attached to the notes and persona. Those checks confirm internal consistency, not the existence of real customer research. Framework source checked October 27, 2026.