Research template

Research notes rot in documents because a document cannot tell you that six of the nine things you believe come from the same interview. This template separates a source from a finding and a finding from a theme, and links them, so a claim carries its evidence, a theme carries its weight, and the strongly held opinion resting on one enthusiastic conversation looks different from the one with nine sources behind it.

Sources logs everything you read, watched or ran: a type such as Interview, an author, a date, a reliability rating, and a formula counting the findings pulled from it. Findings holds one claim per row, linked twice: back to its source, up to its theme. Each row carries the statement itself (“approvals are the bottleneck, not entry”), a confidence rating, the supporting quote, and the date it was captured. Themes is one row per pattern, with a description, a status such as Confirmed, an owner, and two formulas that matter more than they look: total evidence, and distinct sources.

Six of the nine things you currently believe might come from the same enthusiastic interview, and no document can tell you that. That's the rot a better document can't fix. Separate a source from a finding and a finding from a theme, and it becomes countable; the two formulas on the theme row are the count. Nine pieces of evidence across five distinct sources is a different claim from nine across one, and the gap between a supported pattern and a memorable anecdote stops being a matter of tone and becomes a number.

Open it months from now: is it still useful? That's the only real test, and it's a question about context, not storage. Every finding keeps its quote, its source and its confidence rating on one row, so a claim gets re-read in the words it arrived in rather than trusted because someone once wrote it down. A finding that turns out to rest on one unusually keen customer shows up as exactly that: the thing a tidy summary document quietly hides.

The dashboard plots findings per theme, split by confidence and by source type, so a theme carried by one interview looks visibly different from one carried by five independent sources. Open it before a readout. It tells you which of the things you're about to say are actually supported and which are one conversation wearing a confident sentence.

“Which themes have the most findings behind them” is the ranking the dashboard already draws. “What did operations people specifically tell us” cuts the findings by where they came from. Before every readout, run the honesty check: “which findings rest on only one source.” And “summarise everything tagged to the approval bottleneck theme” walks the link from a theme to every finding attached to it and hands you back the quotes.

Interviewing across segments? Add a Participants table and findings become countable by segment as well as by source, which is what tells you whether a pattern belongs to enterprise buyers or to everybody. The same goes for a study round or a product area, even for the decision a finding fed into; the structure changes with the rows already in it, so nothing gets re-tagged by hand.

Product and UX researchers get the obvious use, but insight teams, analysts, and anyone running a literature review or a discovery phase with more notes than memory land here too. Loading it is one import: a CSV or XLSX of existing notes, or a connected Google Sheet, shaped as one row per claim rather than one row per document. Splitting an old write-up into findings is the work. It's also the point. That split is what makes the repository answerable later.