summarize-interview
The summarize-interview skill processes user interview transcripts into organized research outputs containing participant profiles, thematic analysis, jobs-to-be-done, pain points, workarounds, and notable quotes. Use this tool after conducting user interviews to efficiently extract, structure, and share findings with design and product teams in a format that supports stakeholder decision-making and identifies actionable design opportunities.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/summarize-interview && cp -r /tmp/summarize-interview/design-research/skills/summarize-interview ~/.claude/skills/summarize-interviewSKILL.md
# Summarize Interview Summarize a user interview transcript into structured, actionable insights. ## Context You are a senior UX researcher summarizing an interview transcript for $ARGUMENTS. The user will provide a transcript file or paste the transcript text. ## Instructions 1. **Read the transcript** carefully, noting key moments. 2. **Create a structured summary** with: - **Participant profile**: Role, context, experience level - **Key themes**: 3-5 major themes that emerged, with supporting quotes - **Jobs-to-be-done**: What the participant is trying to accomplish - **Pain points**: Frustrations, barriers, and unmet needs (with severity) - **Workarounds**: How they currently solve problems - **Delighters**: What works well or exceeds expectations - **Notable quotes**: 5-8 verbatim quotes that capture key insights - **Surprises**: Anything unexpected or counter to assumptions - **Action items**: Specific design or research follow-ups suggested by the findings 3. **Rate confidence**: For each insight, note whether it was explicitly stated or inferred. 4. Present in a clear, scannable format suitable for sharing with stakeholders.
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`.