Voice of Customer
Part of Customer interviews
Recording interview findings without inventing consensus
Record interview observations, participant reports and interpretations separately without overstating consensus.
An interview finding should state who reported or did what, in which situation, and how strongly the collected accounts support the interpretation. Never turn a memorable remark into “customers want”, or erase a contradictory account to tidy a theme.
Capture the account before the conclusion
During or immediately after each interview, record the participant code, relevant context, the incident described and any exact wording you are permitted to keep. Separate three layers: what the participant said, what the interviewer observed, and what the team thinks it may mean.
A note such as “P03 said the renewal screen returned to the start after payment” differs from “the payment system is broken”; the latter needs technical verification.
If a recording is allowed, do not assume it replaces notes. Mark the time of important moments and unresolved questions. If recording is declined, a second note-taker can help, provided the participant knows who is present and how notes will be used.
Keep personal details out of shared finding summaries when they are not needed. GOV.UK's research privacy guidance treats notes and recordings as research data requiring careful handling.
Recording Interview Findings Without Inventing Consensus
- Record participant code and contextNote the participant ID (e.g., P03) and situation (e.g., during renewal process)
- Capture exact words (if permitted)Document direct quotes with permission, e.g., 'renewal screen returned to start after payment'
- Note interviewer observationsRecord non-verbal cues or system behaviour observed during the interview
- Separate interpretation from evidenceLabel inferences as such; avoid stating ‘the system is broken’ without technical validation
- Flag unresolved questions and time markersMark key moments in recordings for follow-up; use second note-taker if recording declined
What to Record vs. What to Avoid
- Do record
- P03 said the renewal screen returned to the start after payment
- Avoid claiming
- The payment system is broken
- Do record
- Four of six participants checked email before contacting support
- Avoid claiming
- Most customers check email before support contact
Use precise language for patterns
If your notes show it, say “four of the six people interviewed described checking their email before contacting support”, and state how those six were recruited. Do not translate that into a population rate.
If one person did the opposite, include the exception when it changes the product decision. Counts can orient the reader to the evidence, but the value of qualitative research is often the explanation around an observed pattern.
Consider a compact evidence table:
Field / What to record
- Observation
- The reported action or observed event
- Context
- Participant type and situation
- Evidence
- Note or permitted excerpt, with participant code
- Interpretation
- A possible reason, labelled as inference
- Contrary case
- Account that challenges the pattern
- Next check
- What would confirm or disprove the interpretation
This is a suggested record format, not a requirement to publish participants' words. Protect identities in the version circulated beyond the research team.
Key Principles for Qualitative Research Reporting
- Protect privacyExclude personal details in shared summaries; treat notes as research data
- Include contrary casesIf one person did the opposite, note it—especially if it affects design decisions
- Link changes to evidenceTag each proposed change to participant codes and supporting accounts
State the sample boundary
The claim “all interviewed account administrators struggled to find the setting” has a clear boundary if all did. “All customers struggle” does not.
Include the recruitment channel and any missing group next to the finding. If the group was recruited from recent support tickets, they cannot stand in for customers who completed the task without contacting support.
NN/g's thematic-analysis guidance describes tagging observations and quotations with codes to help discover significant themes. Link each proposed change to the participant codes and accounts that support it, and note any contrary case.
Review Before Sharing Findings
- Did I state the sample boundary?E.g., 'All 6 account admins recruited from recent support tickets struggled'
- Did I specify recruitment channel?Include how participants were selected (e.g., via ATO portal, ABN lookup)
- Did I note missing groups?E.g., 'Not representative of users who completed task without support'
- Is the interpretation labelled as inference?Yes — avoid presenting assumptions as facts
