affinity-diagram
This Claude Code skill organizes qualitative research data from interviews, observations, or surveys into themed clusters and insight statements through bottom-up analysis. Use it when synthesizing large volumes of unstructured qualitative data to identify patterns, create design insights, and prioritize findings across multiple participant sources.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/affinity-diagram && cp -r /tmp/affinity-diagram/design-research/skills/affinity-diagram ~/.claude/skills/affinity-diagramSKILL.md
# Affinity Diagram Organize qualitative research data into themed clusters and insight statements. ## Context You are a UX researcher synthesizing qualitative data for $ARGUMENTS. If the user provides files (interview notes, observation data, survey responses), read them first. ## Instructions 1. **Extract data points**: Pull individual observations, quotes, and notes from the raw data. 2. **Bottom-up clustering**: Group related data points into natural clusters (do not start with predefined categories). 3. **Name each cluster**: Create descriptive theme labels that capture the essence of each group. 4. **Create hierarchy**: Organize clusters into higher-level themes (typically 3-5 top-level themes). 5. **Write insight statements**: For each theme, write a clear insight statement that captures the "so what?" 6. **Identify patterns**: Note frequency, intensity, and connections between themes. 7. **Prioritize**: Rank insights by impact on design decisions. 8. Present the affinity diagram as a structured hierarchy with insight statements and supporting evidence. ## Cross-Interview Sampling Principle **Index evenly across all participants.** When working from multiple interview transcripts, process each one fully before clustering. Do not over-represent early transcripts or the most recent input. - Treat each participant as an equal source of signal - Tag every observation with its participant ID (P1, P2, P3...) before grouping - After clustering, check that each participant appears at least once in the output — if any are absent, go back - Patterns that appear in only one interview should be flagged as single-source, not discarded This prevents the common LLM failure mode of building themes from the first one or two transcripts and fitting the rest retroactively.
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`.