persona-draft
Paste into Claude Code, Claude.ai, the desktop app, or the browser extension — ⌘/Ctrl+V. ✓ Copied. Switch to Claude and paste — ⌘/Ctrl+V.
Persona Draft
Draft research-grounded personas from discovery data. Personas here are JTBD-first: they start with what the person is trying to accomplish, not who they demographically are. Demographic details emerge from the research, not from assumption.
When this skill applies
- User has synthesized discovery data (themes, quotes, opportunity areas) and wants personas
- User provides interview transcripts or a synthesis report and asks for audience segments
- The engagement needs content author personas, not just end-user personas
- A platform recommendation requires mapping user types to platform capabilities
Do not draft personas from scratch without data. If the user has no research input, say: "Personas built without research data become assumptions dressed as insights. Please share discovery notes, interview themes, or even rough notes — any real data is better than none." Then pause and wait.
Workflow
Step 1 — Read the research data
Read all provided synthesis, transcripts, or notes. Extract:
- Distinct role clusters (groups of people who have meaningfully different goals, contexts, or behaviors)
- Behavioral patterns by role cluster — not demographics
- Representative quotes per cluster
- Pain points and workarounds per cluster
- Stated goals and motivations per cluster
- Constraints per cluster (time, authority, technical access)
If the source data only covers one type of participant (e.g., only IT leads), note this gap explicitly. Personas require data from the people the persona represents.
Step 2 — Identify persona candidates
List the distinct role clusters found in the data. Evaluate each against:
- Breadth: Does this cluster appear across multiple participants?
- Distinctiveness: Does this cluster behave meaningfully differently from others in ways that affect the digital experience?
- Consequence: Would designing for this cluster require different decisions than designing for another?
Only promote a cluster to a persona if it is broad enough, distinct enough, and consequential enough. A single interview participant with a unique role is not a persona — they are a stakeholder to map.
For DXP engagements, always check whether these persona types are present in the data:
- End user — the person the digital experience is built for
- Content author — the person who creates and manages content in the CMS
- Administrator — the person who manages the platform, permissions, and governance
- Buyer / decision-maker — for B2B contexts; the person who evaluates and approves the solution
Step 3 — Draft each persona
Use the structure in templates.md. For each persona:
1. JTBD statement (the backbone) "When [situation], I want to [motivation], so I can [expected outcome]."
This is the most important element. Every design decision should be testable against this statement.
2. Name and archetype label Give the persona a first name and a short archetype label that the team will use as a shorthand. Keep the name human and memorable but not stereotyping. Example: "Maria — The Distributed Content Author."
3. Role and context
- Job title and department (from research data, not invented)
- Work environment — remote, hybrid, in-office; which devices
- Relationship to the platform — daily user, occasional user, admin
- Technical fluency — low, medium, high (from behavioral signals in the data, not job title assumptions)
4. Goals and motivations 3–5 goals grounded in research quotes. Each goal should be:
- Functional: what they are trying to accomplish
- Emotional: how they want to feel when they accomplish it
- Social: how they want to be perceived by their team or clients
5. Pain points and frustrations 3–5 pain points from the research. Paired with the quote that surfaced them. Include the workaround they have invented, if any.
6. Behaviors and mental models How this person currently navigates their work. What tools they reach for, how they think about their domain, what they assume about technology.
7. Success criteria What "good" looks like for this person. What they would say if the digital experience met their needs perfectly. Phrase as a direct quote — even if constructed, ground it in real quote patterns from the research.
8. Platform implications Specific platform capabilities or configurations this persona's needs imply. Use hedged language. Add a platform adapter note if a platform-specific consideration is relevant.
9. Design questions this persona raises 2–3 open questions for the design team. These are gaps in the current data or decisions the persona's needs force.
Step 4 — Cross-reference against the opportunity areas
If a discovery insights report is available, map each persona to the opportunity areas it is most affected by. A persona should connect to at least one opportunity area. If a persona does not connect to any opportunity area, either the opportunity areas are incomplete or the persona is not well-grounded in the research.
Step 5 — Self-check before returning
- Every persona has a JTBD statement as its backbone
- Demographic details (age, gender, location) are absent unless the research specifically evidences them as relevant to the digital experience
- Each pain point is traced to at least one research quote
- Content author personas are present if the engagement involves a CMS
- Platform implications use hedged language
- The persona set covers the distinct role clusters found in the data without fabricating new clusters to fill a grid
Anti-patterns to avoid
- Demographic-first personas — starting with age/gender/location when the research didn't make these salient
- Aspirational personas — describing who the client wishes their users were rather than who they are
- Single-source personas — a persona grounded in only one interview participant (flag as a "proto-persona" instead)
- Persona proliferation — drafting 8 personas when 3 distinct clusters are all the data supports
- Jargon archetypes — labels like "The Digital Native" or "The Millennial Buyer" that encode assumptions
Reference and template files
reference.md— JTBD framework detail, proto-persona vs. research persona distinction, B2B buyer persona notestemplates.md— per-persona markdown template, card format for decks, and comparison table format
Technical details
- Plugin
- discovery-synthesizer
- Author
- Dakota Smith
- Skill name
persona-draft- Maturity
- experimental
- Security review
- No security review
- Owners
-
- strategy
- Argument hint
[paste synthesis findings, quotes, or @file-path] [--type end-user|content-author|buyer|admin] [--platform sitecore|optimizely|umbraco|composable] [--count 1-6] [--format full|card|jtbd-only]- Allowed tools
-
ReadWriteGlob
- Source
plugins/discovery-synthesizer/skills/persona-draft/SKILL.md
Edit this skill on GitHub — opens GitHub's web editor. No git knowledge needed.