research-synthesis

research-synthesis

Turn a stack of raw research — interview transcripts, usability notes, survey exports — into a synthesis document a team can actually act on: named themes, evidence-backed insights, and a prioritized set of opportunities.

When to use this

Trigger any time someone hands over a set of markdown transcripts, notes, or research exports and wants to know what they mean — whether or not they use the word "synthesis." If there's only one transcript, synthesis still applies — themes just won't have much prevalence data yet; say so in the output rather than forcing false patterns from a single data point. If the underlying research problem or the questions asked of users seem poorly defined, that's a different problem — flag it, but don't block on it.

Before synthesizing: read everything first

Read every transcript in full before writing anything. A theme only becomes a theme when it shows up in more than one place, and the only way to know that is to hold all the transcripts in mind at once — summarizing them one at a time and stitching the summaries together flattens patterns and loses the specific participant language that makes a synthesis credible.

If it's unclear which files to include (transcripts from multiple studies, interviews mixed with unrelated notes), ask before assuming scope.

What makes a good theme

A theme is a pattern that recurs across participants, not a single interesting quote. For each theme, say how many of how many participants raised it — "6 of 8 participants struggled with X" beats "users struggled with X." When prevalence is genuinely unclear (small sample, ambiguous mentions), say so rather than inventing a number.

Keep observations and interpretations visibly separate: "5 of 8 users clicked the wrong element first" is something that happened; "the layout is confusing" is a conclusion drawn from it. Both belong in the synthesis, but a reader must be able to tell which claims are direct evidence and which are your read on it.