Blog••Journalism

User Research Interview: Questions and a Note-Taking System

Sarah Johnson

Sarah Johnson

Writes about field sales, meeting notes and voice-first workflows at ParrotNotes. Every article is reviewed by the ParrotNotes product team before it goes live.

User Research Interview: Questions and a Note-Taking System

Priya ran six customer interviews in one week. On Friday she opened her notes to write up the findings and found lines like "liked it", "export confusing?" and "mentioned Excel a lot". She knew one participant had said something sharp about the export flow. She couldn't find the words, and she couldn't remember which of the six had said it. (Priya is a composite, not a real person.)

Most first-time interviewers end the week this way. The conversations were good. The record of them is not.

A user research interview is only as useful as what you can pull out of it a week later: the exact phrase, the workaround, the moment the participant went quiet. This guide gives you 30 questions organized by stage, the questions that spoil the data, a one-page note sheet you can copy, a 10-minute debrief, and a plan for interviewing alone. If you also want the interview on record, download ParrotNotes free and capture it on the phone in your pocket.

What a user research interview is (and isn't) good for

A user research interview is a one-to-one conversation in which a researcher asks open questions about a participant's past experiences, listens, and follows up to learn how they work, what gets in their way and why. Nielsen Norman Group calls it an attitudinal method: it captures what people report, not what they do.

That distinction matters. Jakob Nielsen's blunt summary in Interviewing Users is that "what users say and what they do are different". Interviews are strong for discovery: how people think about a problem, what they tried, what happened. They are weak for predicting whether someone would use a feature they haven't seen, and useless for settling a button colour.

Nielsen also names the query effect: "People can make up an opinion about anything" if you ask. So the job of your questions is to pull stories about real events, and the job of your notes is to keep those stories separate from your own interpretation. Both halves are below.

NN/g's guide to user interviews opens with the line most teams skip: "Think of an interview as a research study, not a sales session or an informal conversation." Three things follow from it.

Write two or three goals that feed a decision. "Learn about onboarding" is too broad. "Find out what people do in the first hour after signing up, and where they stop" tells you which questions to write and which to cut.

Write a guide, not a script. A page with your main open questions and the follow-ups nested under them. Pilot it on a colleague once; you'll find the question that confuses people and the one that takes ten minutes.

Get consent before you record. Say in the opening that you'd like to record, why, who will hear it and how long you'll keep it, then wait for a clear yes on the recording itself. Ask again if someone joins late. Recording law varies by place; our guide to one-party consent states covers the US rules for recording a conversation you are part of. Keep contact details out of the notes and use a participant code (P1, P2) instead, which the 18F team recommends in its tips for capturing interview data.

30 user research interview questions by stage

Each stage below has the questions and the probe that goes with them. You will not ask all 30 in one session. Pick two or three per stage that serve your goals, and keep "Tell me more about that" ready for every answer.

Warm-up (3 to 5 minutes)

  1. Tell me a little about your role and what a normal week looks like.
  2. Where does [the task] fit into that week?
  3. Who else is involved when you do it?
  4. What tools do you keep open while you work on it?

Probe: "What does that look like on a busy day?"

The last time (the most important question)

Jeff Gothelf calls "Tell me about the last time you [did something]" the most valuable question you can ask a user, a point Simon Willison picked up and repeated. The last time is specific, recent and real, so the answer is evidence rather than a forecast.

  1. Tell me about the last time you [did the task].
  2. What made you do it that day?
  3. What happened first? Then what?
  4. How did you know it was done?
  5. What did you do right after?

Probe: "You said [their word]. What did you mean by that?"

Walk-through

  1. Could you show me how you did it, step by step, as if I were sitting next to you?
  2. Where did you pause or go back?
  3. What were you looking for at that point?
  4. What did you expect to happen there?

Probe: "What would have happened if that step didn't exist?"

Pain and workarounds

Nielsen notes that especially difficult or especially smooth experiences are the most vivid and the most useful to ask about.

  1. Tell me about a time this went badly.
  2. What did you do to get around it?
  3. How often does that happen?
  4. What did it cost you, in time or in something else?
  5. Tell me about a time it went unusually well. What was different?
  6. Have you ever stopped doing it altogether? What happened?

Probe: "Walk me through what you did next."

Context and constraints

  1. Who sees the result of this work?
  2. What deadlines or rules shape how you do it?
  3. What have you tried before, and why did you stop?
  4. Where do you keep the information you need for it?
  5. What do you do when you're not sure what to do?

Probe: "Can you give me an example from the last month?"

Close (5 minutes)

  1. What do you wish someone had told you when you started doing this?
  2. If you could change one thing about this process, what would it be, and why that one?
  3. Is there anything I should have asked and didn't?
  4. Is there someone else I should talk to about this?
  5. Could I follow up by email if something is unclear?
  6. Would you be open to another conversation once we've built something?

Probe: none. Thank them, stop the recording on the record, and tell them what happens next.

Questions that spoil the data

Some questions produce confident answers with nothing behind them. Cut these from your guide:

  • "Would you use a feature that...?" A prediction. Nielsen's point: users can't reliably say whether they'd use something they haven't seen. Ask about the last time they faced the problem instead.
  • "How do you usually do this?" You get an idealized workflow with the shortcuts removed. Ask about the last time.
  • "Wasn't that step frustrating?" Leading. Ask "How was that step?" and wait.
  • "Do you like the dashboard?" Yes or no, and the query effect fills in the rest. Ask what they did with it last week.
  • Two questions in one. "How do you plan and track it?" gets an answer to one half.
  • Anything that can make someone feel stupid. NN/g's example is asking about the last book someone read. If you need to know, ask it gently and late.

The note-taking system

A note-taking system has three parts: who writes, what the marks mean, and what the page looks like. Set all three before the first interview so every participant's notes look the same.

Who writes

The 18F team's rule is a dedicated note taker who is not the interviewer, so the interviewer can listen. If you have a colleague, use them. If you're interviewing alone (most founders and many PMs are), do this instead: record the interview with consent, keep your pen for timestamps and stars only, and write the full note from the recording in the 10-minute debrief. Trying to do both jobs at once is how "liked it" ends up on the page.

The four-symbol key

Both 18F and the Looppanel team's interview notes template separate what the participant said from what you thought. Use four marks and nothing else:

  • "..." a direct quote, word for word
  • [...] something you observed: a pause, a sigh, a screen they opened
  • {...} a follow-up to ask later or a question for the team
  • * a moment worth returning to in the recording

Never write a summary inside quote marks. If you didn't catch the exact words, write [said something about export being slow, check 14:20].

The one-page note sheet

USER RESEARCH INTERVIEW NOTE SHEET
Participant code:            Date:           Interviewer / note taker:
Segment or screener fit:                     Recording: yes / no (consent at __:__)
Goal this session serves:

STAGE          NOTES (use " " [ ] { } *)                            TIME
Warm-up
Last time
Walk-through
Pain / workaround
Context
Close

TOP 3 QUOTES (word for word, with time)
1.
2.
3.

OBSERVATIONS THAT CHANGE HOW A QUOTE SHOULD READ

FOLLOW-UPS OWED (to participant / to team)

FIRST READ (write in the debrief, not during): one sentence on what this person is telling us

Marcus, a composite founder, interviewed eight clinic managers about scheduling. For the first three he typed everything and missed the tone. For the last five he used the sheet with a colleague, Lena, writing. Lena's page for P6 had a star at 22:10 and [laughs] "We have a whiteboard for the whiteboard." That line opened the findings deck, and it only exists because someone was writing quotes rather than paraphrases.

The 10-minute debrief

Do it before you open email. Within ten minutes of the session ending, fill in the three quotes, the observations and the first read. Looppanel's advice is to clean the notes up right after the interview and share them with the team within 24 hours; the first-read sentence is what makes that share useful. If something stood out and you can't find the words, go to the starred timestamp now, not next week.

Interviewing alone this week? Try ParrotNotes free, record each session with consent, and write the sheet from the transcript while the conversation is still warm.

From notes to themes

One sheet per participant is the unit of analysis. After five sessions, lay the top-three quotes side by side and tag each with a short label ("export", "double entry", "manager approval"). When a label appears on three or more sheets, that's a theme worth a slide. When a label appears once, it stays in the appendix no matter how good the quote is.

Keep the symbol discipline through analysis: quotes in the deck come from " " lines only, and anything inside [ ] is presented as an observation. If you run a formal coding pass, our guide to qualitative interview transcription covers transcript levels and a coding-ready format. Group sessions follow the same logic with more voices; see focus group transcription for speaker labels and turnaround.

Recording the interview with ParrotNotes

Many of the best user research interviews don't happen on a call. They happen at a participant's desk, in a clinic back office or across a café table, where there is no meeting link and no bot to invite. ParrotNotes records on your phone in the background, with the screen off, so the phone sits face down between you and the conversation stays a conversation. Ask for consent on the record, tap record, and put it away. Our guide to recording an interview on your phone covers placement and a two-minute sound check.

When the session ends you get a transcript, a summary and the action items you promised the participant. Ask the transcript "Every time they mentioned export" and you have your " " lines with timestamps for the note sheet. Participants who switch between languages mid-sentence are transcribed as they spoke on Pro, which supports 99+ languages with translation.

Plan limits, honestly: the Free plan includes 100 minutes a month with up to 30 minutes per recording, an AI summary on every recording, and 5 AI-powered recordings a month. That covers screener calls and short intercepts. A 45-minute interview needs Pro ($19.99 a month, or $14.99 a month billed annually), which allows up to 3 hours per recording and 3,000 minutes a month, with unlimited AI and search across every session. Download ParrotNotes free and test it on your pilot interview.

Ask about the last time, write down the words

A good user research interview comes down to a few habits: goals that feed a decision, consent before the record button, questions about the last time rather than the usual way, four symbols that keep quotes and opinions apart, and a debrief before the details fade. Do that for five participants and the findings write themselves from the top-three quotes.

Copy the question bank into your guide, print the note sheet, and run your pilot this week. Get ParrotNotes free so the exact words are there when you need them.

Frequently Asked Questions

How many user research interviews do I need?

Enough to see the same theme on three or more note sheets. Most teams start with five to eight participants per distinct user segment and pause after five to check whether new sessions are still producing new themes. If they are, keep going; if not, move to synthesis.

How long should a user research interview be?

Plan for 45 minutes: five for the opening and consent, five for warm-up, 30 for the last-time and walk-through questions, and five to close. Sessions that combine an interview with a usability task run longer, around 90 minutes according to Nielsen Norman Group.

What is the best first question in a user interview?

"Tell me about the last time you [did the task]." It asks for a specific, recent event instead of a habit or a prediction, so the answer is evidence. Follow it with "What happened next?" and "What did you mean by [their word]?"

Should I record user research interviews?

Yes, with explicit consent given on the record at the start, and a clear statement of who will hear it and how long you'll keep it. Recording lets a solo interviewer listen instead of typing, and gives you word-for-word quotes for analysis. Check local recording law before you start.

How do I take notes during a user interview without losing the conversation?

Use a dedicated note taker if you can. If you can't, record with consent and limit your live notes to timestamps and stars, then complete the note sheet from the recording in a 10-minute debrief. Keep quotes in quote marks and your interpretations in square brackets.