Run a user interview

Outcome

Notes from one interview about a real, recent episode, written up within an hour of the call, with the participant's words kept verbatim and the workarounds marked. Across a study, eight such write-ups and a decision rule set before the first call.

When to use it

• You need to understand how people do a task today, in what order, with whom and with what workarounds.
• You need the words people use for their problem, to name features or write copy.
• A roadmap decision depends on why people behave a certain way, and nobody on the team has asked them.

When not to use it

• You want to know whether people can use a design. Watch them try: write a usability test script.
• You want to know how many people have a problem. Eight interviews show that a problem exists, not how common it is; follow up with a survey.
• You want people to tell you whether they would buy or use something. Stated intentions about the future are the weakest evidence an interview produces.

Before you start

• The decision. One sentence: we need to decide X, and today we are guessing about Y.
• Participants. Eight people who did the task recently, recruited on behaviour, including people who stopped or chose something else.
• Consent and recording. A consent form or a spoken consent line, and permission to record.
• A note-taker. A second person to take notes, so the interviewer can listen.
• The synthesis tool. Somewhere to paste notes one observation per line, such as Research Synthesis.

Steps

Step 1: Write the decision and a decision rule

Write the decision the interviews inform, then a rule fixed in advance, such as if five of eight describe a weekly manual workaround, we build the import. A rule written before the calls stops the loudest participant from deciding the result.

You should now have: a written decision and a decision rule, agreed before the first call.

Step 2: Write a short guide in three parts

Write a warm-up about the participant's role and week, one core question — tell me about the last time you did X — and four or five follow-ups about where it went wrong: what they tried first, who they asked, what they did instead. Ten to twelve questions in total; most will not be asked.

You should now have: a one-page guide: warm-up, the last-time question and follow-ups about the problems.

Step 3: Open the call and get consent

Introduce yourself and the note-taker, say how long the call takes, that there are no right answers and that you are learning about their work, not testing them. Get consent to record before you start.

You should now have: a recorded call with consent given and the participant knowing what to expect.

Step 4: Ask about the last time, in order

Ask the participant to walk through the last time they did the task, from the moment they knew they needed to. When they slip into what they usually do, bring them back: and last time, what did you actually do? Ask what happened next? until the episode ends.

You should now have: one real episode, walked through in order, in the participant's words.

Step 5: Follow the problems and stay quiet

Probe every point where something went wrong, slowed down or needed someone else. Ask open questions, repeat their words back, and leave silences unfilled. Do not explain your product, suggest answers or ask whether a feature would help.

You should now have: the workarounds and problems in the episode, each with what the participant did about it.

Step 6: Close with one open question

With two minutes left, ask is there anything I should have asked you about? Thank them, confirm the incentive and stop the recording.

You should now have: a closed call, with anything the guide missed captured.

Step 7: Debrief within the hour

With the note-taker, write the episode as one observation per line, keeping quotes verbatim and marking each workaround. Note anything that surprised you and any change to the guide for the next call.

You should now have: a written-up interview, one observation per line, with quotes and workarounds marked, ready to synthesise.

Worked example

A team building scheduling software wants to know whether to build a calendar import for clinics.

1. Decision rule: if five of eight clinic managers re-type appointments from another system every week, we build the import.
2. The core question is tell me about the last time you set up next week's appointments.
3. The participant, a clinic manager, agrees to recording.
4. She starts with "usually I just copy them over". Asked about last Monday, she describes printing the old system's list, typing 64 appointments by hand and checking them against the printout.
5. Asked what happened when an appointment was wrong, she describes a patient arriving for a slot that had moved, and a sticky note she now keeps on her monitor. The interviewer does not mention the import.
6. Asked what they should have asked, she says the real problem is the dentist's cancellations, which arrive by text.
7. The debrief produces 31 observations, two workarounds (the printout and the sticky note) and a new follow-up about cancellations for the remaining calls. After eight interviews, six managers describe re-typing weekly, and the team builds the import.

Checklist

• The decision and a decision rule were written before the first call.
• Participants were recruited on recent behaviour, including people who stopped.
• Consent to record was given before the interview began.
• The core question asked about the last time, not what usually happens.
• The interviewer did not pitch, suggest answers or ask about future use.
• Every problem in the episode was followed up.
• The interview was written up within an hour, one observation per line.
• Quotes are verbatim and workarounds are marked.

Common mistakes

• Asking about the future. "Would you use this?" gets a polite yes. Ask what they did last time.
• Accepting the general answer. "Usually I…" describes how people like to see themselves. The specific episode is often different, and the difference is the finding.
• Pitching in the call. Once you explain the product, the participant starts reviewing it.
• Interviewing only happy customers. People who left or never adopted know where the product fails.
• Waiting to write up. After a day, notes become a summary of what you expected to hear.

Related

• Research Synthesis: paste the write-ups, one observation per line, and cluster them into themes.
• Create a user persona: turn eight interviews into personas built on behaviour.
• Create an empathy map: one participant's moment in detail.
• Write a usability test script: when the question is whether people can use a design.
• UX research basics course: research methods in lessons with knowledge checks.
• User Interviews Without Getting the Answer You Wanted: why interviews fail quietly, and how to keep them honest.