Use this when you have research inputs (interview notes, support tickets, survey data, analytics, conversation transcripts, contextual-inquiry observations, whiteboard photos and affinity-wall outputs, or even team assumptions) and need to produce structured persona artifacts that the team can reference in product documentation, use for steering decisions, and include in presentations.

This skill replaces /persona-draft and /persona-from-field-notes. It produces saved files -- not just conversation text -- so personas become reusable project artifacts, and it grounds every attribute in evidence with an explicit confidence rating. When your inputs are raw field research (whiteboard photos, sticky-note clusters, affinity walls), use the field-notes mode noted in Step 1.

Brand reference

For branded visual outputs, see brand tokens.

Process

Step 1: Gather inputs

Ask the user:

1. What research data do you have? (Interview transcripts, survey results, support tickets, analytics, informal observations, existing proto-personas, conversation notes, or files to analyze. Field research counts too: whiteboard photos, sticky-note clusters, contextual-inquiry observations, affinity-wall outputs.)
2. Who is this persona representing? (A specific user segment, role, or behavior pattern -- e.g., "power users," "new PMs," "client stakeholders.")
3. What product or feature area is this persona for?
4. Are there existing personas to differentiate from? (If yes, what makes this persona distinct?)
5. What format do you need? Options:
   • Full persona document -- detailed artifact for product docs and steering (default)
   • Persona card -- one-page summary for slide decks and team walls
   • Both -- full document plus a condensed card section at the end
6. Where should the file be saved? (Default: personas/ directory in the project root. Can also be a specific path.)
7. Do you want visual output beyond the markdown file? Options:
   • Markdown only (default) -- the saved .md file is the final artifact
   • PDF slide deck -- branded PDF via Marp
   • Presentation (Google Slides) -- generated via Gamma, exported as PPTX
   • Miro board -- document posted to a Miro board
   • FigJam -- visual map in FigJam (diagram formats only)
   • Multiple -- any combination of the above

If the user provides files (PDFs, transcripts, documents), read and analyze them as research inputs.

Field-notes mode: If the inputs are raw field research (whiteboard photos, sticky notes, affinity walls, contextual-inquiry notes), have the user share or describe each artifact -- for photos, ask them to describe what's on the whiteboard. Then run the clustering pass in Step 2 to find distinct user types before structuring any persona. Field research usually yields a set of personas (a primary, internal/admin personas, and edge cases), not a single one, so plan to produce several and a coverage assessment (Step 9).

Step 2: Analyze the research

Review all provided data and extract:

• Behavioral patterns -- What do these users actually do? How do they work?
• Goals -- What are they trying to accomplish? What does success look like?
• Frustrations -- What blocks them, slows them down, or makes them anxious?
• Triggers -- What causes them to seek a solution or take action?
• Decision factors -- What influences their choices? Who else is involved?
• Context -- Where do they work? What tools do they use? What constraints apply?
• Workarounds -- What have they invented to cope with current tools or process?
• AI interaction preferences -- How does this persona expect to interact with AI-powered features? Consider: trust level (skeptical, cautious, eager, dependent), control preference (wants to steer vs. wants to be guided), transparency need (wants to know when AI is involved vs. doesn't care), correction willingness (will report errors vs. will silently stop using it), and AI literacy (sophisticated user vs. first encounter). These preferences shape how AI features should behave differently for this persona. See /ai-persona-design for designing AI system personas that respond to these preferences.
• Direct quotes -- Verbatim quotes that capture their voice (2-4 strong quotes).

AI-first clustering pass (with human verification). As of 2026, the manual affinity-mapping burden has largely collapsed. If the research lives in a tool like Dovetail (auto-transcribe, theme-tag) or an AI-native repository like Notably or Marvin, run an AI clustering pass first: let it auto-tag themes, group repeated patterns, and surface candidate insight summaries across the corpus. This roughly halves the interview-to-insight time. Treat the output as a draft, not a verdict. Read the source clips behind each cluster yourself, confirm the theme actually holds, and drop or merge any cluster the AI over-fit. The AI proposes the groupings; you decide which ones are real. If no AI tooling is in play, fall back to manual clustering across the same dimensions above.

Look for patterns that cluster users into distinct types. Cluster on different primary tasks (not just different job titles), different relationships to the system (power user vs. occasional, admin vs. end user), and different pain profiles (speed-focused vs. accuracy-focused). Watch for edge cases that represent real segments (new-user onboarding, locked-out or unauthorized users, power users). If the data reveals multiple personas, note this and offer to create each one.

When the domain involves service roles (agents, representatives, coordinators), consider the dual-persona pattern: the end customer persona AND the service provider persona. The Allstate engagement showed that agent personas (retention-focused, relationship-driven) have fundamentally different goals and frustrations than customer personas, even though they interact with the same product.

For four reusable starting templates (End User, Service Provider, Internal Stakeholder, Product Team), see persona-archetypes-guide.md.

Step 3: Deepen the character

Before writing the formal persona, build deeper empathy using character-development techniques. 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.

• 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.

Step 4: Write scenarios

For each persona, draft 2-3 concrete scenarios. Scenarios are what make personas actionable -- they describe real situations where the persona interacts with the product.

Each scenario includes:

• Trigger -- what event starts the interaction
• Goal -- what the persona is trying to accomplish
• Environment -- where and when (at desk, on mobile, in a meeting)
• Actions -- what they do, step by step
• Resolution -- how it ends (success or frustration)

Step 5: Generate the persona artifact

Use the persona template to produce the full persona. Fill in every section. If data is insufficient for a section, mark it as "(Needs more research -- insufficient data to determine)" rather than guessing.

Two elements are mandatory in every persona:

Confidence & gaps table. Rate the evidence strength behind each attribute so the team knows what to trust and what to verify:

• 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

For each Weak/Assumed attribute, suggest a follow-up method (e.g., "Run 3-4 contextual inquiries to observe actual workflow" or "Add 2 survey questions on decision factors").

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 they confirm (or the product is public-facing and the audience is broad), add an accessibility persona variant capturing: 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, key friction points in the current product, and current workarounds. Use this 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.

Include the presentation-ready persona card at the end of the document (the condensed version suitable for slide decks).

Step 6: Trace every attribute back to evidence

By 2026, the field had a real backlash against fabricated AI personas, and the lesson is worth holding onto. A systematic review found only 19.2% of generative-persona work followed standard persona methods. NN/g tested synthetic users and found they predicted behavior poorly: the synthetic versions claimed they finished every course while real users told messier stories. Left unprompted, LLM personas collapse toward an affluent, English-speaking, tech-literate stereotype, even when you explicitly ask for diversity.

So before you save, audit the artifact for evidence-grounding:

• Every attribute traces to a real research artifact. Goals, frustrations, quotes, scenarios: each one should point back to an interview clip, a ticket, a survey response, or an analytics signal. If you cannot name the source, the attribute is a guess, and a guess gets flagged "(Needs more research)" or cut.
• Quotes are verbatim, not invented. A quote that no real user said is the fastest way to lose the team's trust. If you do not have a strong verbatim quote, leave the slot empty rather than fabricating one.
• Synthetic personas are a hypothesis aid, never a substitute for real users. If part or all of this persona came from an LLM generating attributes rather than from research, label that section clearly as a proto-persona at low confidence, and write down what to validate next. Use it to generate questions for real research, not to make steering decisions on its own.
• Check for stereotype collapse. If the persona reads as a generically affluent, tech-savvy, English-first professional and your real users are not, that is the LLM default leaking through, not a finding. Push it back toward what the data actually shows.

This audit is what separates a persona the team trusts from a character sheet they quietly ignore.

Step 7: Save the artifact

Save the persona as a markdown file:

• Default path: personas/(persona-name).md (e.g., personas/maria-ops-manager.md)
• File naming: lowercase, hyphenated version of the persona name and role
• If the personas/ directory doesn't exist, create it.

If creating multiple personas, save each as a separate file and create a personas/README.md index that lists all personas with one-line descriptions and a summary table (Name | Role | Archetype | Top pain point).

Step 8: Generate visual outputs

If the user requested visual output in Step 1, generate it now. The markdown artifact from Step 7 is always the source of truth -- visual outputs are produced from it.

Follow the visual output addon for detailed instructions on each path. Persona-specific guidance below:

PDF slide deck (Path A)

Use the persona slides template as the structure guide. This produces a 6-slide branded deck:

1. Title slide -- persona name, role, key quote
2. Bio & Goals -- two-column: bio/goals left, frustrations/context right
3. Behaviors & Triggers -- two-column: behaviors left, triggers/decision factors right
4. Key Scenarios -- three-column cards, one per scenario
5. Success & Evidence -- success narrative + evidence/confidence table
6. Persona Card -- the condensed reference card (closing slide)

Save the Marp markdown to ./output/decks/(persona-name)-persona.md and generate PDF + HTML per the addon instructions.

Presentation via Gamma (Path B)

Prepare the persona content as a slide-by-slide outline following the same 6-slide structure above. Use textMode: "preserve" since the content is already structured. Set numCards: 6 and exportAs: "pptx".

Miro board (Path C)

Post the full persona markdown to the user's Miro board. The markdown format transfers well to Miro docs -- headings, bullets, bold, and quotes all render correctly.

FigJam visual map (Path D)

For personas, FigJam works best as a persona journey map -- a flowchart showing the persona's triggers, key scenarios, and decision points as a connected flow. Generate a Mermaid.js flowchart with:

• Trigger nodes (rounded) leading to scenario nodes
• Decision factor nodes branching from scenarios
• Resolution nodes at the end of each path

This complements the full persona document rather than replacing it.

Step 9: Validate coverage and connect to the backlog

If you produced a set of personas (typical for field research), check coverage before reviewing:

1. Does every major user type from the research have a persona?
2. Is there at least one primary persona (the user you design for first)?
3. Are internal/admin personas present if the product has an admin layer?
4. Are edge cases represented (new users, locked-out users, power users)?
5. Do the personas cover the full workflow or just one phase?

Flag any gaps: "We have no persona for (role) -- was this covered in research?"

When you produce a set, add a cross-persona comparison and a shared-patterns note so the team can see the personas side by side and decide who to design for first:

### Persona comparison

| Dimension | Persona 1 | Persona 2 | Persona 3 |
|---|---|---|---|
| Primary JTBD | ... | ... | ... |
| Biggest pain | ... | ... | ... |
| Product fit | Strong / Moderate / Weak | ... | ... |
| Priority | ... | ... | ... |

### Shared patterns

Jobs, pains, or gains that appear across multiple personas (these often point to the highest-leverage opportunities).

For each persona, also capture a product-fit assessment: how the product addresses this persona's primary job, the gaps between what they need and what the product delivers, and the biggest risk if this persona is ignored.

For each persona, suggest 2-3 stories that would directly address their top pain point, so personas connect straight to the backlog:

As (Persona Name), I want to (action) so that (outcome).

Step 10: Review and validate

Present a summary of the persona(s) and ask:

• Does this feel like a real person you've encountered in your research?
• Are the goals and frustrations accurate to what you've heard?
• Are the scenarios realistic -- do they match how this person actually works?
• Are the evidence gaps flagged in the right places?
• Is anything missing or overstated?
• Would the team find this useful when writing stories and making design decisions?

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

Related skills

• /artium-deck -- create standalone branded slide decks (used by the PDF output path)
• /artium-prototype -- create branded HTML prototypes with persona-informed UI
• /research-synthesize -- synthesize raw research into themes before creating personas
• /jtbd-analysis -- connect persona goals to jobs-to-be-done
• /stakeholder-map -- when personas include internal users
• /story-write -- use personas when writing user stories ("As Maria...")
• persona-archetypes-guide.md -- four reusable persona archetype templates (End User, Service Provider, Internal Stakeholder, Product Team)
• Visual output addon -- shared module for generating branded visual artifacts from any skill

Origin

Synthesized from two Pivotal engagements: the Allstate CompoZed boot camp (participant-created customer and agent personas grounded in interview data) and the Home Depot HAM engagement (2018), where contextual inquiries and generative interviews with vendor companies (HamStrength Cabinets, Ritzy Mirrors, Moen) were synthesized into 6 personas (Alyssa, Faye, Allen, Barbara, Harold, Lonnie) that drove the Supplier Hub backlog.

Output locations