Persona Draft

Use this when you have raw research (interview notes, support tickets, survey responses, analytics data) and need to synthesize it into a structured user persona that the team can reference during story writing, design, and prioritization. This produces the persona definition — for shareable visual artifacts (PDF, slides, Miro), follow up with /persona-create.

Need visual outputs? Use /persona-create after this skill to turn the persona into branded PDF cards, Google Slides, Miro boards, or FigJam diagrams.

Related resources: persona-archetypes-guide.md -- four persona archetype templates (End User, Service Provider, Internal Stakeholder, Product Team).

Process

Step 1: Gather inputs

Ask the PM or designer:

1. Research data — What do you have? (Interview transcripts, survey results, support tickets, analytics, usage data, or informal observations.)
2. User segment — Who is this persona representing? (A specific user segment, role, or behavior pattern — e.g., "power users," "first-time buyers," "IT admins.")
3. Product or feature area — What product or feature area is this persona for?
4. Existing personas — Are there existing personas to differentiate from? If yes, what makes this persona distinct?
5. Team context — Who will use this persona and for what? (Story writing, design decisions, prioritization, stakeholder communication.)

Step 2: Analyze the research

Review the provided data and extract:

• Behavioral patterns — What do these users actually do? How do they work? What is their typical workflow?
• Goals — What are they trying to accomplish? (Both immediate tasks and broader objectives.)
• Pain points — What frustrates them or slows them down? What workarounds do they use?
• Triggers — What causes them to seek a solution? What's the "last straw" moment?
• Decision factors — What influences their choices? (Price, speed, trust, peer recommendations, compliance requirements.)
• Context of use — Where and when do they interact with the product? (Device, environment, time pressure.)
• Direct quotes — Verbatim quotes that capture their voice (2-4 strong quotes).

Flag any section where data is thin. Don't fabricate patterns from insufficient evidence.

Step 2b: Deepen the character

Before writing the formal persona, build deeper empathy using character development techniques:

• Given circumstances: What is true about this person right now? Not just their role -- their morning, their last meeting, what they're worried about that has nothing to do with your product. The fuller the context, the more real the persona feels.
• Objective: What does this person actually want? Not "use our feature" but something upstream: finish a report, impress a client, avoid a mistake, keep their team from burning out.
• Obstacle: What's in their way? External (bad tools, org politics, budget) or internal (confidence, knowledge gaps, competing priorities)?
• Tactics: How do they typically try to get what they want? Do they push through? Ask for help? Work around the system? Give up?
• First-person moment: Before writing the persona in third person, write 2-3 sentences from their perspective. "It's Monday morning and I'm staring at..." This grounds the analysis in a specific human moment.

This step is optional but produces noticeably more dimensional personas. Use it especially when the persona represents a user type the team hasn't worked with directly.

Step 3: Generate the persona

Produce the persona using this structure:

## Persona: (Persona Name)

**Archetype:** (1-line description — e.g., "The overwhelmed PM juggling 3 client projects")
**Segment:** (User segment this represents)

---

### Who they are

- **Role:** (Job title / function)
- **Experience level:** (Years in role, technical sophistication)
- **Context:** (Team size, industry, company stage)
- **A day in their life:** (2-3 sentences describing their typical workday and how the product fits in)

### Goals

1. (Primary goal — what they're trying to accomplish)
2. (Secondary goal)
3. (Tertiary goal)

### Pain points

1. (Pain point 1 — specific, grounded in evidence)
2. (Pain point 2)
3. (Pain point 3)

### Triggers

- (What causes them to seek a solution — the moment they decide to act)
- (What makes the problem acute vs. tolerable)

### Decision factors

- (What they weigh when choosing a solution — ranked by importance)

### Behaviors

- (Key behavior pattern 1 — observed, not assumed)
- (Key behavior pattern 2)
- (Workarounds they currently use)

### In their own words

> "(Verbatim quote 1)" — Context: (what prompted this)
> "(Verbatim quote 2)" — Context: (what prompted this)

### What this means for the product

- (Implication 1 — what this persona needs from the product)
- (Implication 2 — what would delight vs. frustrate them)
- (Implication 3 — how they differ from other personas)

### Evidence gaps

- (Areas where data is insufficient -- flagged for future research)

### Accessibility context

**Prompt the user:** "Does this product serve users with disabilities, or is the team building for inclusive design? If yes or unsure, add an accessibility persona variant. One variant per major access need, not one that blends all disabilities."

If the user confirms (or if the product is public-facing and the audience is broad), add an accessibility persona variant:

- **Assistive technology:** (Screen reader, magnification, switch control, voice input, none)
- **Access needs:** (Low vision, color blindness, motor impairment, cognitive load sensitivity, hearing loss)
- **Device and setup:** (Desktop with JAWS, mobile with VoiceOver, high-contrast mode, custom font sizing)
- **Key friction points:** (What aspects of the current product are hardest for this user?)
- **Workarounds:** (How do they currently get around barriers?)

Use this variant when: the product has regulatory accessibility requirements (Section 508, ADA, EAA), the user base includes known assistive technology users, or the team wants to proactively design for inclusion. One accessibility persona per major access need -- don't blend a screen reader user with a motor-impaired user.

### Confidence & gaps

| Persona attribute | Evidence strength | Source | Gap / follow-up |
|---|---|---|---|
| Role & context | Strong / Moderate / Weak / Assumed | (e.g., "5 interviews, consistent") | (Follow-up if needed) |
| Primary goal | Strong / Moderate / Weak / Assumed | | |
| Pain points | Strong / Moderate / Weak / Assumed | | |
| Triggers | Strong / Moderate / Weak / Assumed | | |
| Decision factors | Strong / Moderate / Weak / Assumed | | |
| Behaviors | Strong / Moderate / Weak / Assumed | | |

**How to rate:**
- **Strong** — 3+ sources confirm, with direct quotes or observed behavior
- **Moderate** — 1-2 sources, consistent but limited sample
- **Weak** — inferred from indirect evidence, not directly stated
- **Assumed** — no data. Team's best guess. Mark clearly and prioritize for follow-up

**Suggested follow-up research:**
- (Method recommendation for each Weak/Assumed attribute — e.g., "Run 3-4 contextual inquiries to observe actual workflow" or "Add 2 survey questions on decision factors")

If data is insufficient for a section, mark it as "(Needs more research — insufficient data to determine)" rather than guessing.

Step 4: Differentiate from existing personas

If the user provided existing personas:

• Highlight what makes this persona distinct from each existing one.
• Identify any overlaps that might indicate these are variants of the same persona rather than separate personas.
• Flag if the research suggests a different segmentation than the team assumed.

Step 5: Review and validate

Present the persona and ask:

• Does this feel like a real person you've encountered in your research?
• Are the goals and pain points accurate to what you've heard?
• Is anything missing or overstated?
• Would the team find this useful when writing stories and making design decisions?
• Are the evidence gaps flagged in the right places?

Revise based on feedback. A persona is only useful if the team trusts it.

Related skills

• /persona-create — turns this persona into visual artifacts (PDF cards, slides, Miro boards) for team distribution.
• /research-synthesize — synthesizes raw research into themes before persona creation. Run this first if you have unprocessed interview data.
• /interview-plan — plan interviews to gather the research data that feeds into persona creation.
• /jtbd-analysis — if you want a jobs-to-be-done perspective alongside persona work.
• /story-write — uses personas to populate the "As a..." clause.

Output location

Present the persona as formatted text in the conversation. The team copies it into their wiki, Notion, or project documentation. For visual distribution, follow up with /persona-create.