User interview script that avoids leading questions

You are a user researcher. Write an interview script for the study below.

Product or topic: [WHAT WE ARE STUDYING]
Research goal: [WHAT WE NEED TO LEARN, e.g. "how small landlords track repairs today"]
Decisions this research will inform: [e.g. "whether to build a repair-tracking feature"]
Participants: [WHO, AND HOW THEY WERE RECRUITED]
Interview length and format: [e.g. "45 minutes, video call"]
Assumptions we want to test: [LIST OUR BELIEFS, e.g. "landlords use spreadsheets"]

Produce:
1. An introduction script: purpose, consent to record, no right or wrong answers, permission to stop.
2. Warm-up questions (5 minutes) about their context.
3. Core questions (most of the time) about specific past experiences, e.g. "Tell me about the last time...". Group them by theme and give a time estimate per section.
4. Neutral probes to use after any answer, such as "What happened next?" or "Why was that important?".
5. A wrap-up with "Is there anything I should have asked?" and next steps.
6. A note-taking template with columns for quote, behaviour, pain point and surprise.
7. A bias check: list any question in the draft that is leading, hypothetical or asks about future behaviour, and rewrite it.

Rules: do not mention our product idea until the final section, if at all. Prefer questions about what people did over what they would do. Map each assumption to the questions that test it.

Example (excerpt):
Core question: "Tell me about the last repair request you received. How did you find out about it?"
Probe: "What did you do next?"

Assumption "landlords use spreadsheets" is tested by questions 4, 6 and 7, without naming spreadsheets.

Bias check: "Would you use an app that reminds you about repairs?" asks about the future and suggests the answer. Rewrite: "How do you keep track of repairs that are still open?"

When to use it

Use this prompt before talking to customers or users about a problem you want to solve: a new product idea, a feature you are unsure about or a process that is not working. It helps product managers, designers, founders and students doing qualitative research to prepare interviews that produce evidence, not polite agreement.

How to customize it

• [RESEARCH GOAL] and [DECISIONS] keep the script focused. If you cannot name a decision the interviews will inform, the study may be too broad.
• [ASSUMPTIONS] makes your beliefs explicit so the interviews can test them. Writing them down also makes it easier to notice when evidence contradicts them.
• [PARTICIPANTS] affects the warm-up and vocabulary, and reminds you to think about who is missing from your sample.
• Follow your organization’s rules for consent and data handling, and record only with clear permission.

Why it works

People are poor at predicting their own future behaviour and tend to be kind to interviewers. Questions like “Would you use this?” invite a friendly yes that means little. Asking about specific past experiences gives you facts about what people actually do, and neutral probes reveal the reasons behind them.

The bias check gives the script a second review, which catches leading wording that is easy to miss when you are close to an idea. Mapping assumptions to questions ensures the interviews answer what you need to know. Keeping the product idea until the end avoids anchoring answers.

Tips and variations

• Run a pilot interview with a colleague and adjust timings.
• Listen more than you talk; silence often brings the most useful details.
• Analyze several interviews together with our thematic analysis prompt.
• For larger samples, follow up with a survey built with our survey question design prompt.
• Turn findings into a customer persona grounded in real quotes.
• After each interview, write three lines straight away: the most surprising thing you heard, a quote you want to remember and one assumption that now looks weaker. These quick notes are often more valuable than the full transcript when you compare interviews.