research methods
User interviews
How do you ask good user interview questions?
A user interview is a one-to-one conversation to understand someone's needs, context and experience. Its quality lives almost entirely in the questions: ask about real past behaviour and you get evidence; ask hypotheticals, leading or yes/no questions and you get polite fiction. The craft is getting people to tell you what they actually did, not predict what they might do or guess what you want to hear.
Also known as: user interviews, interview questions, research interviews, depth interviews
Prefer to watch?
Watch the recap 0:54
The demo
You're about to interview a user. For each weak question below, pick the rewrite that will actually get you a useful answer - then see why.
What this demo shows (text version)
Each round presents a weak interview question - a hypothetical ("would you use a feature that saves favourites?"), a leading or yes/no question ("do you find the app easy?"), or one that asks users to design ("what features do you want?") - alongside two rewrites. You pick the stronger one, and the reveal explains why: the best questions are open, neutral and about specific past behaviour ("tell me about the last time you wanted to come back to something"), because people report what they did far more reliably than they predict what they'd do.
The craft of interviewing is mostly this - asking for memories not prophecies, following the participant rather than a script, using silence, and never outsourcing design to the user. Combined with observation (since what people say and do diverge), good questions are what turn a chat into evidence.
Good interview questions are open, neutral and about the past: "tell me about the last time you…" beats "would you use…?" every time. People are terrible at predicting their own behaviour and eager to please, so hypotheticals, leading questions and yes/no questions produce unreliable answers. Ask what they did, dig into the why, embrace silence, and never ask users to design your product for you.
Each "better" question pulled for a real story instead of a flattering guess - "tell me about the last time" rather than "would you like…". That's the whole craft: people can't reliably predict what they'd do, but they can tell you what they did. Ask for the memory, not the prophecy, and the answers are worth something.
The most reliable questions are grounded in specific past behaviour: "walk me through the last time you tried to do X", "what happened then?", "what were you hoping for?". Hypotheticals ("would you use a feature that…?") ask people to predict themselves, which they do badly and optimistically; leading questions ("how helpful was that?") hand over the answer; and yes/no questions close down the story you actually want.
Technique matters as much as wording. Ask open questions and then follow the participant's thread rather than marching through a script; use silence - people fill it with the real answer; ask "why" and "tell me more"; and resist the urge to explain, defend or sell, which turns an interview into a pitch. You're there to listen, not to validate.
And don't ask users to be designers. "What features do you want?" outsources your job and yields wish-lists, not insight; people are experts in their problems, not in solutions. Mine the problems, frustrations and workarounds instead, then design the answer yourself. Pair interviews with observation, too, because what people say and what they do diverge.