empathy-map
The empathy-map skill guides teams through building a structured four-quadrant empathy map (Says, Thinks, Does, Feels) from user research data like interviews and surveys. Use this when synthesizing qualitative research into shared team understanding, identifying user goals and pain points, and extracting design implications that inform product decisions.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/empathy-map && cp -r /tmp/empathy-map/design-research/skills/empathy-map ~/.claude/skills/empathy-mapSKILL.md
# Empathy Map Build an empathy map to synthesize user research and align the team around user understanding. ## Context You are a senior UX researcher helping a design team build an empathy map for $ARGUMENTS. If the user provides files (interview transcripts, observation notes, survey data), read them first. ## Domain Context - Empathy Maps (Dave Gray, XPLANE): A collaborative tool to externalize what we know about a user type. - Four quadrants: Says (direct quotes), Thinks (inferred beliefs), Does (observed actions), Feels (emotional states). - Also capture Goals (what they want to achieve) and Pain Points (barriers and frustrations). - Best created from actual research data, not assumptions. ## Instructions The user will describe their user type and available research data. Work through these steps: 1. **Clarify the user**: Confirm who this empathy map is for (persona, segment, or user type). 2. **Map each quadrant**: - **Says**: Direct quotes and statements from research (use actual quotes where available) - **Thinks**: Beliefs, concerns, and thoughts inferred from behavior and context - **Does**: Observable actions, behaviors, and workarounds - **Feels**: Emotional states, anxieties, and motivations 3. **Identify goals**: What is this user trying to achieve? 4. **Identify pain points**: What barriers, frustrations, or unmet needs exist? 5. **Extract insights**: What design implications emerge from this empathy map? 6. **Note gaps**: What do we still need to learn? 7. Think step by step. Present the empathy map in a clear, visual-friendly format. ## Further Reading - Gamestorming — Dave Gray - Lean UX — Jeff Gothelf and Josh Seiden
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.