In short
Ask about past behaviour rather than future intentions, because people predict their own behaviour badly and describe it accurately. Avoid questions that suggest an answer, that ask people to imagine hypotheticals, or that ask why they did something in a way that invites rationalisation. The most useful question in most interviews is simply asking someone to walk you through the last time they did the thing.
The core problem
People describe their past behaviour reasonably accurately. They predict their future behaviour badly, and they explain their own motivations by constructing plausible reasons after the fact.
That single fact determines what you can usefully ask.
"Would you use a feature that did X?" produces an answer with no predictive value. People say yes to be agreeable, or because it sounds reasonable in the abstract, or because they cannot imagine the cost of adopting it.
"When did you last need to do X, and what did you do?" produces something real.
Ask about the last time
The most productive question in most interviews: "Tell me about the last time you did this."
It anchors to a specific event rather than a general impression. General impressions are averaged, tidied, and unreliable; a specific memory contains the workaround, the frustration, and the detail nobody would think to volunteer.
Follow with the mechanics. What happened first? What did you do then? Where did you get stuck? What did you do instead?
That sequence produces more usable material than an hour of general discussion.
Do not ask about hypotheticals
"If we built X, would you use it?" is unanswerable, and the answer is usually yes.
The honest version is to ask about the problem the feature would solve. Do they have that problem? When did it last occur? What did they do about it? Did they pay for anything to address it?
What people have already paid for or worked around is the strongest signal available, because it is behaviour rather than opinion.
Do not lead
Leading questions are easy to write without noticing.
"How frustrating was the checkout?" assumes frustration. "How was the checkout?" does not.
"Don't you think it would be easier if..." is not a question; it is a proposal seeking agreement, and interviewees generally agree.
Watch for embedded assumptions, positive framing, and any question whose phrasing indicates the answer you hope for. Reading questions aloud beforehand catches most of them.
Be careful with why
"Why did you do that?" invites rationalisation. People generate a plausible reason, and often believe it.
Better approaches: "What were you trying to do?" which asks about the goal rather than the motive. "What did you expect to happen?" which surfaces the mental model. And "What were you looking at when you decided?" which anchors to something observable.
Why is not forbidden — it is useful for surfacing constraints — but treat the answers as hypotheses rather than facts.
Question shapes worth using
Open, then specific. Start broad, then narrow into detail. Starting narrow constrains what you learn to what you already suspected.
One thing at a time. "Was it easy to find and use?" gets one answer covering two questions, and you cannot tell which.
Neutral scales. If you use a rating, label both ends symmetrically rather than running from adequate to excellent.
Silence. The most under-used technique. After an answer, wait. People fill silence with the qualification they were going to omit, and that is frequently the useful part.
What to ask before a redesign
Useful ground to cover with existing users: what they use it for, what they do most often, the last time something was difficult, what they have stopped using and why, what they do outside the product to make it work, and what would make them leave.
That last question is more revealing than asking what they like — dissatisfaction is specific, and satisfaction is vague.
Writing a guide, not a script
Write the questions down, then be willing to abandon them.
The purpose is to ensure you cover what matters, not to march through in order. When someone says something unexpected, follow it — the unplanned tangent is often where the finding is.
Keep it short. Eight to ten prepared questions fills forty-five minutes once you follow up properly, and a longer list encourages rushing.
The check before you run it
Read each question aloud and ask: does it suggest an answer, does it ask about the future, does it ask two things, and could it be answered with a specific story rather than a generalisation?
Rewrite anything that fails. It takes twenty minutes and is the difference between research that informs a decision and research that confirms what you already believed — which is the more common outcome, and the harder one to notice.
If you are about to make a significant decision and want the research designed so it can actually change your mind, book a call.
Common questions
What makes a good user research question?
It asks about specific past behaviour rather than future intentions or hypotheticals, does not suggest an answer, and asks one thing at a time. The most productive question in most interviews is simply asking someone to walk through the last time they did the thing you are researching.
Why shouldn't you ask users if they would use a feature?
Because people predict their own behaviour badly. They say yes to be agreeable, because it sounds reasonable in the abstract, or because they cannot imagine the cost of adopting it. Ask instead whether they have the problem it would solve, when it last occurred, and what they did about it.
Is it wrong to ask users why they did something?
Not wrong, but treat the answers as hypotheses rather than facts, since 'why' invites people to construct a plausible reason after the event. Asking what they were trying to do, what they expected to happen, or what they were looking at when they decided produces more reliable material.
How do I avoid leading questions?
Watch for embedded assumptions and positive framing — 'how frustrating was the checkout' assumes frustration, while 'how was the checkout' does not. Reading every question aloud before the session catches most of them, as does removing any phrasing that signals the answer you hope for.
How many questions should a research interview have?
Eight to ten prepared questions is enough for forty-five minutes once you follow up properly. Treat them as a guide rather than a script and be willing to abandon the order — the unplanned tangent when someone says something unexpected is often where the real finding is.
