Use this user persona template to connect goals, observed behavior, and product context to the decision you are making. The worked profile keeps its supporting notes beside each statement, including a contrasting record that does not belong in the same pattern.
Begin with the product task and the observations
Nielsen Norman Group's persona guidance describes personas as fictional representations grounded in user research. The identity can be fictional; the research basis for an actual product persona needs to be real. Group relevant patterns in behavior, goals, and context rather than filling a biography with attractive details.
This example uses original fictional walkthrough records, printed in full below, to demonstrate the method. No participants were recruited, no sessions were conducted, and no actual library users or research findings are represented. The resulting profile is a practice persona, not evidence for changing a real library service.
The design question is: What information should the reservation view make easy to read before a collection trip?
| Record | Complete simulated walkthrough |
|---|---|
| T1 | On a phone, a person plans a reserved-book pickup after work. The reservation card shows Ready and the branch. They open account details to find the pickup deadline, then compare it with the time available for the trip. |
| T2 | On a laptop, a person plans a reserved-book pickup among other errands. They check the branch and pickup deadline before deciding which day to travel. Both are available in the reservation details. |
| T3 | On a phone, a person browses library events without a reserved book to collect. They compare event dates and topics to decide which event to attend. |
T1 and T2 share a collection-planning goal despite using different devices. T3 also uses a phone, but the task is event selection. Grouping all phone use into one persona would hide that difference.
Fill the profile with a pattern you can trace
Here is the worked Trip-planning reserver profile:
| Profile field | Worked statement | Basis |
|---|---|---|
| Product context | Planning when and where to collect a reserved book. | T1–T2 |
| Goal | Fit the collection trip around other commitments and the pickup deadline. | After-work planning in T1; errands and day selection in T2. |
| Recurring behavior | Check the branch and deadline before deciding when to travel. | T1–T2 |
| Device context | The pattern appears on a phone and a laptop in this exercise. | T1 and T2 respectively. |
| Specific friction | The Ready card in T1 omits the deadline, requiring a visit to account details. | T1 only; T2 does not establish the same difficulty. |
| Design question | Can the reservation view present readiness, branch, and pickup deadline together clearly enough to support trip planning? | An interpretation to investigate, based on T1–T2. |
| Boundary | Event browsing is a different task and is outside this practice profile. | T3 |
The label names a behavior in context. Age, occupation, income, and hobbies are omitted because the records do not provide them or establish their relevance to this decision. There is no need to invent a portrait or quotation to make the profile look finished.
Choose Collection-planning goal in the example. It shows the profile statement beside T1 and T2 so a reviewer can inspect the grouping. Choose Deadline friction to see the narrower basis in T1. Keeping those different scopes visible stops a single difficulty from becoming a claim about every user in the group.
Turn the profile into a question for the interface
The design implication is specific: review whether the reservation view places Ready, branch, and pickup deadline together. That proposal addresses the information used in both collection records and the extra navigation described in T1.
It is not a tested improvement. The simulated notes establish no usability gain, trip-completion rate, or preference among actual users. A real team would inspect the current interface, consult its research, and evaluate a proposed change in the appropriate product workflow.
Compare two profile statements in the example:
| Proposed statement | What the records support |
|---|---|
| Checks pickup details before planning a collection trip. | T1 and T2 show this behavior. |
| Always uses a phone to plan the trip. | T2 uses a laptop; the statement excludes part of the pattern. |
Choose Compare device claim to inspect both alongside T2. Revise the profile to “Plans across phone and laptop contexts in this exercise.” You have kept the useful task pattern without forcing everyone into the device choice of the first record.
Use your own research without flattening the differences
Start with the product decision and the permitted research material relevant to it. Keep stable note references so a teammate can find the original observation and its context. Separate what happened from your interpretation of why it happened.
Look for patterns across the relevant material, then inspect exceptions. If an observation does not fit, ask whether it qualifies the profile, belongs to another task pattern, or requires more investigation. A persona is a synthesis aid; it should not hide a contrary observation to preserve a tidy story.
Keep the amount and limits of the evidence clear. The two collection records here are enough to illustrate the grouping exercise, not to establish how common the pattern is in any population. An actual project needs to assess the adequacy of its own research for its decisions.
Review the profile when new observations or the product context change. Preserve the reference to the earlier interpretation so the team can explain why a statement was revised. Keep personal or restricted research material in the system where your team is authorized to hold it; a review copy can use sanitized excerpts and source IDs.
Copy a prompt for the profile and evidence review
Create one complete HTML user-persona evidence review page.
Product context and decision the persona should inform: [PASTE]
Permitted research notes with stable IDs and relevant context: [PASTE]
Observed goals, actions, constraints and exceptions: [PASTE]
Current proposed profile statements and their source references: [PASTE]
Research scope/limits and review owner: [PASTE]
Use only my supplied material. Group relevant behavioral patterns;
do not fabricate participants, research, quotations, demographics,
motives, frequency or effectiveness. Distinguish observations from
interpretation and proposed design implications. Attach note IDs
to every profile statement and retain relevant contrary evidence.
Fictional persona identity does not permit invented research facts.
Include this separate Original fictional walkthrough exercise.
State no participants were recruited or sessions conducted; the
practice persona is not evidence about actual library users.
Question: What information should a reservation view make easy
to read before a collection trip?
T1: On a phone, a person plans a reserved-book pickup after work.
The reservation card shows Ready and the branch. They open account
details to find the pickup deadline, then compare it with the time
available for the trip.
T2: On a laptop, a person plans a reserved-book pickup among other
errands. They check the branch and pickup deadline before deciding
which day to travel. Both are available in the reservation details.
T3: On a phone, a person browses library events without a reserved
book to collect. They compare event dates and topics to decide
which event to attend.
Worked profile label: Trip-planning reserver.
Context: planning when/where to collect a reserved book, T1–T2.
Goal: fit collection around commitments and pickup deadline,
after-work planning T1 and errands/day selection T2.
Behavior: check branch/deadline before choosing when to travel, T1–T2.
Device context: phone T1 and laptop T2; no mobile-only claim.
Friction: Ready card omits deadline and requires account-details
navigation, T1 only; do not attribute this difficulty to T2.
Design question: can Ready, branch and deadline appear together
clearly enough for trip planning? This is a proposal, not tested.
Boundary: T3 event selection is a different task, outside this profile.
Provide Collection-planning goal and Deadline friction selections
that show the exact statement beside its note references and scope.
Compare device claim shows supported pickup-detail checking in
T1–T2 beside unsupported Always uses a phone, contradicted by T2.
Give the narrower revision: Plans across phone and laptop contexts
in this exercise. Keep complete T1–T3 readable, including T3's
contrasting goal. Do not infer prevalence or research sufficiency.
Add a separate blank persona scaffold and an interpretation-writing
area for human review. Keep typed interpretation when selections
change; ask before reset. No automatic persona score, truth grade,
recruitment, research submission or tested-design success badge.
Use at least 16px text, native labeled controls, visible focus and
readable profile/evidence records at 360px without page overflow.
Inline CSS/JavaScript only; no external assets, network or storage.
State that typing is temporary in this open page. Return full HTML.
Read each generated profile statement against its cited notes. In this exercise, the collection goal should point to T1 and T2, the specific deadline friction only to T1, and the contrasting event task to T3. Check the interpretation before polishing the profile's appearance.
Let a teammate inspect how you grouped the observations
A sanitized HTML review copy can put the proposed persona beside the notes that support it. Put that copy in your NOS workspace when a designer or researcher needs to discuss whether the grouping serves the current product question.
If “Mobile-only reserver” overstates the evidence, revise the static profile heading to “Trip-planning reserver” in visual editing mode. Save the correction so your teammate can reopen the existing link and read it. Update the maintained persona record too; a heading edit does not change underlying research notes or programmed evidence selections.
Use the review to decide which statement needs refinement and what to investigate next. Keep the actual research, design decision, and any evaluation of a revised interface in the team's normal product records.