Plan a customer interview that produces useful evidence

Name the decision before writing questions

A customer interview can be friendly and still leave a team unsure what it learned. That often happens when the questions were assembled before the purpose was clear. Start by writing the decision the team is facing. Perhaps it needs to decide which part of onboarding to investigate, whether a recurring request points to a new use case or why a particular group stopped using the product. The interview should help reduce uncertainty around that decision.

Write one research question below it. “What happened during the first attempt to invite a colleague?” gives a conversation more direction than “What do people think of the product?” Then list what is already known and what is only assumed. This can expose a question that an interview cannot answer. If the team needs to estimate how many customers experience a problem, a handful of conversations will not provide that estimate.

Choose participants for their experience

A participant should have encountered the situation you want to understand. For a study of abandoned trials, recruit people who began a trial and stopped recently enough to recall it. Someone who has used the product happily for years may have a useful perspective, but they cannot supply the same account. Keep the screen tied to observable experience rather than an opinion about the proposed solution.

A recruitment screen could ask when the person signed up, what they hoped to do and whether they completed the relevant task. Keep it short and avoid revealing the hypothesis you want to test. Asking “Were you frustrated by the confusing invitation screen?” selects for agreement and introduces the team's interpretation before the interview even begins. Ask what the person did instead.

Explain the commitment in the invitation

Tell the person who is contacting them, what the conversation concerns and how much time it will take. Describe any incentive and recording request plainly. Include a way to decline. A participant should not have to accept a calendar invitation before discovering that the session includes observers or a request to share their screen.

Confirm the practical details shortly before the session. Check the meeting link and provide an alternative contact route appropriate to the study. If the participant cannot attend, make rescheduling easy where possible. Recruitment is part of the research experience. Confusing instructions can create unnecessary stress and may exclude people whose schedules are already difficult to coordinate.

Build a guide around a recent episode

Organise the interview in a sequence: the situation before the task, the trigger, the actions, the result and what happened afterward. For an invitation workflow, you might ask what prompted the person to invite a colleague, where they started and what they expected the colleague to receive. Follow the account in the order the participant gives it before moving to a prepared question.

A useful opening is “Tell me about the last time you tried this.” Ask for a specific occasion rather than a general opinion. If the person says the process was easy, invite them to describe the steps. If they say it was confusing, ask where that feeling began. The example gives the team something it can examine; the adjective alone leaves too much open to interpretation.

Keep the proposed solution out of the question

A question such as “Would a clearer dashboard help?” asks the participant to react to the team's idea. It may be appropriate later in a separate concept study, but it is a weak way to understand what happened in an exploratory interview. The person may agree because the suggestion sounds reasonable or because they want to be helpful.

Replace solution questions with experience questions. Ask what they looked for, what they tried next and how they knew whether the action had worked. If they mention another tool, ask what that tool helped them do. These questions can reveal the job the person was trying to complete without asking them to design the product during the interview.

Use follow-ups that open the account

Short follow-ups can keep the conversation moving without imposing an explanation. “What happened next?” invites sequence. “What made you choose that?” invites a reason. “Can you give me an example?” asks for detail. Do not use the same phrase mechanically after every answer. Listen for a point that matters to the research question and follow it.

Silence can be useful too. Give the participant a moment to remember before filling the gap with a suggestion. If they cannot recall, acknowledge that and move on. Do not treat uncertain memory as a precise record. Your notes should distinguish what the person clearly remembers from an estimate or a general impression.

Handle demonstrations with care

If the person is willing to show a workflow, explain what you want to observe and remind them to close unrelated private material. A screen share can clarify an account, but it can also reveal information the study does not need. Avoid collecting sensitive content merely because it appeared during the demonstration. The recording and storage arrangements should be appropriate to the agreed purpose.

Watch before instructing. If you tell the person where to click, you may remove the very confusion the study is meant to understand. Ask them to explain what they are looking for. When the session is an interview rather than a usability test, be clear about that distinction and avoid treating a short demonstration as a full test of the interface.

Take notes that preserve the evidence

Separate an observation from your interpretation. “The participant returned to the account page twice” is an observation. “They did not trust the invitation status” is an interpretation unless they said so or other evidence supports it. Both may be useful, but keeping them separate helps a reviewer understand the reasoning and challenge it where necessary.

After the session, write a brief summary while the sequence is still fresh. Include the participant's relevant context, the main episode, important examples and open questions. Do not tidy every account into the same story. A participant whose experience differs from the others can reveal a condition the team has overlooked.

Synthesize for the decision

Compare accounts against the research question. Look for recurring experiences, contrasting cases and evidence that challenges the starting assumption. Grouping notes by topic can help, but a topic label is not yet a finding. Explain what happened, to whom and under what circumstances. Attach enough context that the team can see how you reached the conclusion.

A decision brief might have four parts: the question, the people interviewed, the observations and the next investigation or change to consider. State the limits of the study. A small sample can suggest an issue worth testing without proving its frequency. Avoid turning the number of interviews into a claim about the whole customer base.

Rehearse the guide once

The GOV.UK guide to in-depth interviews also recommends a prepared discussion guide, a practice run with a colleague and questions that avoid leading the participant. These are useful checks on a first guide before recruitment begins.

Before the first real session, ask a colleague to walk through the guide as a practice participant. Notice which questions need explanation, where you accidentally suggest an answer and whether the sequence fits the available time. The rehearsal will not validate the research method, but it can expose practical problems before a customer's time is involved.

Then revise only what the rehearsal revealed. Keep a small set of essential questions and a separate list of optional follow-ups. In the interview, let the participant's account determine which follow-up matters. A prepared guide gives the conversation a purpose. Careful listening supplies the detail that makes the eventual brief useful.