The user interview notes template that keeps the participant's exact words

What a user interview note has to do

Interview notes have one job that ordinary meeting notes do not. They have to survive being read by someone who was not in the room, three weeks later, when the team argues about what the user actually meant. Everything in this template exists to pass that test.

Most research notes fail it the same way. The note-taker writes conclusions instead of evidence. "Struggled with onboarding" is a conclusion. Nobody can check it, nobody can quote it in a readout, and after six sessions you still cannot tell whether all six people struggled in the same place or in six different places.

So the template keeps four things apart, in separate blocks: what the person said, what the person did, what surprised you, and what you concluded. The first three are evidence. The last one is yours, and it sits at the bottom with a label on it, so nobody later mistakes your idea for something the participant told you.

The ten blocks, in order. 1. Session header. 2. Participant profile. 3. The one research question. 4. What they said, word for word, with timestamps. 5. What they did, written as plain observation. 6. The pain, ranked. 7. Surprises. 8. What they asked for, and the problem underneath it. 9. Tags for synthesis. 10. Your own read, labelled as yours. Blocks 1 to 3 are filled before the participant says anything, 4 and 5 during the session, 6 to 10 in the ten minutes after they leave. The fields for all ten are three sections down. Whatever you keep or cut, the note has to stay four things.

• Comparable. Same fields every session, so session 11 lines up beside session 2 without any rewriting.
• Quotable. Every claim in the final readout can point at a participant, a timestamp and a sentence.
• Checkable. Anyone who disagrees with your conclusion can open the recording at that timestamp and hear it for themselves.
• Fast to fill. If a field needs real thought during the session, it is in the wrong block. Thinking happens after the participant leaves.

Say versus do, and why the exact words matter

People are honest and still wrong about themselves. That is not a character flaw, it is how memory works. Ask someone how often they check a dashboard and you get the answer that feels true, not a count.

So the template has two evidence blocks, not one. Said is anything that came out of their mouth. Did is anything you watched happen: a click, a file they opened, a tab they switched to, a long pause, a workaround they performed while explaining something else. When the two disagree, that gap is usually the most valuable thing in the session. Here is what the split looks like in practice.

• Write the said rows word for word. Not tidied, not corrected, not translated into product language. If they say "the thing where you pick the dates is annoying", that is what goes in the note, not "friction in the date picker".
• Their words carry information yours do not. Which parts of the product they even have a name for. How strongly they feel. Whether they blame the tool or blame themselves. Paraphrasing removes all of that and you cannot get it back later.
• Write the did rows with no interpretation. "Opened three files to answer one question" is an observation. "Was confused" is your conclusion about it, and it belongs in the last block.
• Timestamp everything. A quote with 00:19:05 next to it is evidence someone can verify in twenty seconds. A quote without one is a claim. If you are recording the interview, the timestamps come with the transcript instead of being typed by hand.

The template, part 1: who, and what the session is for

Copy everything from here to the end of part 3. Square brackets are placeholders to replace. You can delete blocks you never use, but delete them at the end of the study, not in the middle of it. A field that is empty in four sessions and full in eight is not comparable with anything.

Blocks 1 to 3 are all filled before the participant says anything. Block 1 is admin and takes thirty seconds. Block 2 is who you are talking to. Block 3 is the one thing this session has to answer, written down in advance so the session cannot quietly turn into a different study halfway through.

The template, part 2: the evidence log

Blocks 4 and 5 are the heart of the note, and they are one table with a Said/Did column so the split stays visible while you type. Everything above this table is context. Everything below it is interpretation. This is the only part that is pure evidence.

Aim for eight to twenty rows in a 45-minute session. Fewer than eight usually means you were summarising while you listened. Many more than twenty usually means you were transcribing, which is a job for a recording, not for a person.

• The tag column is filled after the session, not during it. Trying to pick a tag live pulls you out of listening.
• A row is one idea. If a participant talks for two minutes, that is three or four rows with three or four timestamps, not one long paragraph.
• Mark your own inferences. If you must write a thought in this table, wrap it: [I think she means the branch manager here]. Brackets mean "this part is not evidence".
• Never fix their grammar. A non-native speaker's phrasing tells you which words they actually use for the thing. Change it and you have quietly replaced the participant with yourself.

The template, part 3: pain ranked, surprises, tags, your read

Block 6. The pain, ranked. The single most useful block in the file, and the one people skip because ranking is uncomfortable. Fill it in the ten minutes after the session, while it is fresh. Three to five rows, ranked by how much the pain costs the participant, not by how loudly they said it.

Rank on evidence, not volume. The loudest complaint is often the smallest one, because small annoyances are easy to describe and big structural problems are things people have stopped noticing.

• Block 7. Surprises. [What happened that you did not expect], [timestamp], [what you expected instead]. One to three, no more. If nothing surprised you, write "nothing surprised me" and treat that as a warning sign about the questions you asked.
• Block 8. What they asked for. [The feature or change, in their words], then the problem underneath it: [what they were trying to get done]. Requests go here and nowhere else, so they never get mixed in with observed pain. A request is a participant doing your design job badly. The problem underneath it is the useful part.
• Block 9. Tags for synthesis. [#five-to-eight-tags-from-the-study-vocabulary]. Pulled from the fixed tag list, not invented per session. New tag candidates go in a separate line: new tag candidates: [ ].
• Block 10. MY READ (not the participant's). [Two or three lines of what you think this session means.] Written in the first person, kept clearly separate from everything above it, and always the last thing in the file.
• Open questions for the next session: [the thing you should have asked and did not]. This is the block that quietly makes session 8 better than session 7.
• Follow-ups owed: [send the summary / share the prototype / send the incentive by Friday].

Filled example: discovery interview, P07

A discovery round for a staff scheduling product, talking to people who build the rota in small clinics. This is session 7 of 12. Names and numbers are made up, but the shape is the shape you will actually get.

Session header. P07. 2026-08-19, 14:00, 47 minutes. Rota Study, discovery round, session 7 of 12. Interviewer: Marta Kelly. Note-taker: Sam Oduya. Video call, recorded, consent captured at 00:00:22. Incentive: 40 USD voucher.

Participant profile. Operations manager at a three-branch dental clinic group, 24 staff scheduled, in the role four years. Builds next month's rota herself over two evenings, publishes it as a printed sheet at each reception desk and a file in the group chat. Tools today: Excel, the branch WhatsApp group, a printed sheet, the clinic's booking software (read-only for her). Screener answers, copied exactly: "I build the rota myself: yes." "How many staff: 24." "Do you use a scheduling tool: no, Excel." Recruitment source: never used us. Unusual: three sites, which most of our other participants do not have.

Research question. How do clinic managers build next month's rota today, and where does it break after it is published? Sub-questions: what does the rota get built from, who is allowed to change it, how does a change reach the people affected, what happened last time a change was missed.

• Pain, ranked. 1. "Finding out about a swap after it happened". Evidence at 00:19:05 and 00:14:10. Two or three times a month. She re-reads the WhatsApp group on Sunday night to catch them.
• 2. "Typing the same change in two places". Evidence at 00:14:10. Several times a week. She does it by hand and accepts that sometimes one of the two ends up wrong.
• 3. "The printed sheet goes out of date". Evidence at 00:06:20 and 00:31:15. Weekly. She reprints when she remembers, and reception trusts the paper over the file.
• 4. "Nobody uses the new thing". Evidence at 00:33:52. Happened once, and it now blocks every purchase. They went back to Excel and stopped looking.
• Surprise 1. She does not want the rota built for her. She defended the Excel file twice, at 00:04:12 and 00:09:45. The pain is confirming the rota after it is published, not creating it. Our research question assumed the opposite.
• Surprise 2. Paper is the source of truth at reception, 00:31:15. Any change that does not reach the printed sheet does not exist for the front desk. We had not asked a single question about printing.
• She asked for: "a group message that updates itself" (00:28:00). The problem underneath it: she needs a swap to reach eight people and reach the paper, without her typing it twice.
• Tags: #excel-lock-in #scattered-truth #post-publish-churn #double-entry #swap-invisible #confirmation #paper-workflow #adoption-failure #stated-vs-actual
• MY READ (not P07's): we may be solving the wrong half of this. Four of the seven participants so far have described post-publish chaos, and only one has complained about building the rota. If P08 to P12 say the same, the build-the-rota feature set is not the wedge.
• Open questions for next session: who is actually supposed to tell her about a swap? She could not answer. Ask P08 directly. Also ask everyone which is worse, building or confirming, in those words.
• Follow-ups owed: send the incentive by Friday, send her the two-line summary she asked for.

Variant: usability test notes

A usability test is not a discovery interview and the notes should not look the same. In discovery you are collecting stories about the past. In a usability test you are watching someone try to do something in front of you, right now, and the evidence is almost entirely in the Did column.

Keep blocks 1, 2, 3 and 10 from the main template. Replace the evidence log with a task table, one row per task. Add a severity number, because a usability finding without severity turns into an argument about which bug to fix first.

Two rules that only apply here. First, write what they said at the moment something went wrong, not what they said about it in the debrief. The debrief answer is polite and reconstructed. The live one is real. Second, record whether you helped, and how much, because a task that only succeeded after a nudge did not succeed.

• Severity, per finding: [1 cosmetic / 2 slows them down / 3 blocks the task / 4 blocks the task and they blame themselves]. Level 4 is the one to fix first, because a user who thinks they are stupid does not come back.
• Assists given: [how many times you stepped in, and exactly what you said]. Note this even when it feels embarrassing. It is the difference between a real pass and a friendly one.
• The moment they blamed themselves: [timestamp and quote]. "Sorry, I'm not good with computers" is a design defect written in the participant's voice.
• What they expected to happen before clicking: [quote]. Ask it before every risky click. The gap between expectation and result is the finding.
• Debrief quotes, kept separate: [ ]. Useful, but weaker evidence than anything from during the task. Label them so nobody mixes the two.

Variant: churn interview notes

A churn interview has one trap in it, and the whole variant is built to avoid the trap. Ask someone why they left and they will say "it was too expensive" or "we didn't use it enough". Both answers are almost always a summary of something else, offered because it is a socially easy thing to say to a person from the company.

So this variant chases events, not reasons. An event has a date, a trigger and a person attached to it. A reason has none of those, which is why reasons cannot be checked and events can.

Keep blocks 1, 2, 4, 5 and 10. Replace the ranked pain block with the fields below, and use them in this order, because working backwards from the cancel date to the first crack is far more reliable than asking "why did you leave" and writing down the answer.

• Cancelled on: [date]
• Signed up on: [date]
• Last real use: [date, if you can see it in your own data before the call]
• What changed in their world around then: [reorg, new manager, budget cycle, a project ended, someone left]. Half of all churn is somebody's job changing, not your product changing.
• The last straw: [the specific event, with a date, that made cancelling the plan rather than a thought]. Push for a date. "Around March" is not an event yet.
• Who actually decided: [the user, their manager, finance, procurement]. Often the person you are talking to was not the decider, and that reframes the whole interview.
• Who else was in that conversation: [names and roles, so you know how many people you lost with one decision]
• What they use now: [tool, or "nothing, we went back to a spreadsheet"]
• What it does that we did not: [in their words]
• What it does worse: [the honest counterweight. If they cannot name anything, the switch was not close.]
• When they stopped, before they cancelled: [the gap between last real use and cancellation. A four-month gap means you lost them in month one and only found out in month five.]
• What would have kept them: [ask it, write it down, then treat it as the weakest line in the file. It is a hypothetical and people are bad at hypotheticals.]
• Would they come back, and for what: [ ]. A much better question than the one above, because it is about a decision they might really make.

Making twelve filled templates comparable

The template only pays off in synthesis. One interview is a story. Twelve interviews in the same shape is evidence, and the tag column is what turns one into the other.

Keep the tag vocabulary small and fixed. Eight to fifteen tags for a whole study. Every new tag you add halves the chance that two sessions ever line up on it, and a tag that appears in exactly one session is a note to yourself, not a pattern.

• Tag rows, not sessions. A session tagged #onboarding tells you nothing. A row tagged #onboarding, at 00:14:10, in a participant's own words, is something you can put in a slide.
• Hold new tags for two sessions. If the same idea shows up again, promote it into the vocabulary and go back and tag the earlier session. If it does not show up again, it was one person's phrasing.
• Fill the tag column with the evidence log open in front of you. Tags go on rows in the ten minutes after the session, while every timestamp is still visible. A tag you add a week later comes from your memory of the session rather than from the row it is attached to, and it will not hold up when somebody opens the recording to check it.
• Set the threshold before you start. Something like: same behaviour observed in 3 of 12 sessions, or 2 of 5 within one narrow segment. Written down in advance, it stops the study from becoming a hunt for quotes that support the plan.
• Separate the say-column pattern from the do-column pattern. They will not match, and where they diverge is your best finding. Nine people said price. Three people actually switched because of price. Those are two different sentences in the readout.
• One search over twelve filled templates, not twelve files opened in turn. To find everyone who mentioned printing you want a single search across the study, not a morning of reopening documents and scrolling for the word. If the sessions were recorded and transcribed, you can ask a question across every note at once and get the participants and timestamps back.

If you would rather listen than type

There is a real trade in interview note-taking. The person writing verbatim quotes is not listening properly, and the person listening properly is not capturing verbatim quotes. That is why teams send two people to a 45-minute session, which is an expensive way to solve a recording problem.

Noter AI records the session, in the room from a phone on the table or from a bot that joins a Zoom, Google Meet, Microsoft Teams or Webex call, and gives back a transcript with a timestamp on every line and speaker labels for who said what. That covers the timestamp and the exact-words columns, which are the two that cost the most to type by hand. Quotes come back word for word, already attributed, already citable, and you can tap any line to hear that exact moment, which is how you check a quote before it goes in a readout. You can also import an audio file you recorded on something else, from the Files app or shared in through the iOS share sheet.

For the write-up, the Custom output style lets you describe this structure once, in plain words, and get the same shape out of every session: profile, research question, quotes with timestamps, surprises, pain, tags. The To-do list style handles follow-ups owed, and Key bullet points is enough for a quick internal share. If the transcript hears a participant's job title or a product name wrong, edit the line and re-run the summary so the summary picks up your fix.

Put each study in its own folder so its notes and transcripts are searchable together. AI chat answers one question across all your notes at once, instead of you rereading twelve documents. Ask which participants found out about a change after it happened? and you get back the sessions and the moments to open, which is the twelve-session synthesis step turned into a search box. What comes back is a set of pointers, so you still read the rows yourself before any of it reaches a slide. More on the research workflow on the page for researchers and user interviews.

Interviews go better in the participant's own language, and this is where most transcription tools quietly fail. Noter AI transcribes in 60+ languages with automatic detection and tags language word by word, so a participant who moves between Arabic and English inside one sentence is quoted accurately in each, rather than transliterated into nonsense, and finished notes translate into 18 languages when the readout goes to another office. The full comparison is on the best app for transcribing multilingual meetings.

Pricing is $9.99/month or $49.99/year, per person, not per seat. Research budgets are usually counted per study rather than per month, so do it that way: a round of eight interviews on the annual plan costs about the same as one participant incentive. It also fits the way research staffing actually works, where a designer or a PM runs two sessions during a busy sprint and none for the rest of the quarter. They still need their own subscription, because there is no shared account here, but $9.99 for the month they are active, cancelled after, is a far smaller decision than a $14 to $19 seat somebody has to approve and then remember to remove. Test it on one real session, on iOS or Android.

• What it will not do for you: the Did column. A microphone cannot see a screen, so observed behaviour is still your job during the session. Type short behaviour notes live and let the recording carry the quotes.
• Ask for consent on the recording. Say it out loud in the first thirty seconds and note the timestamp, so the permission is stored with the evidence.
• Audio only. You can import audio files, not video or screen recordings, so record the session's audio if you also capture the screen elsewhere.
• Everything is processed in the cloud, encrypted in transit and at rest, and you can delete a recording whenever you want. Check that against your study's consent form before you record anything.