Skip to main content

Product

User Interview Template

A user interview note is only useful if a teammate can tell what the participant said from what you concluded. This template keeps verbatim quotes, observed behavior and your interpretation in separate sections, ends with a three-line snapshot, and links every session to one study note for synthesis.

Updated 2026-10-27

Copy and adapt

The template

User interview notesTemplate

[Study name], [P-number], {{date}}

Participant: [P07], [segment], [role and company size], recruited via [source] Interviewer / note-taker: {{author}} / [name] Session: [discovery / usability / churn / concept test], [45 min], recorded with consent: [yes / no] Study: [[Study name]] Hypothesis this session tests: [one sentence we could be wrong about]

Context (their words)

  • Role and day-to-day: [...]
  • Tools they use for this today: [...]
  • Last time they did [the job we care about]: [when, what happened]

Quotes (verbatim, with timestamps)

  • [mm:ss] "[Exact words]"
  • [mm:ss] "[Exact words]"

Observed behavior

  • [mm:ss] [What they did, where they hesitated, what they skipped]

My interpretation (kept separate)

  • [What I think it means] (based on [timestamp])

Snapshot (fill in within 15 minutes)

  1. [Takeaway]
  2. [Takeaway]
  3. [Takeaway]
  • Hypothesis: [supported / weakened / no signal] because [evidence]
  • Surprise: [what we did not expect]
  • Themes: #[theme] #[theme]

Follow-ups

  • Send thank-you and incentive (@[name]) @due(YYYY-MM-DD)
  • [Clip, quote or question for the next session] (@[name]) @due(YYYY-MM-DD)

5 examples

Examples for different situations

The same structure, filled in for the situations people actually bring to it. Copy the one closest to yours.

1.Discovery interview that weakened the hypothesis

When it fits: Use this when you are early, you have a hunch about a problem, and the session's real value is finding out the hunch is wrong before anyone builds it.

Discovery interview that weakened the hypothesisExample 1

Small-firm invoicing study, P03, 2026-11-05

Participant: P03, bookkeeping firms under 10 staff, senior bookkeeper at a 6-person firm, recruited via the accountants' forum post Interviewer / note-taker: Owen Lindqvist / Bea Sato Session: discovery, 45 min, recorded with consent: yes Study: [[Small-firm invoicing study]] Hypothesis this session tests: small firms chase late invoices by hand and would pay to automate the reminders.

Context (their words)

  • Handles 140 client businesses, mostly cafes and trades.
  • Tools: Xero, a shared spreadsheet, email.
  • Last month-end: "three late nights matching bank lines to invoices that clients paid in two parts."

Quotes (verbatim, with timestamps)

  • 08:15 "We don't chase. If a cafe pays late, it's because they're having a bad month. I'm not sending them a robot."
  • 17:40 "Reconciliation is the job nobody bills for. That's where my evenings go."
  • 31:02 "If something matched split payments I'd pay for it tomorrow. Reminders, no."

Observed behavior

  • 22:00 Shared her screen and opened the spreadsheet: 61 rows flagged "part paid" for October alone.
  • Scrolled past the reminder settings in Xero without comment. Has never turned them on.

My interpretation (kept separate)

  • Chasing is a relationship decision for her, not a workload problem (08:15).
  • The pain is reconciling partial payments, and she puts a price on it (31:02).

Snapshot

  1. She does not chase late invoices and does not want automated reminders.
  2. Month-end reconciliation of split payments costs her three evenings a month.
  3. She would pay for split-payment matching now.
  • Hypothesis: weakened because she rejected reminders unprompted and has the feature available and unused.
  • Surprise: 61 partial payments in one month for one firm.
  • Themes: #reconciliation #client-relationship

Follow-ups

  • Send thank-you and 75 dollar gift card (@Bea) @due(2026-11-06)
  • Add a split-payment question to the guide for P04 to P08 (@Owen) @due(2026-11-06)

2.Usability test of a new onboarding flow

When it fits: Use this when the participant is working through tasks on a prototype, what they do matters more than what they say, and the team needs to know exactly where the flow breaks.

Usability test of a new onboarding flowExample 2

Meal-planner onboarding v3, P11, 2026-11-12

Participant: P11, new users who cook 3+ nights a week, nurse working night shifts, recruited via the in-app waitlist Interviewer / note-taker: Kemi Adeyemi / Lars Brandt Session: usability, iPhone prototype, 30 min, recorded with consent: yes Study: [[Onboarding v3 usability]] Hypothesis this session tests: users can set dietary preferences and get a first week plan in under 3 minutes.

Tasks

  1. Create an account and set preferences. Completed in 4:10 (target 3:00).
  2. Swap Wednesday's dinner for something vegetarian. Completed in 0:50.
  3. Find the shopping list for the week. Failed after 1:30, gave up.

Quotes (verbatim, with timestamps)

  • 02:20 "Is 'pescatarian' under vegetarian or separate? I'll just skip it."
  • 09:45 "I'd expect the list to be on the plan screen. Where is it?"

Observed behavior

  • 01:50 to 03:30 Scrolled the 24-item diet list twice, skipped it, came back after the plan showed meat.
  • 08:10 Tapped the plan header three times looking for the list. The list is in the profile tab.

My interpretation (kept separate)

  • The diet list is too long to scan on a phone; she skipped it and then hit the consequence.
  • The shopping list is in the wrong place for her mental model (09:45).

Snapshot

  1. Preference step is the slow step: 1:40 of the 4:10.
  2. Skipping preferences produces a wrong first plan, which costs trust.
  3. Shopping list not found from the plan screen.
  • Hypothesis: not met for her (4:10). Two of four participants so far over 3:00.
  • Surprise: she never noticed the search field on the diet list.
  • Themes: #preferences #navigation

Follow-ups

  • Send thank-you and 40 dollar gift card (@Lars) @due(2026-11-13)
  • Clip 09:45 for the design review (@Kemi) @due(2026-11-14)

3.Churn interview with a former customer

When it fits: Use this when a customer has already cancelled, the reason they gave in the exit survey is short and polite, and you need the decision behind it.

Churn interview with a former customerExample 3

Churn interviews Q4, P02, 2026-11-19

Participant: P02, cancelled accounts over 10 seats, operations lead at a 40-person architecture practice, 14 seats, cancelled after 7 months Interviewer / note-taker: Farah Haddad / none, recorded Session: churn, 30 min, recorded with consent: yes Study: [[Churn interviews Q4]] Hypothesis this session tests: mid-size accounts cancel because the per-seat price jumps at 15 seats.

Context (their words)

  • Exit survey answer: "Too expensive for our size."
  • Used the product for project timelines and client approvals.
  • A new CTO joined in July.

Quotes (verbatim, with timestamps)

  • 04:30 "Honestly the price was fine. It was the easiest box to tick."
  • 06:15 "Our new CTO standardized everything on Jira in August. We weren't asked."
  • 19:50 "The client approval screen was the one thing my team fought to keep. We export PDFs now."

Observed behavior

  • Got noticeably more animated describing the approval flow than anything else.

My interpretation (kept separate)

  • The exit survey reason was a polite one (04:30). The real driver was a top-down tool consolidation (06:15).
  • The approval flow had a champion who lost the argument. That is a product we could sell separately.

Snapshot

  1. Cancelled because of a new CTO's tool consolidation, not price.
  2. The team still misses client approvals and works around it with PDFs.
  3. No one at the account was asked before the switch.
  • Hypothesis: weakened because price was named as a convenience answer.
  • Surprise: a workaround still in use three months after cancelling.
  • Themes: #consolidation #approvals

Follow-ups

  • Send thank-you note and 100 dollar donation to her chosen charity (@Farah) @due(2026-11-20)
  • Check how many other churned accounts had a leadership change in the 90 days before cancelling (@Farah) @due(2026-11-26)

4.Concept test with a buyer and a user in the same call

When it fits: Use this when two people from one customer join the session, they want different things from the product, and the notes have to keep their answers apart.

Concept test with a buyer and a user in the same callExample 4

Fleet maintenance concept test, P06 and P06b, 2026-11-24

Participants: P06, fleet operations manager (buyer), and P06b, dispatcher (daily user), regional delivery company with 85 vans, recruited via sales Interviewer / note-taker: Ruth Okafor / Sam Delgado Session: concept test, 3 mockups, 50 min, recorded with consent: yes Study: [[Fleet maintenance concept]] Hypothesis this session tests: a predicted-breakdown score per van is what makes this worth buying.

Quotes (verbatim, with timestamps)

  • P06, 06:30 "The score is the reason I'd sign. I can take it to finance."
  • P06b, 07:10 "I wouldn't trust a score. I need to know which van is off the road tomorrow and what I swap in."
  • P06b, 21:40 "Mockup 2 is the one. The calendar with the gaps."
  • P06, 23:05 "Mockup 2 is fine but finance won't care about a calendar."

Observed behavior

  • P06b took control of the screen share for mockup 2 and started planning a real Tuesday.
  • P06 deferred to P06b on every daily-workflow question.

My interpretation (kept separate)

  • Buyer and user want different first screens: the score sells it, the calendar gets used.
  • If the dispatcher does not adopt it, the renewal is at risk regardless of the score.

Snapshot

  1. Buyer values the score for budget conversations.
  2. Dispatcher values the swap calendar and distrusts the score.
  3. Both chose mockup 2 for daily use.
  • Hypothesis: partly supported. The score sells, but it is not what gets used.
  • Surprise: dispatcher planned a real day in the mockup unprompted.
  • Themes: #buyer-vs-user #scheduling

Follow-ups

  • Thank both, confirm incentive went to each person, not the company (@Sam) @due(2026-11-25)
  • Run the next two concept tests with buyer and user in separate sessions (@Ruth) @due(2026-11-27)

5.Study synthesis across six interviews

When it fits: Use this after the last session in a round, when the team wants a recommendation and you need to show how many participants actually said each thing.

Study synthesis across six interviewsExample 5

Small-firm invoicing study: synthesis, 2026-11-28

Sessions: P01 to P06, bookkeeping firms under 10 staff, Nov 3 to Nov 21 Researchers: Owen Lindqvist, Bea Sato Original hypothesis: small firms chase late invoices by hand and would pay to automate reminders.

Themes (count of participants)

  • Reconciling partial payments is the real cost: 5 of 6. P03 "that's where my evenings go." P05 estimated 6 hours a month.
  • Chasing is a relationship decision, not a workload: 4 of 6. P01, P03, P04, P06 all said they choose not to chase some clients.
  • Reminders wanted: 1 of 6. P02 only, a firm with mostly corporate clients.
  • Bank feed errors: 2 of 6. Not enough signal yet.

What we no longer believe

  • That automated reminders are the wedge. One participant in six wants them.

Recommendation

  • Pause the reminders prototype. Spend the next round on split-payment matching with five new participants, three of them from firms with mostly retail clients.

Evidence links

  • Session notes P01 to P06, all linked from [[Small-firm invoicing study]]. Every count above can be checked against their snapshots.

Follow-ups

  • Share this note with product and design before Thursday's planning (@Owen) @due(2026-12-01)
  • Draft the guide for the split-payment round (@Bea) @due(2026-12-04)

What belongs in user interview notes

Most user interview templates focus on the script: the questions you will ask. The script matters, but the notes are what the team reads afterwards, and that is where most research loses its value. Each section of the template above exists to keep the evidence usable after the call.

  • Participant ID and segment. Who this is, in terms that matter for the decision (firm size, plan, role), without their name. Synthesis is counting by segment, so the segment has to be on every note.
  • The hypothesis. One sentence you could be wrong about. It tells you what to listen for and gives the snapshot something to judge.
  • Context in their words. What they do today and the last time they did the job you care about. Past behavior is the most reliable thing a participant can tell you.
  • Quotes with timestamps. Exact words, so nobody has to trust your paraphrase, and a timestamp so anyone can check the recording.
  • Observed behavior. What they did, separately from what they said. People say a flow is easy while scrolling past the same option twice.
  • Interpretation, in its own section. Your reading of the session, each line pointing at the evidence it comes from.
  • Snapshot. Three takeaways and a verdict on the hypothesis, written within 15 minutes.

Keep quotes and interpretation apart

Notes that blend what was said with what you concluded cannot be re-read. A teammate who sees "she doesn't care about reminders" cannot tell if that is a quote, an observation or your guess. Six sessions later, nobody can either, and the synthesis becomes a summary of the researcher's opinions.

Three sections fix this: Quotes, Observed behavior, My interpretation. Every interpretation line names the timestamp it rests on. When someone challenges a finding in the review, you can point at 08:15 instead of defending a memory.

From six interviews to one decision

Every guide mentions synthesis. Few say how to do it. A procedure that works for five to eight sessions:

  1. Write each snapshot the same day. The synthesis is built from snapshots, not from rewatching recordings.
  2. Tag themes as you go. A short tag per theme on each session note, added in the snapshot.
  3. Count participants per theme, not mentions. "5 of 6" is a finding. "Mentioned 14 times" usually means one talkative participant.
  4. Write what you no longer believe. It is the most useful line in a synthesis and the one most often skipped.
  5. End with a recommendation and a next round. The fifth example ends with what to stop, what to test next, and with whom.

Common mistakes

  • Asking about the future. "Would you pay for this?" produces polite yeses. Ask about the last time the problem happened.
  • Showing the concept too early. Once they have seen your idea, everything they say is about the idea.
  • One note-taker's summary as the only record. Without quotes and timestamps, nobody can check it.
  • Counting mentions instead of people. A single enthusiast can make a theme look universal.
  • No snapshot. The session is vivid for a day and vague in a week.

When to use a different template

Background reading and desk research belong in the research notes template. Once the synthesis has a recommendation, turn it into a PRD or a set of user stories that cite the sessions. If the question is about the market rather than the user, start with the competitor analysis template. And if the person across the table is a job candidate, the interview notes template is the one you want.

Customization tips

  • Use participant IDs, not names

    Write P03, not the person's name, in the title and throughout. Keep the name-to-ID mapping in one restricted place. Notes get shared with people who never needed to know who said what, and IDs make that safe.

  • Write the hypothesis you could be wrong about

    "Learn about invoicing" cannot be weakened by anything. "Small firms would pay to automate reminders" can. A falsifiable line at the top tells you what to listen for and makes the snapshot honest.

  • Switch to a task table for usability tests

    For usability sessions, add a numbered task list with completion time and pass or fail, as in the second example. Times across participants are the first thing a design review asks for.

  • Split the note for two participants

    When a buyer and a user join the same call, prefix every quote with their ID. Merged notes from a joint session hide exactly the disagreement you most need to see.

  • Keep a snapshot even if you keep a recording

    Recordings are the source; nobody rewatches six hours before planning. The three-line snapshot, written within 15 minutes, is what the synthesis is built from.

In the app

How to do this in Scribelet

  1. Open Desk Settings, then Templates, tap Add Template and paste the template above. Set the category to Research, add #user-interview as a default tag, and keep {{date}} so every session note is dated.

  2. Create one note per study, say [[Small-firm invoicing study]], and link it from every session. The study note's backlinks panel lists every session, which is your index when you sit down to synthesize.

  3. Tag themes inline as you write the snapshot, such as #reconciliation. Opening a tag shows every session where it came up, which is the count you need for the synthesis note.

  4. Ask the AI chat "what did participants say about split payments?" It answers from your session notes and cites the specific notes, so you can check every quote before it goes in a deck.

  5. Photograph the sticky notes from an affinity-mapping session and attach the photo to the synthesis note. Scribelet extracts the text, so the stickies become searchable alongside your notes.

Templates, template variables and AI generation are documented in Note templates.

Frequently asked questions

How many user interviews do I need?

For usability testing, five participants per round is a common rule of thumb; most serious problems show up by then. For discovery, keep going per segment until new sessions stop producing new themes, which is often six to eight. The synthesis example above stopped at six because the themes had repeated.

What questions should I ask in a user interview?

Ask about past behavior, not future intentions: "tell me about the last time you did X" gets real answers, "would you use X" gets polite ones. Follow up on specifics (what tool, how long, what happened next) and save any concept or prototype until the end so it does not shape what they tell you.

What is the difference between a user interview and a usability test?

A user interview explores someone's context, problems and decisions. A usability test watches them try tasks on a product or prototype. The notes differ: interviews lean on quotes, usability tests on observed behavior and task times. The template covers both; the second example shows the usability variant.

Should I record user interviews?

Yes, with explicit consent, and still take notes. The recording settles disputes about exact wording; the notes with timestamps are what make the recording usable, because they tell you where to look.

Is a customer interview template different from a user interview template?

Mostly the same structure. Customer interviews often include the buyer, so add a line for who signs and who uses, and keep their answers apart as the fourth example does. Churn and win-loss interviews are customer interviews too; the third example shows one.

How do I take notes and interview at the same time?

Ideally you do not: one person asks, one writes. If you are alone, record, note only timestamps and single words during the call, and fill in quotes and the snapshot right after, while you still remember what the words referred to.

Six interviews, one decision, every quote traceable

Save this user interview template in Scribelet, link each session to its study, and ask your notes what participants said before you write the recommendation. Encrypted, free to start.

Free plan, no credit card. See pricing

Research

Research Notes Template

Research notes go wrong in two ways: you cannot tell where a claim came from, or you cannot tell whether it is still true. This template ties every finding to a source and a confidence level, keeps observation apart from interpretation, and records when you last checked.

Product

PRD Template (Product Requirements Document)

A PRD (product requirements document) says what problem a release solves, for whom, how you will know it worked, and what it deliberately will not do. This template keeps it short enough to be read, and adds what most PRD templates leave out: a status, a decision log, and open questions with owners and dates.

Product

User Story Template with Acceptance Criteria

The format is one line: As a [role], I want [capability] so that [outcome]. The line is the easy part. This template adds what makes a story buildable: Given/When/Then acceptance criteria, edge cases, what is out of scope, and an INVEST check before it enters a sprint.

Product

Competitor Analysis Template

A competitor analysis is only useful if it changes a decision. This template starts from the question you need answered, compares three or four competitors with a source and date on every claim, and ends with decisions, owners and a review date. Copy it, or start from the example closest to your market.

Work

Interview Notes Template

Good interview notes record what the candidate said and did, rate it against the competency you were asked to assess, and end with one recommendation and one reason. Copy the interviewer template below, or start from the example closest to your round, including two for candidates preparing and debriefing.

Work

Decision Log Template

A decision log is a running record of what was decided, why, by whom, and what you expected to happen. This template adds the two fields most logs leave out: who disagreed, and a date to check whether the decision worked. Copy it for a team, or use the decision journal example for your own choices.

We use cookies for analytics to improve your experience. Learn more