User Interview
A structured conversation with someone who uses or might use a product, aimed at understanding their situation rather than collecting opinions.
A user interview is for learning what someone actually did and why, not what they think they would do. The distinction decides everything about the questions. “Would you use a feature that did X?” produces a polite yes and no information. “Walk me through the last time you had to do X” produces a story with real constraints, workarounds and costs in it.
Interviews are cheap to run and easy to ruin. Leading questions get agreement, not evidence. Asking about frequency in the abstract gets a flattering estimate. Demoing the design first anchors everything that follows. The discipline is to ask about the past, stay quiet longer than feels comfortable, and follow specifics rather than generalisations — when someone says “it's slow”, the useful move is “tell me about the last time”.
Interviews are not usability tests
An interview asks about a person's world. Usability testing watches them attempt a task in your product. Interviews tell you what to build; usability tests tell you whether what you built works. Running one and calling it the other is the most common research mistake in product teams.
In practice
A B2B invoicing tool interviewed twelve customers about a requested “bulk edit” feature. Nine of them, asked to walk through their last week, described exporting to a spreadsheet, editing there, and re-importing — because they needed a colleague to approve changes first. The request was for bulk edit; the problem was approval. Shipping bulk edit would have changed nothing.
Where teams get it wrong
- Asking what people would do instead of what they did.
- Showing the design before asking about the problem, which anchors every answer.
- Interviewing whoever is easiest to reach rather than whoever has the problem.
- Taking the first answer. The useful detail is usually two follow-ups down.
- Treating an interview as validation, where the only possible outcome is agreement.
( Learn more )
Related terms
All terms- User ResearchThe systematic study of users' goals, behaviour and context — through interviews, observation and analysis — to inform what gets designed and built.
- Usability TestingWatching real users attempt real tasks in a product or prototype to find where they struggle, without steering them.
- Contextual InquiryWatching someone work in their own environment, with their own data and interruptions, and asking about it as they go.
- Jobs to Be DoneA framework describing what people are trying to accomplish and the circumstances driving them, rather than who they are.