The question that ruins the most interviews
"Would you use this?"
It feels like the whole point of the session. It is the least informative sentence in research. You are asking a person who is being polite, in a room they did not choose, about a product they saw four minutes ago, to predict what they will do in a situation that has not happened yet.
They will say yes. They are not lying. Predicting your own future behaviour is genuinely hard, and the prediction is made worse by wanting to be helpful to the person who arranged the coffee.
The answer you get is real data about how people respond to being asked that question. It is not data about your product.
Past behaviour is the only evidence in the room
The replacement is not a cleverer hypothetical. It is a change of tense.
"Walk me through the last time you had to pull that report."
Now they are recalling rather than predicting. Recall is imperfect, and it is anchored to something that actually occurred: a Tuesday, a spreadsheet, a colleague they messaged, a workaround they are slightly embarrassed by. All of that is checkable, specific, and impossible to invent smoothly on the spot.
A hypothetical produces a sentence. A recalled event produces a sequence, and the sequence is where the design problem is hiding.
The other thing recall gives you is the workaround. Nobody volunteers "I export to a spreadsheet because your filters cannot do it" when asked what they think of your filters. It falls out of a story about last Tuesday without being asked for.
The four questions that do most of the work
I keep the guide short and lean on these.
- "Walk me through the last time you did X." The spine of the interview. Everything else hangs off the story it produces. 2. "What did you do just before that?" Almost every product problem lives one step upstream of where the team is looking. 3. "What happened next?" Finds the workaround, the second tool, and the colleague who gets messaged. 4. "When was the last time that happened?" Converts a vague complaint into a frequency you can weigh against other complaints.
That is most of it. The skill is not in the question list, it is in following the story rather than the guide when the two disagree.
Questions that quietly contaminate the answer
Some phrasings put the answer in the participant's mouth. They are easy to write and hard to hear yourself say.
Leading: "How frustrating was the export?" You have told them it was frustrating. Ask what happened when they exported it.
Compound: "Do you use it daily and does it fit your workflow?" They will answer whichever half is easier and you will record it as an answer to both.
Solution-shaped: "Would a bulk edit help?" You have moved them from describing a problem to critiquing your fix, and they will be agreeable about it. Bring the solution out later, if at all.
Ranking on the spot: "What are your top three frustrations?" People produce a list under social pressure and rank it in the order they thought of it. Ask about incidents and count them yourself afterwards.
Frequency by feel: "How often does that happen?" gets you "quite often". "When did it last happen?" gets you a date.
Silence is a technique, not a gap
The most useful thing I do in interviews is stop talking after the answer appears to finish. Three or four seconds. It is uncomfortable and it is where the qualification arrives: the "although", the "to be fair", the part that complicates the tidy answer they just gave.
Filling that silence with the next question is how you get an interview made entirely of first drafts.
Write the guide short enough to abandon
A twelve-question guide guarantees a bad interview, because getting through it becomes the goal. The interviewer starts steering back to question seven while the participant is halfway through the most interesting thing they will say all session.
Four or five questions, on one page, is enough. The guide is there to make sure you leave with the essentials if the conversation goes nowhere, not to be completed. Anything the participant raises that you did not plan for is more valuable than anything you did plan for, because you already knew to ask about the planned parts.
I also write the guide as topics rather than sentences. A written sentence gets read aloud, and read-aloud questions sound like a survey, which puts people into survey mode where answers get shorter and more agreeable.
What to do with what you collect
The output of a good interview is not quotes. It is a sequence of events, with the moments where the person left your product marked on it. Each of those exits is a design question: what were they trying to do, why was the alternative faster, and does the exit happen often enough to matter.
Watch out for the pull toward the vivid story. One articulate participant with a memorable problem will dominate the readout unless you write down incidents and count them. That is a different discipline from sizing the study correctly, and both are needed before anyone should act on a finding.
The point
Interview technique is usually taught as rapport, and rapport matters. But the thing that separates an interview that changes a roadmap from one that produces a nice quote is much simpler than warmth. It is whether the questions can be answered from memory instead of imagination.
Everything a person tells you about the future is a guess wrapped in politeness. Everything they tell you about last Tuesday is evidence, imperfectly recalled. Build the guide out of the second kind and most of the other problems solve themselves.
Frequently asked questions
- What questions should I ask in a user interview?
- Ask about specific past events rather than opinions or predictions. The core question is "walk me through the last time you did X", followed by "what did you do just before that", "what happened next", and "when did that last happen". These produce a recalled sequence of real actions, which is evidence, rather than a hypothetical answer, which is a guess.
- Why should I avoid asking users if they would use a feature?
- Because people predict their own future behaviour badly, and because participants want to be helpful to the person interviewing them. The answer is almost always yes, and it tells you nothing about whether they will adopt the feature. Ask instead what they currently do about that problem, which reveals whether the problem is worth solving at all.
- What is a leading question in user research?
- A leading question contains its own answer, usually as an adjective or an assumption. "How frustrating was the export?" tells the participant that the export was frustrating and invites them to agree. The neutral version asks what happened when they used the export, and lets any frustration appear on its own if it is really there.
- How many people should I interview?
- Four to five per distinct user group is a reasonable starting point for discovery, and you should plan more rounds rather than one large round. If the goal is to measure how common something is rather than to discover that it exists, interviews are the wrong instrument and you need a survey or behavioural data instead.
Sources
This thinking, applied
Share this
