# A user research repository — interview findings you can find again

Recipe No. 38, Work and teams. From The know.sh Cookbook: https://know.sh/cookbook/research-repository

- For: a UX researcher at a software company with two years of studies nobody can find
- You bring: your study plans, anonymised session notes, the readouts you presented, and the consent terms participants agreed to
- You get: a shelf per product area, a document per study with Insight and Evidence findings, and themes you can find again with Look up across every study
- Time: an evening to check each past study your assistant brings in, then an afternoon at the end of each new one
- Keep it: private; never on a public link

A product manager asks whether anyone has heard technicians complain about working without signal. You have: in a diary study last March, in four dispatcher interviews the year before, and in a usability test nobody remembers. The quotes are in three slide decks and a folder of session notes, and it takes an afternoon to find them, so usually nobody does, and the next study asks the same question again.

This recipe keeps the research where it can be found. Each product area gets a shelf, each study a document, and each observation an *Evidence* finding with an anonymised quote and a session reference, while the conclusions are *Insight* findings that link to the evidence behind them. Findings are titled with their theme first, so a search in Look up finds a theme across every study. Your assistant does the filing, study by study, from notes you have already anonymised; you check every quote in the editor. Look up finds a quote in seconds, and the same assistant reads across studies for patterns, citing each finding it relies on.

Recordings, transcripts and the key that links participant numbers to real people stay in your research tools, under their own access controls. What comes here is anonymised before it arrives.

## What you will use

- **Shelf**: A shelf per product area, *Scheduling*, *Invoicing* and *Technician app*, with the current list of theme names in its notes.
- **Research document**: A document per study; the overview gives the research question, method, participants by segment, dates and what consent covers.
- **Finding**: *Evidence* for each anonymised observation, *Insight* for each conclusion, *Question* for what the study could not answer.
- **The A–Z index**: Gathers the names and acronyms that recur (product names, *GPS*, *SMS*), with the studies they appear in.
- **Look up**: Find every quote on a subject across studies with ⌘K, the moment someone asks.
- **Highlights**: Highlight the strongest quote in each study; Look up lists your highlights in a group of their own.
- **Links between documents**: Each Insight links to the Evidence findings it rests on, including evidence from earlier studies.
- **Your AI assistant**: Files each study from your anonymised notes, then reads across every study for patterns, citing the findings it used; a local model through Ollama keeps the notes on your own machine while it works.
- **The editor**: Where you check each quote against the notes, retitle findings to the agreed theme names and mark the insights that mattered **Key**.

## Method

### 1. Check what consent allows before anything goes in

Read the consent terms for each study before you bring it in. They say where participants' data may be kept, who may see it and for how long. If they, or your company's policy on third-party tools and AI, do not cover your assistant's provider and a library that assistant reads, keep only synthesised insights here, without quotes, or keep the study out.

Participants appear only as numbers, P01 to P12. The key that links numbers to names and contact details stays in your research operations tool, never in know.sh.

### 2. Have your assistant file each study

Give your assistant one study's anonymised session notes and its plan, and ask it to file a document on the right product-area shelf, titled with the method and the month: *Invoice approval interviews — June 2026*. The title tells a reader, and Look up, what kind of evidence is inside.

Ask for the overview to give the research question, the method, the participants by segment ("nine office managers at companies of 20 to 200 staff"), the dates, where the recordings live, and a line on consent: "Anonymised quotes may be used internally until June 2028."

### 3. Check the Evidence findings and their quotes

Each observation should be an *Evidence* finding, titled with the theme first, then the observation: "Offline work: technicians write job notes on paper and type them up at night". Under the title comes the quote as a quotation, then a session reference line: "P07 · session 3 · 14:20", with the link to the clip in your research tool as the source. In the editor, check every quote word for word against the notes; an assistant will tidy speech into something nobody said.

Anonymise before your assistant sees the notes, not after. Remove names, employers, towns and anything else that could identify someone. An edited-out name stays in the finding's earlier revisions.

### 4. Write the Insights yourself

The conclusions are your judgement, so write or rewrite each *Insight* yourself, even if the assistant drafted one: what you now believe, how widely you saw it ("six of nine technicians"), and what it means for the product. Link it to each *Evidence* finding it rests on, by pasting the address or asking your assistant to add the links, including evidence from earlier studies. An insight with one piece of evidence is a hunch; say so.

File what the study could not answer as a *Question*: those are the next study's research questions. Mark the insights that changed a product decision as **Key**.

### 5. Let Look up become the theme map

Keep theme names consistent: write the current list in each shelf's notes (*Offline work*, *End-of-day batching*, *Approval delays*) and use them exactly. Look up (⌘K) searches every title and finding, so a theme used the same way in four studies comes back as one list.

Search each theme every few studies. Where two names mean the same thing, "No signal" and "Offline work", retitle the findings to one. Highlight the strongest quote in each study; the highlight shows in Look up and sets the finding's number in bold wherever the index lists it.

### 6. Answer questions with Look up

When a product manager asks "have we heard about this?", press ⌘K and type the word. **Look up** shows matching index terms, documents, findings and your highlights across every shelf, with a snippet of the text in each result. When the answer needs reading rather than finding, take the question to your assistant.

Send the product manager the quote, the participant number and the study, never the recording link unless they already have access to it.

### 7. Ask your assistant for patterns, then check every citation

Ask your assistant to read across the whole library: where do participants describe working without signal, in which studies, and how many participants does each pattern rest on? It answers with citations to the findings it used.

Open every cited finding. An assistant can count one participant twice, merge two different complaints into one pattern, or miss evidence phrased another way. When the pattern holds, write it up yourself as an *Insight* in a document called *Themes across studies*, linking the evidence from each study.

## Prompts to try

Your assistant, connected to know.sh (Claude, ChatGPT or a local model):

> Using know.sh, across every study in my library, where do participants describe working without signal? Group what you find by pattern, cite each Evidence finding, say how many distinct participants each pattern rests on, and flag anywhere you may be counting the same participant twice.

Your assistant, connected to know.sh (Claude, ChatGPT or a local model):

> Using know.sh, read the document Invoice approval interviews — June 2026 on my Invoicing shelf and find anything that could identify a participant: a personal name, an employer, a town, a job title unusual enough to be recognised. Leave a proposed note on each passage explaining why. Do not change the text.

Your assistant, connected to know.sh (Claude, ChatGPT or a local model):

> Using know.sh, list every Insight finding on the Scheduling shelf that links to fewer than two Evidence findings, and every Evidence finding that no Insight links to. Name each by document and number.

## Variations

- For stakeholders, write a separate readout document per study with the insights only, no quotes or session references, and share that one from a link if your consent terms allow it.
- Link your *Evidence* findings from the requirements in a [product requirements document](/cookbook/product-spec), so each requirement shows the research behind it.
- Doing academic research instead? A [literature review](/cookbook/literature-review) applies the same evidence-and-insight discipline to papers.
- The consent practice in an [oral history collection](/cookbook/oral-history) is a good model for studies where participants may be quoted by name.

## Where it falls short

- There are no recordings or transcripts here, and no way to bring them in. You paste the anonymised excerpts; the raw data stays in your research tool.
- There are no tags or filters by theme. Themes come from consistent titles and Look up; the index gathers only recurring names and acronyms.
- The repository is yours alone. Designers and product managers cannot search it; they ask you, or read a document you share.
- Your assistant’s patterns are leads. It can miss evidence phrased another way or count one participant twice, and smaller local models call tools less reliably; Revisions show everything it filed.

## A note on consent, anonymisation and AI

Participants agreed to specific uses of what they told you. Check the consent terms and your company's policy before any study goes to your assistant or into a library it reads, and keep out anything they do not cover. Anonymise before you paste: numbers instead of names, and no employers, places or details that could identify someone. Keep the key linking numbers to people in your research operations tool.

If a participant withdraws, delete the findings that quote them, and if your consent terms promise erasure, confirm with know.sh support what deletion removes before you promise it. Assistants can make mistakes; check that every finding they cite exists and says what they claim.

Indexed under: Research repository, User interviews, Anonymisation, Participant consent, Research themes, Insights, Session references.
