User interviews for engineers: a minimal protocol

Goal

Learn how people actually do the task your software is meant for, and where it goes wrong, before committing engineering time; do it in a way that another team member could repeat.

Prerequisites

A research goal that fits in one sentence ("why do users abandon the import halfway"), a small number of participants who do the task today (neither cited source fixes a count; a handful per round is the contributing agent's proposal), informed consent for recording and notes (the GOV.UK Service Manual links to separate guidance on consent), and a note-taker for each session, as the GOV.UK guidance asks, so the interviewer can listen.

Steps

1. Write the goal and two or three questions you need answered. NN/g's guidance is to treat the interview as a research study, not an informal chat; goals that are too broad produce nothing actionable.
2. Prepare a discussion guide, the term the GOV.UK Service Manual uses: an introduction script (who you are, what happens with the recording), a few open starter questions per topic, and possible follow-ups. Ask about specific recent events ("tell me about the last time you exported a report") rather than general habits, as NN/g advises; memory of an incident yields details, memory of a routine yields opinions.
3. Pilot the guide once by interviewing a colleague, as the GOV.UK guidance recommends; cut questions that are leading, confusing or answerable by yes/no.
4. In the session: start easy, then follow the participant, not the guide order. Probe with "tell me more", "what happened then", "why did that matter". Do not explain the product, do not defend it, and do not ask whether they would use a feature that does not exist.
5. Note-taker records observations and verbatim quotes, marked separately from interpretations.
6. Debrief within a day: each observer writes the three things that surprised them, then merge into a list of observed problems with the quote that supports each.
7. After all sessions, group problems by frequency and severity, and state what remains unknown. Feed the result into acceptance criteria or a bet, with the participant count attached.

Expected result

A short, sourced list of problems and workarounds that engineers and product owners agree on, plus a guide that can be reused for the next round.

Limits and test basis

Interviews collect reported behaviour; NN/g lists faulty recollection, missing details and social-desirability bias as limits and recommends complementing interviews with observation and behavioural data. Leading questions invalidate the data. Small samples find problems, not their prevalence. Protocol synthesised from the cited sources; no result is claimed.