How to Write a User Interview Guide: Remove "Do You Like It?" from the Questions

An interview guide easily becomes a list designed to hear a desired answer: Is this feature useful? Would you pay? Is this page clearer? Participants often nod politely, and the team leaves with positive-looking notes that cannot support a decision.

An interview guide easily becomes a list designed to hear a desired answer: Is this feature useful? Would you pay? Is this page clearer? Participants often nod politely, and the team leaves with positive-looking notes that cannot support a decision.

01 Start the Guide with the Team's Decision, Not the Questions

First write what the team must decide after the interviews. If the objective is only to "understand users," the guide quickly becomes dozens of unrelated questions.

An actionable research question should look like:

• Why do new customers abandon initial setup?
• How do finance staff reconcile monthly bills, and where are errors most likely?
• What evidence do enterprise customers need before contacting a corporate website provider?
• Why do existing users continue using Excel instead of the system's bulk import?

These are not sentences to read directly to participants. They describe what the team needs to learn. Interview questions must translate them into real experiences participants can recall and describe.

02 Ask What Happened Before Asking What They Think

People struggle to predict future behavior and tend to give socially correct answers. Rather than asking what they would use, ask them to describe the most recent occurrence.

"The most recent time," "which exact day," "who participated," and "what did you do" move answers from attitudes back to behavior.

03 A Good Guide Has a Spine but Is Not a Word-for-Word Questionnaire

An interview guide usually has six parts: introduction, warm-up, background and role, key experience, deep probing, and close. It should help moderators stay consistent without preventing them from following valuable new leads.

45-Minute Interview Schedule

When usability testing is included, shorten the interview portion, place behavioral tasks in the middle, and avoid revealing interface terminology before the test.

04 Reduce the Feeling of Being Evaluated in the Introduction

You can say:

"We are learning how people currently complete this work. We are not testing you, and there are no right answers. You may skip any question you prefer not to answer. With your permission, we will record this discussion only for project analysis."

Do not open by selling product advantages or saying, "We designed a particularly convenient feature." This encourages participants to please the team.

05 Reconstruct Critical Experiences with Timeline Probes

When a participant says, "We usually approve it," do not immediately move on. Follow one concrete occurrence backward and forward:

• What triggered this approval?
• Who received the information first?
• Which tool or file did that person use?
• Who joined during the process?
• Which step required waiting or repeated confirmation?
• What exception occurred?
• How were the result recorded and communicated?
• What did you change the next time a similar situation occurred?

This timeline naturally reveals roles, information, tools, and states and provides better design input than asking, "Which features do you need?"

06 Neutral Probes Feel More Natural Than Repeatedly Asking "Why?"

"Why" can make people defend themselves. Alternate with:

• You mentioned... Can you describe one specific occurrence?
• What information did you see then?
• How did you decide what to do next?
• What concerned you most at this step?
• What would you do without this spreadsheet?
• Who would be affected by this decision?
• Was there a time when the situation was completely different?

The moderator's hardest skill is not asking many questions, but pausing to listen. When participants pause briefly, do not immediately fill in an answer for them.

07 Change the Guide's Focus by Product Stage

Discovery Stage: Understand the Current State and Problem

Focus on existing tasks, triggers, roles, alternatives, costs, and failures. Do not rush to show a solution.

Concept Stage: Validate Value and Comprehension

A low-fidelity concept may be shown, but first ask how participants interpret it and when they would use it before discussing the solution. Do not end with "Do you prefer A or B?"

Design Stage: Validate Flow and Information

Have participants complete tasks and observe behavior; use interview questions to understand judgments and mistakes instead of substituting stated opinions for performance.

After Launch: Understand Adoption and Churn

Start from real usage records and ask about first use, continued use, abandonment, help-seeking, and alternatives. Select participants with data so research does not include only the most active users.

08 An Interview Guide You Can Adapt Directly

Research Objective

Understand the real flow, primary friction, and decision basis when [target role] most recently completed [critical task], providing evidence for [upcoming product decision].

Background Questions

• What are your primary responsibilities on the team?
• How often does this task occur?
• Who do you collaborate with, and which tools do you use?

Most Recent Experience

• Think about the most recent [critical task]. How did it begin?
• Walk through what you did in chronological order.
• Which step took the most time or felt most uncertain?
• When a problem occurred, whom did you ask and which information did you review?
• How did you ultimately confirm the task was complete?

Counterexamples and Variation

• Was there an occasion when the process was completely different? Why?
• How do beginners and experienced users work differently?
• If time were extremely limited, which step would you skip?

Closing

• If you could change one thing, what would you change first?
• What important situation did we not ask about today?

09 Scan for Leading Questions Before the Interview

Check every question for:

• Implying a correct answer, such as "Don't you think...?"
• Asking two questions at once, such as whether something is both easy and efficient.
• Requiring a future prediction, such as "Will you use this often?"
• Substituting product terminology for user language.
• Asking participants to explain a solution the team already chose instead of understanding current behavior.
• Asking only about the average case without specific events and exceptions.

Run a ten-minute pilot with a colleague outside the project. Awkward, repetitive, and difficult questions appear immediately.

Frequently Asked Questions

Should the Interview Guide Be Sent to Participants in Advance?

Usually, share the topic, duration, format, and privacy information, not every question. For sensitive interviews or those requiring materials, explain the scope in advance so participants can prepare.

Can the Product Be Introduced During the Interview?

Yes, but timing matters. If the goal is current behavior, complete that portion before introducing the product, or the description will contaminate subsequent answers.

What If Participants Keep Offering Suggestions?

Thank them, then ask, "Which experience led to this suggestion?" and "Which problem would it solve?" A suggestion is not itself a requirement; the underlying context may be evidence.

Must Every Participant Receive Exactly the Same Questions?

Keep core topics consistent for comparison, while adapting probes to each experience. An interview is not a survey; excessive standardization misses important information.

10 A Strong Guide Gives the Moderator Room to Listen

A mature guide does not make an interview mechanical. It organizes required topics so the moderator can focus on concrete experiences, contradictions, and exceptions. The team returns not with "everyone liked it," but real evidence that can change a design decision.