User interviews help a team understand people’s experiences, circumstances and reasoning. They are useful for exploring a problem before choosing a solution, but they do not insure a product against failure or establish what people will buy. Ask about relevant events and decisions rather than simply asking which features users want.
This guide uses a fictional shift-swap service to show how to plan a focused conversation. The question is how staff currently arrange a shift change, where coordination becomes difficult and what they consider confirmed. The examples are interview prompts, not findings from a study.
What Are User Interviews and When to Use Them?
A user interview is a qualitative conversation guided by a research question. It explores a relevant part of a person’s experience, such as arranging a shift, selecting a service or resolving a problem. The researcher listens for context and meaning rather than treating the participant as a source of product specifications.
Interviews can be useful before design, during exploration and after observing a task. They can inform participant profiles and journey maps, but these artifacts should reflect evidence rather than invented identities. Post-task questions can clarify an observed action without replacing the observation. For a recent change of tools, a customer switch interview reconstructs the trigger, alternatives and commitment.
Why do we need a user interview?
Use an interview when you need to understand an experience in context. Other methods may be more suitable for measuring behavior or testing a specific interface. For experiences that unfold over several days, diary entries and follow-up questions preserve details between sessions.
- Explore the sequence of a recent event and the people or systems involved.
- Understand what mattered to the person and how they made a decision.
- Identify expectations or constraints to investigate further without assuming that one account represents everyone.
When will user interviews be conducted?
User interviews can be completed in a variety of situations:
- Before design, explore the current task and its surrounding circumstances.
- Alongside observation, ask about decisions or events that are not visible in the session.
- After a usability task, clarify what the person expected at a specific moment.
User Interviews: Planning and Preparation
Prepare questions before the interview
Prepare a discussion guide with the research goal, broad topics and optional probes. Pilot it to check whether the questions are understandable and relevant, while leaving room to follow an unexpected but useful detail.
The list of user interview questions ensures that you:
- Let the team review whether the questions serve the research goal.
- Cover the important topics without trying to ask every possible question.
- Keep the session focused while allowing the participant’s account to develop.
- Provide a reference when you need to return to the topic.
Write user interview questions that boost conversation
Ask one thing at a time and anchor it in a specific event. For example: “Tell me about the last time you needed to change a shift.” Follow with “What happened next?” and “How did you know the change was confirmed?” These prompts reveal more context than “Would a shift-swap app be useful?”
Prepare Neutral Follow-Up Prompts
Some participants give detailed accounts; others need time or a prompt. Ask “Can you give an example?” or “What do you mean by confirmed?” without supplying the answer. Do not equate the length of an answer with the quality of evidence.
Take user interviews seriously
Recruit people with relevant experience, explain the purpose and arrange a suitable setting. GOV.UK’s interview guidance describes practical preparation and facilitation considerations. A recruitment screener turns that experience into consistent eligibility questions.
Agree how notes or recordings will be used and who can access them. Obtain the appropriate consent, allow questions and make participation voluntary. Avoid requesting identifiable details about coworkers when they are not needed for the research question.
Be Open to Evidence That Challenges the Idea
A participant may describe a working process that does not need your proposed feature, or a problem caused by policy rather than interface design. Record that evidence instead of steering the conversation back to a preferred product.
How to Conduct the User Interview?
1. Set the goals of the interview
Write the research goal at the top of the guide. For the shift-swap example: understand how staff coordinate a change and distinguish a request, a colleague’s agreement and a manager’s confirmation.
Use that goal to select topics: the trigger for the change, people contacted, information exchanged, delays and how the outcome became clear. The guide supports a conversation, not a rigid interrogation.
Compare a broad preference question with an event-based prompt:
Less useful on its own: “Would you like a shift-swap app?”
A positive answer may express politeness or general interest without explaining the current task.
More specific: “Think about your most recent shift change. How did you arrange it?”
Follow-up: “At what point did you consider the change confirmed, and what told you that?”
2. Stay Neutral and Check Assumptions
Avoid leading the participant toward an emotion or explanation. The following hypothetical exchange illustrates a leading question:
Participant: “I had to message two colleagues and then wait for the manager.”
Leading prompt: “That must have been frustrating, right?”
Neutral alternative: “What was that experience like for you?”
Follow the participant’s words. If they describe a delay, ask what happened during it and what consequence it had. Do not assume the delay was a problem, or that a new interface would remove it.
3. Make your user comfortable
Explain the session clearly and give the participant time to respond. A respectful setting can support the conversation, but no facilitation technique guarantees complete or unbiased evidence.
- Start with relevant background questions that are easy to answer.
- Balance attention and notes; a second researcher can help when appropriate.
- Record only when appropriate consent and handling arrangements are in place; recording is not mandatory.
- Allow silence and avoid finishing the participant’s answer for them.
4. Use Follow-Ups to Clarify Meaning
Follow-up questions are useful when a statement is unclear or incomplete. Ask for a concrete example, sequence or meaning without suggesting what the person should have done.
- When the participant gives a short answer, invite an example rather than repeating the question more forcefully.
- When they use a broad term such as “approved,” ask what that meant in the event.
- When the conversation moves away from scope, acknowledge the point and explain the transition back.
5. Keep the Conversation Responsive
Listen for the experience behind the answer. You can follow the guide while adapting the order of questions to the participant’s account.
- Acknowledge that you heard the response without praising an answer that matches your hypothesis.
- Wait for the response before moving to the next topic.
- Explain when you are changing topics and invite anything important that was missed.
Analysis of the User Interview
Separate notes or quotations from interpretations. Compare accounts for patterns and differences, retain contradictions and describe the recruitment context. A small qualitative study can reveal important issues without establishing how common they are in the whole workforce.
Turn the Findings Into a Specific Next Question
Suppose the interviews suggest that “agreed” and “approved” mean different things to staff. Treat that as a design question to investigate, not a result already proven by this article. In Mockitt, prepare fictional Shift requested, Colleague agreed and Manager confirmed states, then conduct a separate task-based review of whether the distinction is understandable.
Keep interview evidence separate from the prototype exercise. The interview explores past experience; the prototype review examines a proposed explanation. Record which source supports each conclusion, and do not report the illustrative shift-swap example as a real participant finding.
