User persona template
Start with what the user needs to finish, where they begin, what gets in the way, and what observable outcome counts as done.
Describe what the user needs to get done
A user persona helps you choose what to build, explain or remove from a workflow. Start with the person’s task and the conditions around it. Budget and buying objections may matter later, but they do not tell you why someone gets stuck inside the product.
To understand who approves the purchase, use the buyer persona template. To select companies to pursue, start with an ideal customer profile.
Copy the task-focused template
Paste this into a doc and work down it. It is deliberately plain so it survives being copied anywhere.
Free to copy, edit and download. No account or email required. Use this worksheet to describe a task inside the product. Use the buyer persona template when your next decision concerns a purchase.
USER — a role label, not an invented customer identity Task: What are they trying to finish? Starting point: What information or materials do they have? Trigger: What starts this task? Current workflow: What do they do, step by step? Constraint: What limits time, access, knowledge or resources? Failure: Where does the task stop or need rework? Success: What observable outcome would count as finished? Evidence: Which observation, artifact or conversation supports this? Unknown: What are you assuming? Next check: What would make you change the profile? USER TASK WORKSHEET Product or workflow: Task and starting point: Current steps and workaround: Constraints: Failure or rework: Observable finish condition: Product decision this changes: EVIDENCE NOTE Statement: Status: hypothesis / participant report / direct observation / unknown Source or permitted reference: Checked date: Contradicting evidence: Next check and owner:
Name one task, an observable finish condition and an evidence gap. Then write down one product decision the profile changes.
A role label does not describe a workflow. Before adding background details, name the task, where it fails and what you would change in the product. Keep untested statements marked as hypotheses.
A filled-in user persona example
Illustrative scenario: not an observed user or generated report.
StockBridge is a fictional inventory tool. This profile describes the warehouse coordinator who uses a tool; it does not describe who buys it.
- Task
- Reconcile stock counts across two warehouses before a promotion starts.
- Starting point
- Warehouse count sheets and a sales-channel stock export.
- Trigger
- The team needs to publish stock availability for the promotion.
- Current workflow
- Collect counts, compare SKU totals, flag differences, ask warehouse leads to resolve them, then update the available-stock list.
- Constraint
- Counts arrive in different formats, and the coordinator cannot change a warehouse count without approval.
- Failure
- A duplicate SKU label hides a mismatch; the coordinator repeats the comparison after clarification.
- Success
- Each mismatch has an owner and a recorded resolution before the availability list is published. This is a proposed outcome, not a measured saving.
- Evidence
- None yet. These details were written for this example.
- Unknown
- Whether mismatched counts, approval delays or another issue causes the most rework.
- Next check
- Watch one permitted reconciliation session, or ask the coordinator to reconstruct the last one using their files.
Every detail in this scenario is assumed. The evidence field is empty until a permitted observation or conversation supplies it.
Turn the persona into one product decision
Compare an avatar for the coordinator with a visible list of unresolved mismatches and their owners. The second is closer to the proposed task. That does not prove it is the right feature: first check whether missing ownership actually causes the delay.
Write down the decision the persona changes. If two profiles lead to exactly the same product decisions, you may not need two documents.
Add evidence without turning guesses into facts
Label each statement assumed, reported or observed. “The coordinator said approval takes too long” is a reported view. “We watched three mismatches wait for approval during this session” would be an observation only if it actually happened. This example supplies neither.
Keep real customer files private. Record the minimum evidence you are permitted to use, plus the date and the detail that contradicted your draft.
Prepare questions to test this taskThree passes for a testable task
Do not try to be complete on the first pass. Be specific, then be honest.
Write what you already know
Write the task, starting point and current workflow. If you have no observation yet, mark the description assumed.
Check the failure and finish condition
Ask for a recent event or observe a permitted session. Record what stopped the task and what actually counted as finished.
Name the decision and next check
Choose one product decision this profile changes. Record the evidence gap and the check that could make you revise it.
A draft organizes questions; observing actual use supplies evidence.
User persona or buyer persona?
A user persona describes a task inside the product. A buyer persona describes purchase roles and decisions. An ICP describes companies to pursue.
For onboarding or workflow changes, start with the task. For buying authority, use the buyer template. The same person may be both user and buyer.
Optional context for buying and outreach
These thirteen existing fields may help with buying or outreach decisions. They supplement the task template; they do not replace a user workflow. Use the buyer template to study purchase roles.
See the buyer persona template| Block | What goes in it |
|---|---|
| Demographics | Only the parts that change the pitch — stage, team size, geography, whether they buy on a card or through procurement. |
| Role | The job title, and the thing they are actually measured on this quarter. |
| Pain points | Written as they would say them out loud, not as your product describes them. |
| Buying motivation | Why now and not last quarter. If you cannot answer this, the persona is not finished. |
| Jobs to be done | The job they hired a tool for, including the parts they do in a spreadsheet today. |
| Day in the life | A realistic day, hour by hour, so you know when an email might actually land. |
| Info channels | Where they already read things. This is where every outreach decision starts. |
| Willingness to pay | A number and a form — monthly on a card, or an annual PO. The two lead to different pitches. |
| Tech savviness | How much setup they will tolerate before they close the tab. |
| Decision triggers | The event that makes them look. Churn email, a competitor launch, a lost deal review. |
| Objections | The three reasons they say no, in their words. |
| Anti-ICP | Who you should stop emailing. Naming them is worth more than another positive trait. |
| Definition of win | What has to be true in 90 days for them to renew, spelled out. |
Only add context that changes a decision. Mark unknown budget, channels and objections as unknown, and keep sources beside the statements.
Draft the task, then test it with a person
Use the free ICP and persona generator to start a research draft from your product description. Treat its output as assumptions to check, not a replacement for observing someone use the product.
Public generation, signed-in full reports and contact matching are separate steps. Check feature availability and limits in your account.