How to take user interview notes that separate fact from opinion

To take user interview notes, get consent first and have a second person take notes so the interviewer can listen. Write what the person said and did, word for word where you can, and leave what it means for later. Afterwards, fill in the problems and ideas, and compare across participants.

The rules here come from the UK government's guidance on taking notes in its Service Manual, plus User Interviews 101 by Maria Rosala and Kara Pernice at Nielsen Norman Group. The Service Manual is written for UK public services. Its advice on notes works elsewhere, but it isn't legal advice for your own country.

Before the call

Get consent. The Service Manual says "you must get informed consent from all participants" before any notes or recording. It also says to use them only for what was agreed.

Find a note-taker. It says "always try to invite an observer who can also act as a note-taker". The interviewer can then focus on the participant, and you get at least one full set of notes. It also says note-taking is a skill that needs practice, so a first-timer shouldn't be your only record.

Label people by code. Our interview notes template uses "P1, sales". Keep the list that links codes to names somewhere else, and remove personal details from the notes afterwards, as the Service Manual asks. On sensitive topics, it says not to collect names, locations or organisations at all.

Which column gets filled in when

The Service Manual says "Good notes stick to observations (for example, something you see or hear during a session) rather than personal interpretations". The first two columns are for that. Problems and ideas are interpretation, so we fill them in afterwards, while the call is fresh. If an idea arrives during the call, or the participant suggests one, write it down in Ideas and mark who said it.

Three invented interviews about an expense app

The participants, the app and what they say below are all made up. Nobody took part in this research. The notes are on our sample board, where P1 is in sales, P2 in finance and P3 a field technician.

Check each note: seen or said?

Take P2's note, "Approves in a batch on Fri". On a video call, did the note-taker watch this happen? No. P2 described it. Rosala and Pernice write that interviews "collect reported behaviors (rather than observed behavior)", and that to learn what users actually do, "we need to observe them or collect data about their behavior". So the note should say where it came from.

The third assumes P3 showed the form on camera, which is the sort of thing a note-taker should note when it happens. If P3 only described it, it gets "Says" as well. A "Says" note tells the team what they know so far. People also forget things and leave things out, as the NN/g article points out, so these notes are a reason to go and look.

Fill in the rest straight after

Now the team adds problems and ideas for each row.

Each problem should trace back to a note in the first table. "Retyping later" comes from the paper form. If it doesn't trace back, either the note's missing or you've made an assumption.

P2's problem deserves a closer look. "Approvals take forever" is P2's complaint about the process, and P2 is the person approving. Does P2 mean their own approvals, or someone else's? Nobody asked. That's a follow-up question, and one you wouldn't have spotted if the note read "Approvals are slow".

Compare across rows, and be honest about what's there

Our template says to read each column from top to bottom and mark what comes up more than once. Here, no two problems match. P1 and P3 share something, though, since both record things later than they happened, one because a receipt is in the car and the other because there's no signal. P2 sits at the other end of the process.

That's two people out of three, and it's a lead. Three interviews can't tell you how many of your users have this problem. It's a reason to ask the next participants about it, and perhaps to watch one of them file an expense.

After the interviews

The Service Manual suggests you "Aim to spend 1 hour analysing every 2 hours of research". Three interviews at 45 minutes each come to 135 minutes, so this team books a little over an hour.

Its analysis guidance says to use a single note for each observation, then sort them into themes until clear groups emerge. Copy your rows onto single notes and move them to an affinity map, and later use them for an empathy map or a user persona.

Go back through the board as well, and remove anything that identifies a person. The Service Manual asks every note-taker and observer to do this.

Frequently asked questions

Should I record the interview as well?

If the participant agrees, a recording lets you confirm the exact words, and notes are still useful for finding your way around it. The Service Manual says audio suits in-depth interviews and is often less intrusive than video. It also recommends intelligent verbatim transcripts, which leave out filler words.

Can I take notes myself while interviewing?

The Service Manual says you can take brief notes, but to invite a note-taker wherever you can. If you're on your own, record the call with consent and write the notes afterwards.

Typing or pen and paper?

It says typed notes are easiest to keep and analyse later. Pen and paper are more flexible, but they take more work to use. If you use a shared board, type straight into the participant's row.

Should a participant's suggestions count as findings?

Write them in Ideas and ask what problem they'd solve. The suggestion is what they said. The problem is what you can look into.

Set up your next round

Open the user interview notes template and add one row for each participant, using codes. Share it with your note-taker and agree who types where. Add "Says" or "Seen" to the Observations notes from the first call onwards, because it's much harder to work out later.