Create evidence-based user personas with empathy maps. Develop detailed user archetypes from research data to guide product decisions and maintain user-centered focus.
Create evidence-based user personas with empathy maps from research data. Use when developing detailed user archetypes to guide product decisions and maintain user-centered focus.
/plugin marketplace add melodic-software/claude-code-plugins/plugin install product-discovery@melodic-softwareThis skill is limited to using the following tools:
Use this skill when:
Personas are fictional representations of key user segments based on real research data. They help teams maintain empathy for users throughout the product development process by making abstract user segments concrete and memorable.
| Type | Based On | Best For |
|---|---|---|
| Research-Based | Extensive user research | Mature products, significant investment |
| Proto-Persona | Team assumptions | Early stage, hypothesis generation |
| Jobs Persona | JTBD analysis | Outcome-focused products |
| Buyer Persona | Purchase behavior | B2B, sales-focused products |
| Negative Persona | Anti-patterns | Avoiding wrong customers |
| Component | Description | Example |
|---|---|---|
| Name | Memorable, representative | "Developer Dana" |
| Photo | Representative image | Stock photo or illustration |
| Quote | Captures essence | "I need to ship fast without breaking things" |
| Demographics | Relevant background | Role, experience, company size |
| Goals | What they want to achieve | "Reduce code review time" |
| Frustrations | Pain points and blockers | "Manual processes slow me down" |
| Behaviors | How they work | "Reviews 5-10 PRs daily" |
| Technology | Tools and preferences | "VS Code, GitHub, Slack" |
| Component | Description |
|---|---|
| Bio | Brief narrative background |
| Day in the Life | Typical workflow |
| Influence Map | Who influences their decisions |
| Success Metrics | How they measure success |
| Objections | Concerns about solutions |
The empathy map captures four quadrants of user experience:
┌─────────────────────────────────────────────────────────────────┐
│ SAYS │
│ What do they say out loud? Direct quotes from interviews. │
│ "I spend half my day in code reviews" │
│ "The process is frustrating but necessary" │
├────────────────────────────────┬────────────────────────────────┤
│ THINKS │ DOES │
│ What are they thinking? │ What actions do they take? │
│ (May differ from says) │ Observable behaviors │
│ "Is this code really safe?" │ Reads every line carefully │
│ "I might miss something" │ Cross-references documentation│
│ "This is taking too long" │ Uses multiple browser tabs │
├────────────────────────────────┴────────────────────────────────┤
│ FEELS │
│ Emotional state during the experience │
│ 😰 Anxious about missing bugs 😤 Frustrated with slow tools │
│ 😊 Satisfied when helping team 😩 Overwhelmed by PR volume │
└─────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────┐
│ PAINS │
│ Obstacles, frustrations, risks │
│ • Repetitive manual tasks │
│ • Context switching overhead │
│ • Fear of missing critical issues │
├─────────────────────────────────────────────────────────────────┤
│ GAINS │
│ Wants, needs, success measures │
│ • Faster time to merge │
│ • Confidence in code quality │
│ • Recognition from team │
└─────────────────────────────────────────────────────────────────┘
Data Sources:
Minimum Viable Research:
Affinity Mapping:
Behavioral Variables:
For each distinct user segment:
Role: [Job Title / Role] Experience: [Years in role, expertise level] Context: [Company size, industry, team structure]
Quote: "[Memorable quote that captures their perspective]"
[2-3 paragraph narrative of typical day]
Role: Senior Software Engineer Experience: 6 years, full-stack development Context: Mid-size SaaS company (200 employees), 8-person engineering team
Quote: "I want to ship quality code fast. The review process shouldn't be the bottleneck."
Dana starts the day by checking Slack and email for urgent reviews. After the daily standup, she spends about 2 hours reviewing PRs from overnight work. She tries to batch reviews to minimize context switching, but urgent PRs often interrupt her coding blocks.
Afternoons are for her own development work, but she's frequently pulled into discussions about code patterns and architecture decisions. She mentors two junior developers who often ask for quick reviews of their work.
When research data is limited, create proto-personas based on team assumptions.
┌─────────────────────────────────────────────────────────────────┐
│ Name: [Descriptive Name] [Sketch/Icon] │
│ Role: [Job Title] │
├─────────────────────────────────────────────────────────────────┤
│ Behaviors: │ Needs/Goals: │
│ • [Assumed behavior 1] │ • [Assumed need 1] │
│ • [Assumed behavior 2] │ • [Assumed need 2] │
│ • [Assumed behavior 3] │ • [Assumed need 3] │
├─────────────────────────────────────────────────────────────────┤
│ Pain Points: │ Demographics: │
│ • [Assumed pain 1] │ • [Age range, if relevant] │
│ • [Assumed pain 2] │ • [Company size] │
│ • [Assumed pain 3] │ • [Tech experience] │
└─────────────────────────────────────────────────────────────────┘
Important: Proto-personas are hypotheses. Validate with research!
When using JTBD, create personas around jobs rather than demographics.
Job: [The main job to be done]
When I... [situation/context] I want to... [motivation] So I can... [expected outcome]
Hiring Criteria:
Firing Triggers:
Given interview transcripts:
Given usage data:
Review persona against:
❌ Creating too many personas (3-5 is usually enough) ❌ Including irrelevant demographics (if it doesn't affect behavior, skip it) ❌ Making personas too perfect (include realistic flaws) ❌ Letting personas become stale (update quarterly)
Inputs from:
design-thinking skill: Empathy research → Persona datajtbd-analysis skill: Job context → Jobs personasOutputs to:
design-sprint skill: Personas for prototype testingFor additional Persona Development resources, see:
Master defensive Bash programming techniques for production-grade scripts. Use when writing robust shell scripts, CI/CD pipelines, or system utilities requiring fault tolerance and safety.