How to Write Good User Interview Questions
Good user interview questions are open-ended, grounded in specific past behavior, and free of hints about the answer you're hoping to hear. Weak questions are closed-ended, ask about hypothetical future behavior, or subtly lead the person toward confirming what you already believe. The difference between the two determines whether an interview actually reveals something new, or just politely confirms your existing assumptions.
Quick facts
- Strong questions ask about specific, real past behavior — "tell me about the last time you..." — not hypothetical future intentions.
- Open-ended questions ("walk me through...") reveal far more than closed, yes/no questions.
- Leading questions ("don't you think X would help?") should be avoided — they invite polite agreement, not honest insight.
- This connects directly to How to Conduct Effective User Interviews, which covers the broader interview process this question-writing feeds into.
The core principles behind a strong question
| Principle | Why it matters |
|---|---|
| Open-ended, not closed | Invites a real story, not a one-word answer |
| Grounded in past behavior, not hypothetical future intent | People are unreliable predictors of their own future behavior, but accurate reporters of what they've actually done |
| Free of leading language | A question that hints at the "right" answer produces false confirmation, not honest insight |
| Specific, not overly broad | "Tell me about the last time X happened" beats "what do you think about X in general" |
Strong vs weak questions, side by side
| Weak question | Why it's weak | Stronger version |
|---|---|---|
| "Would you use a feature that does X?" | Asks about hypothetical future behavior, which people predict poorly | "Tell me about the last time you needed to do something like X — what did you actually do?" |
| "Do you like our onboarding?" | Closed-ended, invites a polite, unhelpful answer | "Walk me through what happened the first time you used the product." |
| "Don't you find the current process frustrating?" | Leading — suggests the expected answer | "How do you feel about the current process?" |
| "What features do you want?" | Asks for a solution, not the underlying problem | "What are you trying to accomplish when you run into that issue?" |
How to write your interview question guide, step by step
- Start with what you're actually trying to learn. A vague goal produces vague questions — get specific about the real question this interview is meant to answer before drafting anything.
- Draft open-ended starting questions for each topic. Use "walk me through," "tell me about," and "how did you" as natural openers that invite a real story rather than a short answer.
- Check each question for hidden leading language. Read each one back and ask: does this hint at an answer I want to hear? If so, rewrite it more neutrally.
- Anchor questions in specific past events, not general opinions. "Tell me about the last time you did X" produces more reliable, concrete insight than "what do you generally think about X."
- Prepare follow-up prompts, not just opening questions. "Tell me more about that" and "why was that frustrating" are often where the most valuable insight actually surfaces, deeper than the first answer.
- Keep the guide loose, not rigid. Treat it as a starting point you can deviate from when an unexpected, interesting answer opens up a thread worth following.
Why "tell me about the last time" beats "would you"
People are consistently unreliable at predicting their own future behavior, especially regarding a hypothetical feature or scenario they haven't actually experienced. Asking about a specific, real, recent example instead anchors the conversation in what someone actually did — a far more reliable signal of real behavior than a hypothetical guess about what they'd probably do. This single substitution — replacing "would you" questions with "tell me about the last time" questions — is one of the highest-leverage changes to make when writing an interview guide.
Common mistakes when writing interview questions
- Writing mostly closed, yes/no questions. These produce thin, easily exhausted answers rather than the rich, detailed stories that reveal real insight.
- Asking multiple questions at once. A compound question ("what do you like and dislike about X") often gets only a partial answer, since the person tends to respond to just one part.
- Including your own assumed solution inside the question. "Would a dashboard help you track this?" primes the person toward a specific answer rather than letting the real need emerge naturally.
- Writing a rigid script and following it exactly, regardless of what comes up. The best insight often comes from following an unexpected thread, not sticking rigidly to a pre-written list.
FAQ
How many questions should a user interview guide include? Fewer than you'd think — many effective interview guides have just 5-8 core open-ended questions, with room for follow-ups, since a good open-ended question often generates enough material to fill significant conversation time on its own.
Should interview questions be sent to participants in advance? Generally not recommended — sending questions ahead of time often produces more rehearsed, less spontaneous answers than asking them live, where genuine first reactions and specific memories are more likely to surface naturally.
How do I write good follow-up questions on the spot? Simple, generic prompts work well and don't need to be prepared in detail — "tell me more about that," "why was that frustrating," and "what happened next" all work across almost any topic and reliably surface deeper insight.
Is it okay to ask about a competitor's product during a user interview? Yes, and it can be valuable — asking what alternatives someone considered or currently uses can reveal real competitive context and unmet needs that questions about your own product alone might miss.