What Is a User Interview?

A structured conversation designed to surface what you do not already know

A user interview is a one-to-one conversation between a researcher and a participant, designed to understand how the participant thinks about a topic, what they do in a given situation, how they experience a product or service, or what drives their decisions. The researcher comes with a discussion guide: a set of topics and prompts rather than a fixed script, which keeps the conversation focused while leaving room to follow what is most interesting.

Unlike a survey, which asks everyone the same questions in the same order and collects answers in the same format, an interview is responsive. If a participant says something unexpected, the researcher can ask about it. If one answer opens a more interesting line of enquiry, the guide can flex. The value is in what emerges, not just in what was anticipated, which is why interviews are used most often at the beginning of a project, when the goal is to understand the shape of a problem rather than to measure something already defined.

How this differs from a survey

A well-designed survey is efficient at collecting the same information from a large number of people: it scales in a way that interviews do not. But a survey is only as good as the questions you write before you know what people are going to say. If you have not anticipated a response, the survey does not capture it. If a question is ambiguous, every participant is left to interpret it however they choose, and there is no way to know what they understood by it.

Interviews work differently. The researcher can notice if a question causes confusion and rephrase it, follow up when an answer is surprising, and explore reasoning that would be invisible in a multiple-choice response. The relationship between the two approaches (when to go deep with a small number of participants and when to measure something across a large group) is covered in more detail in our guide to qualitative vs quantitative research.

How this differs from a focus group

Focus groups, in which a moderator leads several participants in a group discussion, are sometimes used as a cheaper substitute for individual interviews. They can work well for certain things (exploring the language people naturally use around a topic, or stimulus-response exercises where group energy is useful) but they have a significant limitation for most research purposes: social dynamics shape what people say.

Participants in a group tend to anchor to the most confident voice, moderate their views towards what seems socially acceptable, and become reluctant to describe experiences that might mark them out as unusual. A person who would readily describe, in a private interview, the workaround they rely on because the system is unreliable may stay quiet in a group where admitting to the workaround also means admitting they struggled. One-to-one interviews give you what people actually think, rather than what they are comfortable saying in company.

The difference between a good user interview and a bad one

The most common mistake in user interviews is asking leading questions without realising it. "Did you find that frustrating?" is a leading question. "How did you feel about that?" is not. "Do you use the search function?" is a closed question that invites a yes or a no. "Walk me through how you find things when you are looking for something specific" invites a description. The distinction sounds straightforward and is consistently hard to maintain in practice, because the natural impulse in conversation is to signal what you expect or hope to hear.

The second most common mistake is rushing past silence. When a participant pauses after answering a question, the instinct is to move on. Often, what they say after a pause is more considered and more revealing than what they said immediately: the first answer is what comes to mind, the second is what they actually think. Learning to wait, to treat a pause as part of the answer rather than a gap to fill, is one of the most useful things an interviewer can develop.

A good discussion guide also separates what the researcher wants to know from what questions will surface it. Directly asking "what do you find difficult about this?" often produces very different answers to asking someone to walk you through the last time they used a system and noting what friction emerges naturally. People are better at narrating experience than at evaluating it in the abstract.

What a user interview session actually looks like

A typical session lasts between 45 minutes and an hour. It begins with an introduction that establishes what the session is for, confirms consent for recording or note-taking, and reassures the participant that there are no wrong answers: the researcher is there to understand their experience, not to test them. This framing matters: participants who think they are being evaluated give different answers from participants who feel like genuine experts in their own lives.

The session then follows the discussion guide loosely, moving between topic areas while pursuing threads that feel productive. A skilled interviewer tracks several things at once: where in the guide they are, what the participant has said so far, what feels under-explored, and whether the conversation needs more time or more pace. The session ends with an open invitation: "Is there anything you expected me to ask, or anything you would like to add?"

Analysis typically works across a set of sessions (usually six to twelve for a focused study) to identify patterns, recurring themes, and notable individual experiences. The output might be a written report, an affinity map, or a set of insights fed directly into design or strategy decisions. Like most qualitative research, the value is not in the individual responses but in what holds across them.

When to use interviews and when to use something else

Interviews work well for questions about attitudes, motivations, experiences, and decisions: the "why" behind behaviour, as people themselves understand it. They are less suited to capturing what people actually do in practice, where unconscious habits and real-world context matter more than recalled experience. For that, contextual inquiry or direct observation will get closer to the truth, because you are watching behaviour happen rather than asking someone to reconstruct it from memory.

If the goal is to validate a specific design or screen, a usability testing session gives you behavioural evidence that an interview cannot: watching someone fail to complete a task tells you more than asking them how they would approach it. If the question is about a broad population at scale, survey research will be more efficient. But if you are at the beginning of a project and need to understand who you are designing for and what actually matters to them, an interview study is usually where that understanding begins. Our in-depth user research page covers how interviews sit alongside other qualitative methods for discovery and exploration work.

If you are unsure which method fits your question, tell us what you are trying to learn. We will help you figure out whether interviews are the right starting point, or whether a different approach would serve you better.