A user interview is a structured conversation with a current, prospective, or former customer, conducted to understand their goals, context, decisions, and experiences. It is the most widely used qualitative research method in product and experience work, and also the most frequently done badly, because a conversation feels easy in a way that produces confident conclusions from unreliable material.
The central methodological problem is that people are poor witnesses to their own behavior and motivations. They rationalize past decisions into coherent narratives, they predict their future behavior inaccurately, they answer hypothetical questions with what they imagine they would do, and they adjust their answers toward what they believe the interviewer wants to hear. An interview that asks whether someone would use a proposed feature, or what they would pay, collects opinions with almost no predictive value, and those opinions are frequently used to justify decisions that later fail.
Good interviewing works around this by asking about the past rather than the future, and about specifics rather than generalities. Asking someone to describe the last time they faced the problem, step by step, what they did, what they tried first, what made them stop, produces evidence. Asking whether they like an idea produces politeness. The most useful questions are open, non-leading, and grounded in a concrete episode, followed by silence, which is the single most effective interviewing technique and the hardest to practice, since inexperienced interviewers fill pauses and lose the elaboration that would have followed.
Recruitment determines the value of the exercise more than the questions do. Interviewing whoever is available, existing enthusiastic customers, or internal proxies produces a systematically distorted picture. The most informative participants are usually the ones who are hardest to recruit: people who evaluated the product and chose a competitor, people who churned, people who started a process and abandoned it. Screening on recent, verifiable behavior rather than on self-described attitudes is what separates a useful sample from a convenient one.
Analysis deserves more time than teams usually allocate. Notes read back weeks later reflect what the interviewer already believed, and the reliable process involves recording, transcribing, extracting observations systematically, and looking for patterns across participants rather than for quotes that support existing positions. Small samples are appropriate for identifying patterns and generating hypotheses, but they cannot establish prevalence, and interview findings presented as proportions of the customer base overstate what the method supports.
Recruitment logistics determine whether interviewing happens at all, and treating them as an ongoing capability rather than a per-project effort is what separates teams that talk to customers regularly from teams that intend to. A standing recruitment mechanism, whether an in-product prompt inviting participation, a maintained panel of willing customers, or an agreed process with the sales and support functions for reaching specific segments, removes the two-week delay that otherwise precedes every study. Incentives, consent handling, and scheduling can be standardized once rather than negotiated each time, which is what makes a weekly cadence realistic rather than aspirational.
Interviews are strongest when paired with methods that observe behavior rather than report it. Combining them with analytics, which shows what happens but not why, and with usability observation, which shows what people do rather than what they say they do, produces a picture that neither provides alone. Within a user research programme this combination is the normal working pattern, and the resulting insight feeds both the hypothesis backlog of a CRO service engagement and the prioritization decisions made in product research.