scope
Decision context is missing
The persona has no explicit Product, UX, messaging, or buying decision to inform.
Next: State the decision first; remove claims that would not change it.
Evidence-backed persona decision system
User Persona Builder
Build a Product, UX, or buyer persona from research or explicit assumptions, trace each important claim to evidence, keep contradictions and unknowns visible, and keep Product implications separate from customer facts.
The core artifact is a Persona Claim & Evidence Map, not a fictional biography. Quick mode creates an intentionally incomplete proto-persona; Research mode helps synthesize recurring person-level patterns without pretending that filled fields are validated knowledge.
- Decision first: define what the persona should inform.
- Claim-level provenance: status, source, contradiction, relevance.
- No fabrication: missing research stays unknown.
No login. Saved persona data stays in this browser's localStorage unless you clear it or create a share link. localStorage is not encryption.
Decision scope
Start with what this persona must change or constrain. Segment selection belongs upstream in ICP.
Persona Library · browser local
Storage cap is 20 records; that is not a recommended number of personas.
Duplicate starts a new persona at v1. New version preserves root/parent lineage.
Persona Decision-Relevance Audit
No score. Automated warnings are prompts for evidence review, not proof that a persona is good.
scope
Represented group is undefined
A persona should represent a meaningful behavioral or role pattern, not a generic human profile.
Next: Add an inclusion-style group definition such as a workflow frequency, role and situation.
behavior
Current workflow is not captured
A persona without current behavior can collapse into biography or generic goals.
Next: Capture what the represented group actually does today when this situation occurs.
behavior
Current alternative is unknown
The team cannot compare proposed value with what people already do or use.
Next: Record the workaround, competitor, manual process, delegation, delay, or doing-nothing behavior if known.
behavior
Trigger / context is unknown
The persona does not yet show when the need becomes salient.
Next: Research the situation or event that makes the behavior relevant.
Quick · proto-persona hypothesis builder
Enter only what the team currently believes. New values default to Assumption; every other field remains unknown / not assessed.
Status: Unknown
Status: Unknown
Status: Unknown
Status: Unknown
Status: Unknown
Persona Claim & Evidence Map
This is the core artifact: claim, status, provenance, contradiction and decision relevance stay together.
No claims entered. Unknowns remain unknown.
Decision Implications
Team interpretations live here, not inside persona facts.
No Product implications entered.
Summary card preview
Bounded summary only. Markdown/JSON preserve the complete evidence trace.
Untitled persona
User · B2C · Proto-persona
Decision: Unknown / not assessed
Group: Unknown / not assessed
0 supported · 0 observed · 0 assumptions · 0 mixed · 0 unknown
Examples, export and share
Synthetic demonstration, names, evidence, metrics and research references in all examples are fictional.
Share privacy boundary
This link contains the selected persona and its evidence notes. Anyone with the URL can inspect them. Remove participant-identifying or confidential information before sharing externally.
Loading browser-local personas…
# Persona Decision Artifact - Persona: Untitled persona - Mode: Proto-persona - Market context: B2C - Persona role: User - Version: 1 - Version note: Initial draft - Updated: 2026-10-17T05:08:13.867Z ## Decision context Unknown / not assessed ## Represented group Unknown / not assessed ## Segment / account reference - ## Research basis - Built from: Unknown / not assessed - Research period: Unknown / not assessed - Last evidence update: Unknown / not assessed - Coverage limitations: Unknown / not assessed - Review trigger: Unknown / not assessed ## Persona Claim & Evidence Map No claims entered. Unknowns remain unknown. ## Decision Implications No Product implications entered. ## Use boundary This artifact is a synthesis of supplied evidence and explicit hypotheses. Unknowns are not auto-filled, and Product implications remain team interpretations rather than customer facts.
Decision Context → Evidence → Persona → Implications
A persona is useful when it compresses a recurring behavioral or decision pattern without erasing where that pattern came from. It should constrain a real decision, not merely make a fictional person feel complete.
Step 1
Decision context
State the Product, UX, messaging, or buying decision the persona should inform.
Step 2
Represented group
Define the meaningful role/behavior pattern and keep account-level ICP selection upstream.
Step 3
Claims + evidence
Record observed behavior or explicit assumptions, then attach provenance and contradictions to important claims.
Step 4
Persona synthesis
Keep unknowns visible instead of completing the profile with plausible fiction.
Step 5
Decision implications
Translate supported claims into team hypotheses without rewriting recommendations as customer facts.
Step 6
Refresh plan
Record coverage limits, last evidence update, and what should trigger another review.
10× asset
Persona Claim & Evidence Map
Every important claim can preserve its status, evidence source/reference, contradictory evidence, and relevance to the stated decision. This makes it possible to distinguish a direct observation from a recurring pattern, an explicit assumption from an unknown, and a customer fact from a team interpretation.
| Persona claim | Status | Supporting evidence | Contradiction | Decision relevance |
|---|---|---|---|---|
| Completes task during field rounds | Supported pattern | Participant refs + usage sessions | Desktop-only subgroup | Mobile workflow |
| Price-sensitive under a threshold | Assumption | None | - | Pricing |
| Uses spreadsheet workaround | Observed | Research reference | - | Import workflow |
Claim status is not evidence provenance
A label cannot certify itself. Supported or observed claims need inspectable provenance; assumptions are allowed; unknowns are allowed. Mixed evidence should show the materially different behavior instead of averaging it away.
Unknown
Not assessed or not known. This is allowed.
Assumption
A team hypothesis that still needs evidence.
Observed
A direct observation with an inspectable source.
Supported pattern
A recurring pattern supported across relevant evidence, not one anecdote.
Mixed evidence
Material variation or contradiction is preserved rather than averaged away.
Persona Decision-Relevance Audit
The audit does not output a Persona Score. It surfaces inspectable warnings grouped by the kind of judgment that still needs attention.
Scope
Decision context, represented group, user/buyer boundaries, and possible merged subgroups.
Evidence
Provenance, unsupported strong claims, staleness, anecdotes generalized as patterns, and contradictions.
Stereotype risk
Fake quotes, decorative biography, invented personality, and unsupported role stereotypes.
Behavior
Current workflow, alternatives, trigger/context, and whether pains are concrete enough to act on.
Boundary
ICP account data inside a person persona and Product recommendations encoded as customer facts.
Decision use
Whether the persona can change the stated decision and whether implications trace back to evidence.
User vs buyer is different from B2B vs B2C
B2B/B2C describes market context. User, buyer, champion, influencer, and admin/operator describe the human role in the workflow or decision. A B2B user does not automatically own procurement; a B2C purchase does not automatically have one decision-maker. Keep the dimensions separate.
Account-level segment characteristics remain with the ICP owner. A persona can reference that segment and record decision-relevant account context, but it should not combine the end user, champion, economic buyer, legal reviewer, and procurement process into one invented person.
Persona facts and Product implications are separate layers
Observed / synthesized fact
Users manually check status during field rounds.
Decision implication
Core status information may deserve earlier mobile visibility.
Potential solution
A push notification is one option, not a customer fact.
Research basis, variation, and refresh
Record what the persona was built from, the research period, last evidence update, known coverage limitations, and the event that should trigger review. A version number alone is not an audit trail. Duplicate creates a new persona; creating a new version preserves root/parent lineage and a change note.
When evidence points in materially different directions, keep the contradiction visible. The audit can flag a possible merged group, but it does not auto-split the persona. The team still has to determine whether the difference is context-dependent noise or a decision-relevant subgroup.
Where this tool stops
ICP Segment Picker
Chooses the target customer/account segment. Persona uses that context but does not replace the ICP.
Open owner →Interview Script Generator
Creates a runnable research instrument when evidence still needs to be collected.
Open owner →Insight Clustering Helper
Clusters raw qualitative notes before the recurring person-level pattern is stable enough to synthesize.
Open owner →JTBD Statement Generator
Owns situation → desired progress → outcome framing for a job, not the full persona artifact.
Open owner →Problem Statement Generator
Frames one supported obstacle/consequence when the problem itself is the next artifact.
Open owner →Value Proposition Canvas
Uses supported jobs/pains/gains for value design after the persona evidence is sufficiently useful.
Open owner →Practical persona hygiene
- Start with the Product, UX, messaging, or buying decision the persona must inform.
- Define the represented group with a behavior, role, situation, or inclusion rule rather than a vague label.
- Keep unknown fields unknown; completeness is not evidence quality.
- Use Observed for a direct observation and Supported pattern only when recurrence across the represented group is actually supported.
- Attach provenance to decision-driving claims instead of relying on a global evidence list.
- Preserve contradictory evidence; mixed behavior may reveal context dependence or a real subgroup split.
- Keep user goals separate from Product KPIs and Product implications separate from customer facts.
- Use a real verbatim quote with a source or leave the quote field blank.
- Treat B2B/B2C market context and user/buyer/champion/admin role as separate dimensions.
- Define a refresh trigger tied to Product, pricing, market, segment, or contradictory-evidence changes.
Common failure modes
A five-input Quick persona looks fully researched.
Why: The tool or team filled unknown fields with plausible defaults.
Fix: Keep Quick mode as an explicit proto-persona; record only supplied hypotheses and research gaps.
A claim is marked supported but nobody can trace why.
Why: Claim status and evidence provenance were collapsed into one label.
Fix: Attach source type and reference to that claim or downgrade its status.
The persona contains buyer, user and account facts in one blob.
Why: Market context and human decision role were treated as the same dimension.
Fix: Choose the human role separately and leave account-level ICP characteristics upstream.
The persona becomes a feature wish list.
Why: Product recommendations were stored as customer facts.
Fix: Move recommendations into Decision Implications and link each one to supporting claims.
Contradictory evidence disappears from the summary.
Why: Variation was averaged away to make the persona clean.
Fix: Use Mixed evidence, preserve the contradiction, and investigate whether the difference is segmentation-worthy.
B2B procurement data reappears after switching to B2C.
Why: The UI hid incompatible fields while state/export retained them.
Fix: Clear or explicitly archive incompatible account context during the switch.
A stakeholder screenshot makes hypotheses look factual.
Why: The summary card omitted claim statuses and unknowns.
Fix: Keep status visible in the summary and use Markdown/JSON for the complete evidence trace.
The persona survives long after the workflow changed.
Why: Version numbers existed without evidence dates or refresh triggers.
Fix: Record last evidence update, coverage limits, change reason and a review trigger.
FAQ
What does this persona generator actually generate?
It structures the claims you enter, their evidence status, provenance, contradictions and decision relevance. Quick mode does not invent missing biography, tools, channels, pricing, procurement or feature preferences. Research mode gives you a fuller evidence ledger, but unsupported fields can still remain unknown.
What is the difference between a persona and a proto-persona?
A research persona synthesizes recurring patterns from evidence. A proto-persona records the team’s current hypotheses so they can be tested. Switching modes does not upgrade evidence: a claim becomes observed or a supported pattern only when the research actually supports that status.
What is the difference between B2B/B2C and user/buyer?
B2B or B2C describes market context. User, buyer, champion, influencer and admin/operator describe the person’s role in the workflow or decision. They are separate dimensions: a B2B user does not automatically own procurement, and a B2C purchase can still involve more than one person.
How much evidence is enough for a persona?
There is no universal interview or evidence-bullet count. Judge whether important decision-driving claims have relevant provenance, recur beyond a single anecdote when you call them patterns, surface contradictions, fit the represented group and are recent enough for the decision at hand.
Can I add demographics or personality traits?
Only add attributes that materially affect the decision and are appropriately supported. This tool emphasizes role, context, workflow, goals, constraints, triggers and decision behavior. It does not infer protected or sensitive attributes, and decorative demographics are not required to make a persona useful.
How are Product implications handled?
Product implications are separate team interpretations. Each implication can link to one or more persona claims, explain the rationale, and remain a hypothesis, supported direction or needs-research item. This prevents a solution idea such as push notifications from being rewritten as a customer fact.
What happens when I switch a B2B persona to B2C?
If B2B-only account context contains data, the tool asks you to clear it, archive it explicitly as account context, or cancel. It does not silently hide procurement or buying-role fields and then leak them through JSON or a share link.
Where is my persona data stored?
No login is required. Saved personas stay in this browser’s localStorage unless you clear them or create a share link. localStorage is not encryption. A share URL contains the selected persona and evidence notes, so remove participant-identifying or confidential information before external sharing.
Can I share and export a persona?
Yes. Markdown and JSON preserve the evidence-aware artifact, while PNG is intentionally a bounded summary card and browser print supports PDF. Share links are size-guarded; when the encoded URL becomes impractically large, use a durable export rather than silently copying a fragile link.
How is this different from an ICP or JTBD tool?
ICP owns which customer or account segment to target. Persona owns person-level behavioral and decision patterns inside an already meaningful segment. JTBD owns situation, progress and outcome framing. The tools can hand context to one another without duplicating those jobs.
Related workflow owners
Freshness
Last updated: 2026-09-18
- Rebuilt Quick mode as a no-fabrication proto-persona workflow with explicit unknowns.
- Added claim-level evidence status, provenance, contradictions, decision relevance, represented-group and research-basis metadata.
- Separated human role from B2B/B2C context and separated Product implications from persona facts.
- Added safe B2B/B2C switching, v1 migration, share-size/privacy guards and evidence-aware exports.