Interview guide: how to build one step by step
An interview guide structures a user interview. How to build one in four parts, which questions to avoid and how to use it without reading it like a script.
What it is and what it is not
The guide is not a questionnaire. A questionnaire is answered the same way by everyone and applied to many people; an interview is conducted with one person and adapts to what they say. The guide is the map of that conversation.
It is not a script either. The guide is flexible: the interviewer can change the order, skip questions or ask questions that were not written down if the person says something worth exploring. What should not happen is reading the guide out loud like a form.
Why does it matter to a designer?
Because the quality of an interview depends in large part on preparation. A well-built guide helps avoid three typical problems: interviews that wander off topic, questions that suggest the answer, and studies where each session covers different topics, which makes comparison impossible.
The guide is also where the team agrees on what it wants to know before talking to anyone. If, while writing it, you cannot say which design decision the answer would change, it is not yet time to interview.
How do you build one, step by step?
UserTesting proposes a four-part structure, while noting that there is no single correct form. It works as a starting point:
- Research objectives. One or two sentences stating the decision the study will inform.
- Introduction and context questions. Introductions, permission to record, and questions about the person’s life or work.
- Topic sections. The core of the guide: blocks of questions by theme, with time assigned to each.
- Wrap-up. A summary, a closing question (“Is there anything I haven’t asked that I should know?”) and thanks.
Inside the topic sections, follow these principles:
- Write the questions out loud, the way you would say them. UserTesting recommends writing each question as it is going to be said.
- Ask about events, not generalities. Nielsen Norman Group recommends asking about concrete facts, such as “Tell me about the last time you bought something online”, rather than “How do you usually shop?”
- Prepare probes. Neutral prompts such as “Can you give me an example?” or “Tell me more about that” work for almost any answer.
- Assign time to each topic. If the session lasts 45 minutes, the last topic you did not reach is the one you will regret.
Which questions should you avoid?
The general rule is that a question should not contain its own answer. Four types show up often (the examples are illustrative):
| Type | Bad example | Why it fails | Alternative |
|---|---|---|---|
| Leading | “Don’t you find the menu confusing?” | It pushes the person to agree | “What did you do the last time you looked for something in the menu?” |
| Hypothetical | “Would you use an alerts feature?” | According to Nielsen, users cannot reliably predict whether they would use something that does not exist yet | “How do you tell your team today when something changes?” |
| Presumptive | “What was the last book you read?” | It assumes they read one | “What do you read lately, if anything?” |
| Opinion about something that exists | “How useful is feature Y?” | It asks for an abstract rating | “Show me how you use feature Y” |
Nielsen gives a warning worth remembering: people can make up an opinion about almost anything. That is why it helps to ask what someone did rather than what they think they would do.
There are also questions an interview cannot answer. Nielsen gives a clear example: “Should the Buy button be red or orange?” According to Nielsen, that is settled by watching users with the design or with a comparative test, not by asking people.
How do you use it in the session?
Before starting, read the guide aloud once. You will notice which question sounds odd. Then run a pilot interview: NN/g warns that even the best guide may need tweaks after the first interview, and that a pilot lets you spot them before running all the others.
During the session, your job is to listen more than you talk. When the person mentions something interesting that is not in the guide, note it and explore it. At the end, check which topics were left uncovered and decide whether a second session is worth it or whether the results are already enough.
After each interview, complete a short note with three columns: what the person did, what they said and what caught your attention. That note is the raw material for research synthesis, where what you learned becomes patterns. If the study frame is not yet clear, the research plan comes before the guide. Before closing the guide, also review how to recruit participants, because the profile of the person changes the context questions. For the full method, read user interviews.
Example
Illustrative example: a team wants to understand why customers of a furniture store abandon their cart. Its guide has four topics: recent purchases, product search, delivery and payment. In the delivery topic, instead of asking “Would you like to choose the delivery date?”, it asks: “Tell me about the last time you bought something big for your home. What happened from the moment you clicked buy until it arrived?” The answers reveal that two people could not choose a time slot and had to switch stores. That is data, not an opinion.
For your next interview: write three questions from your guide, rewrite each one around a concrete event and read each aloud. If one sounds like a survey, change it.
Common mistakes
- A 30-question guide that the session cannot cover in half.
- Leading questions that confirm what the team already believes.
- Hypothetical questions about features that do not exist yet.
- Reading the guide like a form without listening.
- Not assigning time, and finding out at the end that the important topic was left out.
- Using the guide for design questions such as colours or button placement.
- Changing the guide between sessions without recording it, which makes comparison impossible. Adjusting it after the pilot is normal; note what changed and when.