5 research mistakes that waste your interviews
Five interview mistakes that turn user research into polite noise, and what to do instead: who you ask, what you ask, and what you do afterwards.
5 research mistakes that waste your interviews
Most wasted interviews fail for one of five reasons: you spoke to the wrong people, you asked them to predict the future, you led them to the answer, you listened for what you hoped to hear, or you never turned the notes into a decision. Each one is easy to fix before the next interview. Here they are, with what to do instead.
The five mistakes
1. You interviewed whoever was easy to reach.
Colleagues, friends of the project sponsor, the three customers who always reply to emails. They are pleasant, available and unrepresentative. Easy recruits tend to be the people already well served, already engaged or already sympathetic to you. The people whose problem you are trying to solve are often the ones who gave up, complain through other channels, or never knew the service existed.
What to do instead: write a short screener before you book anyone. Name the behaviour you need ("applied for the permit in the last three months", "cancelled within the first year"), not a demographic. Recruit at least a couple of people at each extreme: heavy users and people who dropped out. If someone on the team says "we already know what customers think", that is exactly the moment to recruit outside the usual list.
2. You asked people to predict what they would do.
"Would you use an app that…?" "How much would you pay for…?" "Would this be useful?" People answer these questions generously and wrongly. They are not lying; they are guessing about a future self who is more organised, more patient and richer than they are. Rob Fitzpatrick's book The Mom Test is built on this point: opinions and hypotheticals about the future are weak evidence, while specifics about the past are strong.
What to do instead: ask about the last real time. "Tell me about the last time you renewed this licence. Where were you? What did you do first?" Then follow the story. Ask what they did about the problem, what it cost them and what they tried before. If they have never tried to solve it, that tells you something important about how much it matters.
3. Your questions carried the answer inside them.
"Don't you find the form confusing?" "How frustrating was the waiting time?" "What did you like about the new portal?" Each question tells the person what you expect, and most people are polite enough to agree. The interviewer's tone, nodding and visible relief do the same work without any words.
What to do instead: use open, neutral prompts. "Walk me through it." "What happened next?" "How did that go?" Then wait. Silence of five or six seconds feels long to you and normal to them, and it is often when the useful detail arrives. Write your discussion guide in advance and have a colleague read it out loud to you, marking any question that hints at a right answer. In the interview, react to everything with the same calm interest, including things you do not want to hear.
4. You heard what you came to hear.
This is the quiet one. The team arrives with a solution in mind, and every interview becomes a hunt for support. Comments that fit are written down in full; comments that don't are summarised as "some concerns". By the debrief, ten conversations have become one comfortable story.
What to do instead: before the first interview, write down your riskiest assumptions and what you would expect to hear if each one were wrong. An assumption map is the right tool for this. Take notes in the person's own words, not your interpretation. Put two people in each interview, one asking and one writing, and have the note-taker capture surprises separately. In the debrief, start with "What did we hear that we didn't expect?" before anyone is allowed to say what confirms the plan.
5. The notes went into a folder and stayed there.
Interviews are expensive in time and goodwill. The most common waste is not a bad question; it is good material that nobody synthesises. A shared drive fills with recordings, a slide deck says "users want simplicity", and the project carries on as planned.
What to do instead: book the synthesis session before you book the interviews, ideally within a day or two of the last one, while memory is fresh. Pull individual observations onto separate notes, cluster them with affinity grouping, and name each cluster as a finding a stranger could act on. Then decide, in the room, what changes: which assumption is now weaker, which question is reframed, what you will test next. If nothing changes, either the research confirmed the plan (say so and record why) or it was not designed to challenge it.
Do's and don'ts
| Do | Don't |
|---|---|
| Recruit by behaviour, including people who dropped out | Recruit by convenience or seniority |
| Ask about the last specific time something happened | Ask whether people would use, like or pay for something |
| Use neutral prompts and leave silence | Fill every pause or explain your idea |
| Write down exact words and surprises | Write your interpretation in the moment |
| Interview in pairs: one asks, one notes | Run interviews alone and rely on memory |
| Book synthesis before the first interview | Leave synthesis "for when there's time" |
| Watch people do the task where you can | Rely only on what people say they do |
The last row matters. What people say and what they do often differ. Where you can, pair interviews with contextual observation: sit with someone while they actually fill in the form or serve the customer.
Illustrative example
Illustrative. A city transport authority in a mid-sized European city wanted to know why its monthly travel pass was under-used. The first round of interviews was with eight people recruited through the authority's own newsletter. All eight were regular pass holders. Asked "Would you buy the pass if it were cheaper?", most said yes. The team prepared a discount proposal.
A second round fixed the recruiting. The screener asked for people who had bought a pass in the past year and not renewed it. Interviewers asked, "Tell me about the month you stopped buying it." The stories were not about price. People had changed jobs, started working from home two days a week, or found the pass did not cover the night bus they relied on. One person described buying single tickets for a month to "see whether it was worth it" and never going back.
The team clustered the notes and found two findings that the discount would not touch: the pass did not fit part-week commuting, and its coverage map was unclear. The next step became a test of a part-week pass with a small group, not a city-wide price cut.
Questions people ask
How many user interviews are enough? There is no single number. Stop when new interviews mostly repeat what you have already heard for the group you are studying. For a focused question with one clearly defined group, that point often comes sooner than teams expect; if you study several different groups, you need enough people in each. Plan a first round, synthesise, then decide whether to do more.
Should I show people my idea during the interview? Not at the start. Learn about their current behaviour first, with no idea on the table. If you need reactions to a concept, show it at the end, or better, in a separate session with a rough prototype where you watch what they do rather than ask what they think.
What is the difference between an interview and a survey? An interview helps you discover what matters and why, through stories you did not anticipate. A survey measures how common something is once you know what to ask. Running a survey before interviews usually means counting answers to the wrong questions.
Where to go next
The stakeholder interviews guide gives you a structure for the conversation itself, and the empathy map helps turn each interview into something the team can see at once. For the bigger picture of which tool to use at each stage, read which innovation tool should I use. Once your findings are in, write a problem statement the whole team can work from, or test an idea before you build it.