Karthik Menon

Synthesise Customer Interview Notes Into Themes With Quotes

Turn raw interview notes into evidence-backed themes with participant counts, verbatim quotes, contradictions and what each theme justifies.

At a glance

Best for: Product managers, UX researchers and founders with a stack of interview notes who need honest themes before a roadmap or design decision.
Tested on: Claude · Opus 5.5
You fill in: research_questionnotes
You get: Themes One mistake involving money ends trust (2 of 6: P1, P4) P4: "I don't trust it with money now." P1: "The client paid through a link I didn't… (full result below)

Prompt

Synthesise these interview notes into themes I can act on. Stay close to what people actually said.

Research question: {{research_question}}
Notes (one block per participant, labelled P1, P2...): {{notes}}

1. Themes: 3-5, each with

- a name that states a finding ("Owners distrust auto-categorisation"), not a topic ("Categorisation");
- how many participants support it (e.g. 4 of 6) and which ones;
- 1-2 verbatim quotes with participant labels, using only exact wording from the notes;
- any participant who contradicts it.

1. Surprises: anything that goes against what the research question assumes.

1. Weak signals: things only one person said that might matter, marked n=1.

1. Implications: for each theme, one decision it supports and one it doesn't justify yet.

Rules: don't count a participant twice for the same theme. Don't merge themes to make them look bigger. If a quote is paraphrased in the notes rather than verbatim, say so. Don't infer emotions people didn't express.

Fill in

{{research_question}}: The question the interviews set out to answere.g. Why do freelance designers stop using our invoicing app within a month?
{{notes}}: Interview notes, one labelled block per participante.g. P1 (brand designer): set up account, sent one invoice...

Example input

research_question: Why do freelance designers who sign up for our invoicing app stop using it within the first month?
notes:
P1 (brand designer, 3 years freelance): Set up account, sent one invoice. "The client paid through a link I didn't recognise and emailed me asking if it was a scam." Went back to sending PDFs from Word.
P2 (illustrator): Still uses the app, but only for time tracking. "Invoicing I only do once a month, so I forget the app exists." Would like a reminder on the 1st.
P3 (UX contractor, works through agencies): Agencies require invoices through their own portals. "I literally can't use your invoices for 80% of my income."
P4 (web designer): Stopped after the import failed. Imported 40 clients from a spreadsheet; about half came in with the wrong currency (EUR shown as GBP). "I don't trust it with money now."
P5 (motion designer): Still uses it, likes payment links. "Got paid in two days instead of two weeks." Said the price is fine.
P6 (brand designer): Left because the invoice template "looks like everyone else's". Wanted custom fonts: "my invoice is part of my brand". Also mentioned forgetting to log in between invoices.

3150

Generated Outputs (1)

2 hours ago

Claude

Opus 5.5

2 hours ago

Generated Output

Themes

1. One mistake involving money ends trust (2 of 6: P1, P4)

• P4: "I don't trust it with money now."

• P1: "The client paid through a link I didn't recognise and emailed me asking if it was a scam."

• Contradicts: P5 had a good experience with payment links (see Surprises).

2. Monthly invoicing means people forget the app exists (2 of 6: P2, P6)

• P2: "Invoicing I only do once a month, so I forget the app exists."

• P6 said they forgot to log in between invoices. This is a paraphrase in the notes, not a direct quote.

3. Some designers can't choose their invoice format (1 of 6: P3)

• P3: "I literally can't use your invoices for 80% of my income."

• I've kept this separate from P6's branding complaint. They're different problems: P3 is blocked by agencies' rules, while P6 is unhappy with the design.

Surprises

• Payment links are both the best and worst experience. For P5 they meant "Got paid in two days instead of two weeks". For P1 they prompted a client to ask whether it was a scam. What makes the difference may be whether the client recognises the link.

• Not everyone who "stopped" has left. P2 still uses the app, but for time tracking, not invoicing.

• Nobody gave price as a reason. P5 said it was fine.

Weak signals (n=1)

• P3: agency contractors may be a segment the product can never serve. If it's common, that's a question for targeting, not a feature request.

• P6: brand designers want custom fonts, saying "my invoice is part of my brand".

• P4: the import problem was specific (currency). Check whether it's a bug that affects others.

Implications

| Theme | Supports | Doesn't justify yet |
|---|---|---|
| 1. Trust breaks on money errors | Fixing the currency import bug; showing the business name clearly on payment pages | A full trust and security redesign based on 2 people |
| 2. Forgotten between invoices | Testing an opt-in reminder on the 1st of the month | Building daily engagement features |
| 3. Format dictated by others | Asking at sign-up whether users invoice through agencies | Building integrations with agency portals |

Why it works

Theme names that state a finding stop the vague headings ("Onboarding", "Trust") that make synthesis useless. Participant counts with labels and the no double-counting rule keep a theme from looking bigger than it is, which is critical with only 6 interviews. Verbatim quotes only prevents the model tidying people's words into what you hoped they'd say. Weak signals at n=1 keep important one-off comments without inflating them. The "doesn't justify yet" half of each implication is a check against overreacting to small samples.

When not to use it

It depends entirely on your notes: if they're already your interpretation rather than what people said, the themes will inherit your bias. Record and transcribe interviews where you can. Don't paste identifiable participant details into a chat tool without consent. For large studies (30+ interviews), use proper coding in a research tool.

Comments (0)

No comments yet. Be the first to share your thoughts!