What is a user interview script?

A user interview script is the prepared runsheet a researcher follows during a session: how to open, the questions to ask in order, where to probe, and how to close. It keeps sessions consistent enough to compare while leaving room to follow something unexpected. Most run 30 to 45 minutes. A good script reads conversationally, so the interview doesn't feel like a form being completed.

What questions should you ask in a user interview?

Ask about the last time something happened rather than what people generally do. Walk me through the last time you tried to do this. What did you do just before that? What was the most frustrating part? What did you try that didn't work? Avoid asking whether someone would use a feature, because predictions about future behaviour are unreliable and people are polite.

What are good user research interview questions?

The strongest user research interview questions are open, past-tense and specific. Tell me about the last time you did this. Who else was involved? What happened next? How did you decide? Follow each answer with a short probe such as "what made you do that" rather than moving to the next item. UX user interview questions work the same way: behaviour first, opinion second.

How long should a user interview take?

Thirty to forty-five minutes suits most sessions. Under twenty and you rarely get past surface answers, since people need a few minutes to settle. Over an hour and both sides tire, and the last stretch produces little worth using. If you're also running a demo, budget the interview and the testing separately rather than assuming one hour covers both.

Should you record user interviews?

Record when you can, and always ask first. A recording lets you quote accurately and lets people who weren't present hear the tone rather than a summary. Ask at the start rather than mid-session, note the answer on the script, and say what happens to the file. Some participants decline, which is why the template keeps a permission field and a link field separately.

TemplatesStrategy & canvasesUser Interview Script

User Interview Script

A user interview script is the runsheet a researcher follows in a session: which questions to ask, in what order, and where to write down what the participant actually said. This template pairs the script with the record. A header captures the participant, the research purpose and recording consent, question blocks hold the answers beneath them, a user testing section logs per-feature observations, and a nested board collects the findings.

Use this template

User interview script with a session header covering participant details, research purpose and recording permission, an agenda checklist, question blocks with answer lines, a user testing section, and a findings board. — Session header with consent, agenda checklist, questions with answers, testing notes, findings.

What's included

A session header. Date, participant name, title, company and email, previous interactions, research purpose, interviewer, and a recording link.
A recording permission field. A yes or no on the doc itself, so you never discover after the fact that one session can't be quoted.
A four-phase agenda checklist. Introduction, questions, demo and user testing, follow up, ticked off as the session moves.
Question blocks with answers underneath. Three to start with, each pairing the question you planned with the reply as it comes.
A user testing section. Per-feature slots for comments and observations, kept apart from the interview answers above them.
A nested findings board. An embedded board at the end where the synthesis sits alongside the raw session it came from.

Why script a user interview?

Every participant gets the same questions. A written script is what makes eight sessions comparable rather than eight separate conversations.
Consent is on the record. The permission field means you know which sessions can be quoted before you start writing the report.
Answers land next to their question. Writing the reply under the question saves reconciling a transcript against scattered notes a week later.
Behaviour stays separate from opinion. The user testing section keeps what someone did during the demo apart from what they said about it.
Findings stay traceable. The nested board keeps the synthesis in the same file as the evidence, so a conclusion can be checked.

How to use this template

Duplicate it per participant. Copy this user interview template for each session and fill the header before the call rather than during it.
Ask permission at the top. Raise recording in the first minute and tick the field, because asking later interrupts the part you most want on tape.
Write your questions in advance. Replace the placeholder blocks with the questions you actually plan to ask, in the order you'll ask them.
Type answers as they come. Fill the answer line under each question during the session, in the participant's words rather than your paraphrase.
Log observations per feature. During the demo, note what the person did and where they hesitated, one block per feature.
Synthesise while it's fresh. Open the findings board the same day, before the next session overwrites your memory.

Prep your next interview

User interview vs usability testing

A user interview asks people about their experience: what they do, what gets in the way, what they've tried. Usability testing watches them attempt a task and records where they hesitate or fail. Interviews surface motivation, which people can describe. Usability tests surface friction, which people usually can't. This doc works as both a user research interview template and a usability testing template, because one session often runs the interview first and the demo second.

Frequently asked questions

A user interview script is the prepared runsheet a researcher follows during a session: how to open, the questions to ask in order, where to probe, and how to close. It keeps sessions consistent enough to compare while leaving room to follow something unexpected. Most run 30 to 45 minutes. A good script reads conversationally, so the interview doesn't feel like a form being completed.
Ask about the last time something happened rather than what people generally do. Walk me through the last time you tried to do this. What did you do just before that? What was the most frustrating part? What did you try that didn't work? Avoid asking whether someone would use a feature, because predictions about future behaviour are unreliable and people are polite.
The strongest user research interview questions are open, past-tense and specific. Tell me about the last time you did this. Who else was involved? What happened next? How did you decide? Follow each answer with a short probe such as "what made you do that" rather than moving to the next item. UX user interview questions work the same way: behaviour first, opinion second.

Thirty to forty-five minutes suits most sessions. Under twenty and you rarely get past surface answers, since people need a few minutes to settle. Over an hour and both sides tire, and the last stretch produces little worth using. If you're also running a demo, budget the interview and the testing separately rather than assuming one hour covers both.
Record when you can, and always ask first. A recording lets you quote accurately and lets people who weren't present hear the tone rather than a summary. Ask at the start rather than mid-session, note the answer on the script, and say what happens to the file. Some participants decline, which is why the template keeps a permission field and a link field separately.