product-user-interview-design

Standalone Mode: This skill is part of the prepkit-product plugin.

• spec/product-context.md is optional — provide context inline or create one from the template.
• Output paths (research/, reports/) are relative to your current working directory.
• Facilitation routing is advisory — invoke any skill directly.

Product User Interview Design

When To Use

• Discovery or validation says the next move is research
• A decision is blocked by weak user evidence
• The team knows it needs interviews but has not designed the study
• ## Research Plan is empty, stale, or incomplete

Key Concepts

• Decision-driven research: interviews exist to change a decision, not just collect quotes
• Exploratory vs. confirmatory: match the interview type to the confidence gap
• Participant fit: recruit for the problem context, not convenience — participant fit includes both problem-context fit and demographic/ability diversity; a homogeneous pool that matches the primary persona will miss exclusion patterns that only emerge when users with different abilities, ages, language backgrounds, or access constraints are included
• Completion criteria: define "enough learning" before interviews begin
• Cross-market sampling: When the product serves multiple markets, research design must account for market diversity. Include at least 2 markets in the participant mix unless the research question is market-specific. If the pack manifest declares a teamContext file, use its market list for sampling guidance.

Rules

• Start with the decision to validate, not the interview script
• Choose the interview type based on the evidence gap
• Present 2-3 research design options and recommend the smallest study that can unblock the decision with credible signal — over-designed research packages delay decisions without proportionally improving evidence quality.
• Keep outputs in active-plan research/ by default
• No default stakeholder-summary artifact belongs in reports/
• Reuse or refine an existing ## Research Plan before starting over
• Design interview questions around user outcomes and behavior, not feature wishlists — asking "what would you want us to build?" produces feature requests; asking "what are you trying to accomplish and where does it break down?" produces actionable outcome gaps
• Apply all output quality gates from references/product-quality-gates.md.
• Cap interview studies at 8–12 participants for a homogeneous qualitative round. If testing across distinct user groups, recruit 4–5 per group. More interviews do not proportionally improve signal quality — diminishing returns set in after 8 for a single segment.