.jpg)
The most direct way to correct these assumptions is to ask users themselves. But asking is not as simple as it sounds. Ask the wrong questions, and you will get confident, polite, and entirely misleading answers. Ask the right questions, and you will uncover needs that users themselves could not have articulated, because those needs live below the surface of awareness.
User interviews are the foundation of the design process — the discipline that separates products built on evidence from products built on guesswork. This article explores how to conduct interviews that reveal real needs: how to prepare, how to ask, how to listen, and how to turn a conversation into design direction.
There is a persistent debate in user research between watching what people do and asking what they think. Observational methods — usability testing, analytics, session recordings — reveal actual behavior. Interviews reveal the reasoning, motivation, and context behind that behavior. Both are essential, and they answer different questions.
Observation answers "what do users do?" Interviews answer "why do they do it?" A user abandons a checkout flow at the payment step. Watching tells you that they left. An interview tells you why — perhaps they expected to see shipping costs earlier, or they were worried about the security of the payment page, or they were actually planning to compare prices elsewhere and the checkout was a dead end for their research.
Interviews also reveal needs that may never manifest as observable behavior because they are unserved. If users do not currently have a good way to track their monthly subscriptions, there is no behavior to observe — they simply live with the problem. An interview surfaces the pain point that no analytics will ever show, because it exists in the gap between what products offer and what people actually need.
Finally, interviews build empathy. There is a world of difference between reading a research report and hearing a user describe the anxiety they feel when a product fails them. Interviews give designers a visceral understanding of the people they design for — an understanding that informs every subsequent decision, from visual style to feature prioritization.
Before exploring how to do interviews well, it is worth confronting why so many interviews fail. The mistakes are common, predictable, and entirely avoidable.
Mistake one: asking leading questions. "Would you find a feature that automatically categorizes your expenses useful?" This question is nearly worthless. It tells the participant what answer you expect, and people are social animals — they want to agree, to be helpful, to give the answer that makes the interviewer happy. Most participants will say yes, not because they would use the feature, but because saying no feels like being unhelpful. Leading questions produce polite confirmations, not honest insight.
Mistake two: asking hypothetical questions. "If we built X, would you use it?" People are terrible at predicting their own future behavior. They imagine a hypothetical version of themselves who is more diligent, more motivated, and more willing to adopt new tools than the person who actually lives their life. The answer to hypothetical questions tells you about people's aspirations, not their behavior.
Mistake three: asking yes-or-no questions. "Do you track your expenses?" A yes or no tells you almost nothing. "How do you currently keep track of what you spend?" tells you everything — the tools they use, the gaps they live with, the workarounds they have invented, and the moments where their system breaks down.
Mistake four: doing all the talking. An interview that is 70% interviewer and 30% participant is a lecture, not a research session. The participant is the expert on their own life; your job is to get out of the way and let them teach you.
Mistake five: interviewing the wrong people. Talking to your existing users is valuable, but it is a sample of people who already chose your product. If you are trying to understand why others do not choose it, or what a new market needs, you need to talk to non-users too. The people who do not use your product hold exactly the information you are missing.
Good interviews are the product of good preparation. The work that happens before the participant arrives determines whether the conversation produces insight or platitudes.
Before writing a single question, be clear about what you are trying to learn. A research question is a broad statement of intent: "How do people decide which bank to switch to?" or "What does a typical day look like for a freelance designer managing multiple clients?"
The research question guides everything downstream. It determines who you recruit, what you ask, and what you look for in the answers. It also keeps the interview from wandering. When the conversation drifts — as it inevitably will — the research question is your compass for gently steering it back.
A discussion guide is a loose outline of topics and questions for the interview. It is not a script to be read verbatim — that would make the conversation feel robotic and prevent you from following interesting threads. It is a safety net that ensures you cover the key topics without forgetting anything important.
A good discussion guide moves from broad to specific. Start with warm-up questions about the participant's background and context. Move to their current behavior and experiences. Then dig into specific pain points and needs. Save any product-specific questions for the end — by that point, you will have learned enough from their own experience that you may not even need them.
Structure the guide around topics, not rigid questions. For each topic, have two or three fallback questions in case the participant does not open up naturally. The guide should support the conversation, not control it.
The most important skill in interviewing is asking open-ended questions — questions that cannot be answered with a single word. Open-ended questions invite stories, details, and context. They put the participant in control of the narrative and reveal what they consider important.
Open-ended questions often begin with how, what, and why:
Follow-up questions — "Can you tell me more about that?" "What did that feel like?" "What happened next?" — are the tools that transform a surface answer into a rich, detailed account. The most powerful interviewing technique is simply asking for more detail, then more again, until you have reached the bottom of the story.
The core challenge of user interviews is that people do not naturally articulate their needs. They describe their problems, their frustrations, their workarounds, and their behaviors — and the needs are hidden within those descriptions. Your job is to dig them out.
The most reliable predictor of future behavior is past behavior. Instead of asking what users would like or what they would do, ask what they have actually done. A question like "Tell me about the last time you had to reorganize your spending" elicits a concrete, factual account. It reveals real processes, real frustrations, and real needs — the soil in which design opportunities grow.
Past-focused questions also avoid the hypothetical-prediction problem. The participant is not asked to imagine; they are asked to remember. And while memory is imperfect, it is far more reliable than imagination as a source of insight about needs.
When you ask "do you think this is a good feature?" you get an opinion. When you ask "how would this change how you work?" you get an assessment grounded in the participant's actual context. Anchoring questions in the participant's behavior and workflow produces answers that are specific, relevant, and actionable.
A powerful version of this is the critical incident question: "Tell me about the last time things went wrong." Asking about a specific recent failure reveals the participant's real priorities, their tolerance for friction, and the exact moments where a product could add value. People are rarely short on stories about things going wrong.
When a participant mentions a problem, the instinct is to move on to the next topic. But the first answer is rarely the real answer. The Five Whys technique — asking "why" repeatedly to drill down to the root cause — is a simple way to reach the underlying need.
Participant: "I keep losing track of my expenses."Interviewer: "Why do you think that is?"Participant: "I use a different app for everything — coffee here, groceries there, subscriptions somewhere else."Interviewer: "Why don't you use one app for everything?"Participant: "I tried, but none of them feel natural to use."Interviewer: "What would make one feel natural?"Participant: "I don't know... maybe if it understood that I pay for things in different ways — my card, my phone, sometimes cash."
The need emerges: not just "track expenses," but "one place that accepts the messy reality of how I actually pay." The fifth why uncovered something the participant could not have stated as a feature request.
The most important information in an interview is often what the participant does not say. Hesitations, long pauses, careful wording, and deflections all signal areas of discomfort or importance. When a participant trails off mid-sentence, that is not the time to fill the silence — it is the time to stay quiet and let them continue. The most revealing thoughts often surface in the space after a pause.
Needs are emotional before they are functional. When a participant describes something with frustration, anxiety, excitement, or relief, you are at the heart of a real need. A user who describes their expense tracking as "a constant source of stress" has a deeper need than a user who says it is "a bit inconvenient." The emotional weight of a problem is a reliable signal of how much a solution would be valued.
A discussion guide gets you started, but the real value of an interview comes from following the threads the participant offers. The most interesting insights are rarely on the guide; they emerge from unexpected places. This requires a balance — enough structure to stay on topic, enough flexibility to explore what matters.
The key is to distinguish between topics and threads. Topics are the areas you planned to cover. Threads are the specific, unexpected directions the participant takes you. When a participant mentions something surprising or tangential, make a judgment call: is this thread worth following, or should you return to the planned topic? Often, the tangential thread contains more insight than the planned topic ever would.
The "wow" moments — when a participant reveals something that challenges your assumptions — deserve special attention. When you hear something surprising, do not rush past it. Slow down. Ask for more detail. Explore the implications. These moments are where the design process pivots from confirming assumptions to discovering truth.
A pile of interview recordings is not research. Research is what you learn from them, and learning requires synthesis. The work of turning conversations into design direction happens after the interviews are over.
First, debrief while it is fresh. Immediately after each interview, capture the key insights — what surprised you, what the participant emphasized, what contradicted your assumptions. Do not rely on memory; record your impressions while the conversation is still vivid.
Second, look for patterns across interviews. A single participant's frustration is a data point. The same frustration appearing across multiple participants is a pattern — and patterns are what justify design decisions. Group the insights by theme: recurring problems, shared workarounds, common emotional responses, repeated workarounds. The patterns that appear across participants are the ones that represent genuine needs rather than individual quirks.
Third, distinguish observations from interpretations. An observation is a fact from the interview: "She spends 20 minutes each week manually categorizing expenses." An interpretation is your inference about what it means: "Manual categorization is a pain point worth solving." Both are valuable, but they should be labeled differently. Observations are evidence; interpretations are hypotheses that need further validation.
Fourth, create insight statements. Convert the patterns into clear, actionable insight statements that a design team can use. A good insight statement is specific and design-relevant: "Users want to understand their spending at a glance, but current tools require too much manual effort to maintain, so they abandon tracking after a few weeks." This statement points toward a design direction — make tracking effortless, make the value visible immediately — without prescribing a specific solution.
Fifth, let insights inform, not dictate. Interviews reveal needs and opportunities; they do not design products. The insight "users want effortless tracking" does not tell you whether to build automatic categorization, simpler manual entry, or better default views. That is where design judgment takes over. Research informs the problem space; design creates the solution. The best outcomes come from a team that does both well.
User interviews should not be a one-time activity performed at the start of a project and never repeated. They are most valuable as an ongoing practice — a habit of talking to users at every stage of the design process.
During discovery, interviews define the problem space. They reveal who the users are, what they need, and where the opportunities lie. This is where the biggest design decisions are made, and where interviews have the most leverage.
During development, interviews validate direction. Talking to users about a prototype or a new feature reveals whether you are solving the right problem in the right way. Even a few interviews with a prototype can catch fundamental misalignments before development costs escalate.
After launch, interviews explain the numbers. When analytics show a feature being ignored or a flow being abandoned, interviews reveal why. They turn the "what" of analytics into the "why" of understanding.
The cadence can be light — even one interview a week with an existing or potential user will, over a year, produce fifty conversations' worth of insight. That is more research than most design teams ever do, and it will transform the quality of the decisions they make.
User interviews are the closest thing the design process has to a ground truth. They reveal the needs that analytics cannot show, the motivations that behavior cannot express, and the context that assumptions cannot capture. They are the antidote to the curse of knowledge — the practice of learning, directly and honestly, what the people you design for actually need.
Interviews are not difficult, but they require discipline. The discipline to ask open questions instead of leading ones. To ask about the past instead of the future. To listen more than you speak. To follow the unexpected thread instead of the prepared script. To pay attention to emotion as well as facts. And to treat every answer as a door to a deeper question rather than a box to be checked.
The designers who build products people love are not the ones with the best taste or the most advanced tools. They are the ones who genuinely understand the people they design for — who have sat across from real users, heard their frustrations, and translated those frustrations into products that make their lives better. Every interview is a step toward that understanding. And every step toward understanding is a step toward building something that matters.
