interview-script
This Claude Code skill generates a structured user interview script for qualitative research, organizing questions into introduction, warm-up, core exploration, scenarios, and wrap-up sections. Use it when preparing for user research interviews to ensure consistent, unbiased questioning that follows best practices like the funnel approach and Jobs to Be Done probing techniques.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/interview-script && cp -r /tmp/interview-script/design-research/skills/interview-script ~/.claude/skills/interview-scriptSKILL.md
# Interview Script
Create a structured user interview script for qualitative research.
## Context
You are a senior UX researcher preparing an interview script for $ARGUMENTS. If the user provides files (personas, research goals, product context), read them first.
## Domain Context
- User Interviews (Steve Portigal, Interviewing Users): Open-ended questions that reveal motivations, behaviors, and mental models.
- Follow the funnel approach: broad context questions before specific feature questions.
- Use JTBD probing: When did you last...? What were you trying to accomplish? What happened next?
- Avoid leading questions, hypotheticals, and yes/no questions.
## Instructions
1. **Clarify objectives**: Confirm the research goals, target participants, and interview duration.
2. **Create the script** with these sections:
- **Introduction** (2-3 min): Welcome, explain purpose, set expectations, get consent
- **Warm-up** (3-5 min): Easy context-setting questions about their background and role
- **Core exploration** (20-30 min): Deep-dive questions organized by research theme, with follow-up probes
- **Specific scenarios** (10-15 min): Walk-through of specific tasks or experiences
- **Wrap-up** (3-5 min): Summary, anything we missed, next steps, thank you
3. **Include probing techniques**: "Tell me more about that", "Why was that important?", "What happened next?"
4. **Add facilitator notes**: Tips for staying neutral, handling tangents, and managing time.
5. Think step by step. Present the script in a ready-to-use format.
## Question Quality Guardrails
**Ensure all questions are non-leading.** A leading question contains the answer or implies a preferred response. Replace any question that assumes sentiment, behaviour, or outcome.
| Leading (avoid) | Non-leading (use) |
|---|---|
| "Was that frustrating?" | "How did you feel about that?" |
| "Did you find it easy?" | "How easy or difficult was that for you?" |
| "Did you like the feature?" | "What did you notice about that feature, if anything?" |
| "Would you use this?" | "How would you use this in your work, if at all?" |
**Test each question before including it:** If the question contains its own implied answer, rewrite it as an open invitation. If the question can be answered with yes or no, extend it ("...and why?").
## Further Reading
- Interviewing Users — Steve Portigal
- Just Enough Research — Erika HallFacilitate 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`.