User Interview Script Template
A user interview script template with opening protocol, warm-up questions, problem exploration, solution probing, and closing. Includes a notetaking framework. Free to copy, download, and use. No signup required.
# User Interview Script **Interview goal:** [One sentence — what you're trying to learn] **Interviewer:** [Name] **Duration:** [45–60 minutes] **Format:** [Video call / in-person] > **Before you start:** Record with permission. Take sparse notes — don't type full sentences or you'll stop listening. Have a notetaker if possible. --- ## Pre-Interview Checklist - [ ] Recording consent obtained - [ ] Notetaker briefed (if applicable) - [ ] Screener confirms participant fits target profile - [ ] Interviewer has NOT shared product screenshots or features yet --- ## Opening (5 minutes) > Build rapport. Reduce social desirability bias. Set expectations. "Thanks so much for joining today. This call is about understanding how you [general topic — e.g. 'currently manage customer feedback'], not about testing anything I've built. There are no right or wrong answers — I genuinely want to understand your experience, even if that includes things that are frustrating or broken. I'll be mostly asking questions and listening. You can stop at any time and there's nothing confidential here — I might share anonymised quotes with my team. Do I have your permission to record this call for my own notes? [Wait for yes.] Any questions before we start?" --- ## Warm-Up (5 minutes) > Establish context and get them talking. Start broad. 1. "Tell me a bit about your role and what a typical day looks like for you." 2. "How long have you been doing [relevant activity]?" 3. "What tools do you use day-to-day for [topic area]?" --- ## Problem Exploration (20 minutes) > Explore the problem space deeply. Do NOT mention your solution. Use "tell me more" liberally. **Main question:** "Walk me through the last time you had to [do the job you're investigating]. Start from the beginning." **Follow-up probes (use as needed — don't ask all):** - "What were you trying to accomplish at that point?" - "What did you do next?" - "What was frustrating about that step?" - "How long did that take?" - "What did you do to work around [problem]?" - "What would have made that easier?" - "How often does this happen?" - "What's the impact when this goes wrong?" - "Who else is involved when you do this?" **Dig into their current solution:** - "What tools or processes do you use today for this?" - "What do you like about how you do it currently?" - "What would you change if you could?" - "Have you tried other tools? What happened?" --- ## Solution Probing (10 minutes) > Use only if you have a specific hypothesis to test. Show mockups or describe the concept. > ⚠️ **Important:** Do not describe the solution before completing the Problem section. Let the problem dictate what you show. "I'd like to show you something we're thinking about and get your honest reaction." [Show mockup / describe concept] - "What's your first reaction?" - "What would you expect to happen if you clicked/tapped [X]?" - "When in your workflow might you use something like this?" - "What would make you trust this output?" - "What's missing that would make this useful for you?" - "Would you pay for something like this? What would feel like a fair price?" --- ## Closing (5 minutes) - "Is there anything you expected me to ask that I didn't?" - "Is there anyone else you think I should talk to about this?" - "Would you be open to a follow-up call if we have specific questions later?" "That's really helpful — thank you. I'll send you a summary of our main takeaways in the next week." --- ## Notetaking Template Use this during the call. Fill in immediately after. **Participant:** [Code/name] | **Date:** [Date] | **Duration:** [X min] | Category | Notes | Quotes (verbatim) | |---|---|---| | Context / role | | | | Current workflow | | | | Pain points | | | | Workarounds | | | | Reactions to concept | | | | Surprising / unexpected | | | **Top 3 insights from this interview:** 1. 2. 3. **Open questions this interview raised:** -
How to use this Interview Script template
Never show the solution before exhausting the problem
The biggest mistake in user interviews is revealing your solution in the first 10 minutes. Once you describe what you're building, the participant starts trying to help you rather than describing their actual experience. Complete the Problem Exploration section first — always.
Use the 'walk me through the last time' prompt
Abstract questions get abstract answers. 'Walk me through the last time you...' grounds the conversation in a specific, recent memory with real emotions and real friction. It's the single most valuable interview technique.
Take sparse notes — listen more than you type
Full-sentence notetaking while interviewing means you stop listening. Capture keywords, short phrases, and exact quotes in the moment. Fill in the Notetaking Template within 30 minutes of the call ending while memory is fresh.
End with 'Is there anything you expected me to ask that I didn't?'
This closing question surfaces the topics participants assumed were relevant but didn't come up. It often reveals the most important insight of the session — the thing they were waiting to say.
Want a Interview Script grounded in your actual customer data?
PMRead ingests your customer interviews, feedback, and Slack threads — and generates PRDs backed by real evidence, not guesses.
Frequently asked questions
How many user interviews do I need?
5 interviews within a single user segment typically reveal 85% of the patterns (Nielsen's law). For a new product or major pivot, aim for 10–15 across 2–3 segments. Quality matters more than quantity — one deep 60-minute interview with a real target customer beats five 15-minute calls with anyone who'll talk to you.
Should interviews be recorded?
Yes, with consent. Recordings let you quote customers accurately and share clips with stakeholders who weren't on the call. They also mean you can focus on listening rather than frantic note-taking. AI transcription tools (Otter.ai, Grain, Fireflies) reduce the effort to near zero.
Who should conduct user interviews — PM or UX researcher?
Ideally both, but PMs who conduct their own interviews build far deeper empathy than those who only read research reports. The PM should be present in at least 50% of interviews, even if a researcher leads. Hearing a customer say 'this is the most frustrating part of my job' directly is irreplaceable.
How do I handle participants who jump to solution suggestions?
Acknowledge it and redirect: 'That's really interesting — I want to make sure I understand the problem before we talk about solutions. Can you tell me more about what's frustrating when you do X today?' Don't ignore solution suggestions — log them — but don't let them derail the problem exploration.
Other free templates