Research repository for small teams: a lightweight template

A research repository for a small team does not need a ResearchOps programme or a specialised platform. Start with three linked layers:

1. a protected archive for recordings, transcripts, notes, and guides;
2. a one-page summary for each conversation;
3. a searchable evidence table that links every observation back to its source.

Use a small set of broad tags, assign one owner, and reserve a short weekly maintenance slot. That is enough to stop useful customer evidence disappearing into folders without creating a second job for the founder who collected it.

This guide gives you a copyable structure. The suggested eight tags and 20-minute weekly review are starting defaults, not research-backed thresholds. Change them when real use shows that your team needs something different.

Why small teams need a smaller research repository

Nielsen Norman Group defines a research repository as a central place where research artefacts and outputs are stored so people in an organisation can access them. It can reduce duplicated work, help teams track observations over time, and make themes easier to see across studies.

The catch is contribution cost.

NN/g describes the central trade-off as discoverability versus effort. A folder of reports is easy to maintain but hard to search for a specific finding. A database of individual insights is easier to search, but each entry takes time to create, tag, update, and retire.

That trade-off matters more when the repository owner also writes code, handles support, and recruits participants.

The available surveys are not specific to two-person startups, so do not treat their percentages as a startup benchmark. They still reveal the operational problem. In a 2021 survey of 353 UX professionals, 46% said their organisation had no dedicated ResearchOps person, 39% reported a repository, and only 9% reported a system for tracking what happened to research findings.

A later NN/g survey of more than 400 UX and ResearchOps professionals found that 29% of repositories had no owner. Nineteen per cent had poor adoption, 11% were stagnant or forgotten, and only 9% were described as mature and thriving.

The lesson for a small team is simple: build the smallest system you will continue to use.

The three-layer research repository template

The layers solve different problems. Do not force one artefact to do all three jobs.

Layer 1: keep a protected source archive

Create one folder or record per conversation. Use a predictable name such as:

2026-07-29 — P-014 — onboarding

Store the recording or transcript, raw notes, and the guide used for that session. If consent or participant-contact records must be retained, link to their restricted location instead of copying them into a widely shared research folder.

Keep source files stable so later interpretations can be checked against what the participant actually said. “Stable” does not mean “keep forever.” Define who can access the files and when they should be reviewed or deleted.

The European Commission’s GDPR guidance says personal data should be limited to what is necessary, kept no longer than needed, and accessible only to people who need it. Your repository should implement those rules from the first interview, not after the folder has filled with names, recordings, and sensitive stories.

For a practical capture workflow, use Maren’s guide to taking notes in a user interview.

Layer 2: create one interview snapshot

A transcript preserves detail, but it is a poor index. Create a one-page summary that lets you understand the conversation without rereading every line.

Teresa Torres’s Interview Snapshot includes participant context, a memorable quote, opportunities, other notable observations, and an experience map of the story. Teams familiar with the format can create one collaboratively in 15–20 minutes. Torres explicitly notes that beginners may need longer.

For a tiny team, this reduced version is enough:

Participant code:
Relevant segment and role:
Research question:
Specific story or event:
What happened:
Why it happened:
Current workaround:
One memorable quote:
Contradictions or uncertainty:
Follow-up needed:
Source link:

Use the participant code in the shared snapshot. Keep the mapping between that code and the person’s identity in a more restricted system when you genuinely need it.

The snapshot is not a final finding. It is your interpretation of one conversation. Keep uncertainty visible, especially when the participant was speculating, recalling an old event, or describing behaviour you could not observe.

Layer 3: maintain a searchable evidence table

The evidence table is where you compare conversations. Each row should describe one traceable observation, not an entire interview and not a roadmap decision.

Use these columns:

Here is an explicitly hypothetical row:

Compare that with “P-014 wants better reporting.” The shorter version loses the event, cause, segment, and source. It also turns an observation into a feature request.

Future intentions can still be useful, but label them accurately. “I would pay for this” is evidence of a stated intention, not proof of a future purchase. Maren’s guide to The Mom Test for founders explains why recent, specific behaviour usually deserves more weight than predictions.

When several rows appear to support the same pattern, do not silently merge them into a fact. Create a synthesis note that links to the supporting and contradicting rows. The full guide to synthesising user interviews into themes shows how to keep patterns traceable.

Start with eight tags, then let use correct you

There is no authoritative rule that a small repository needs exactly eight tags. Eight is a useful constraint because it forces you to begin broadly.

For a B2B SaaS product, a starting set might be:

signup ·activation ·daily-use ·reporting ·integration ·trust ·pricing ·support

Choose tags that match the questions your team repeatedly asks. A product with buyers, administrators, and end users may need role tags. A product organised around a journey may need stage tags. Do not mix five overlapping taxonomies on day one.

NN/g recommends starting with a few broad tags and iterating as the repository grows. Its repository-failure research also warns that an unplanned taxonomy becomes hard to repair after large volumes of data accumulate.

Use three working rules:

1. Apply no more than three tags to a row.
2. Record proposed new tags instead of creating them during entry.
3. Review proposals on a regular cadence and merge synonyms.

Tags should improve retrieval. If nobody searches or filters by a tag, it probably does not earn its maintenance cost.

A weekly routine that can survive a busy sprint

Treat this as a pilot schedule:

After each conversation: file the source materials and draft the snapshot while the story is still fresh.

Once a week for 20 minutes: add the week’s strongest observations to the evidence table, check their source links, and update statuses affected by a recent decision.

Once a quarter for 45–60 minutes: merge duplicate tags, retire obsolete entries, review access, and check whether your retention schedule requires deletion. Use affinity mapping when clustering a larger batch, but keep every cluster linked to participant-level evidence.

Twenty minutes is a calendar commitment, not a promise that every team can process every interview in that time. If the queue grows each week, reduce what you capture, add another owner, or move the work closer to the interview workflow.

Ownership matters. NN/g found that repositories without an owner were more likely to become disorganised or forgotten. Put one person’s name next to the routine even if several people contribute.

Choose the tool after you define the queries

Do not start with a vendor comparison. Start with three questions you expect the repository to answer:

• What have administrators said about onboarding in the past six months?
• Which pricing observations are based on behaviour rather than stated intention?
• What evidence supported the reporting change, and what happened after release?

Then test whether your current tool can answer them.

For a small repository, the minimum useful capabilities are:

• full-text search;
• filters or tags;
• links to exact source evidence;
• appropriate access controls;
• export in a usable format;
• enough structure to update or retire findings.

A spreadsheet, database tool, or existing documentation system may be sufficient. Familiarity lowers the contribution barrier, but convenience is not enough if search is weak or participant data is exposed too broadly.

NN/g’s 2024 survey found that collaboration software was the most common repository tool type but received a median satisfaction score of 3 out of 5, compared with 4 out of 5 for research platforms and database tools. That does not prove that a small team needs specialist software. It does show that “we already have it” is not a complete tool-selection criterion.

Common repository mistakes

Treating a folder as the finished system

A central folder solves storage. It does not automatically solve retrieval, comparison, or decision tracking. Add the snapshot and evidence layers only when they answer a question the folder cannot.

Removing context to make entries tidy

An isolated quote can support several interpretations. Keep the participant segment, story, evidence type, and source link attached.

Counting mentions as prevalence

Five rows do not mean that half your market has a problem. Qualitative interviews can show that a problem exists and explain how it works. Prevalence requires a sample and method designed to estimate it.

Turning findings into a wishlist

Store the situation and its cause before storing a solution. “Needs CSV export” closes the question too early. “Rebuilds the client report because each audience needs a different view” leaves room for several possible fixes.

Keeping personal data by default

Do not make names, contact details, or full recordings visible simply because the tool allows it. Separate identity from the shared evidence where practical, restrict access, and set review or deletion dates.

Migrating everything before the workflow works

Test the template on recent, decision-relevant research. NN/g recommends starting simple rather than importing an entire archive at once. Migrate older work only when someone needs it.

When a small team should upgrade its repository

Consider a purpose-built platform or a more formal workflow when:

• several people contribute and use different naming conventions;
• permissions are difficult to manage;
• searches return too much material to review;
• clips, transcripts, and findings need to be linked at scale;
• teams repeatedly ask for research that already exists;
• repository maintenance consistently exceeds the time budget.

There is no universal row count or company size that triggers an upgrade. Upgrade when a recurring retrieval, governance, or contribution problem is clear enough to evaluate tools against.

How Maren fits into the repository

Maren provides searchable transcripts, per-interview summaries, cross-interview synthesis, project workspaces, and full export for research run in Maren.

Those outputs map naturally to this template:

• transcripts are layer 1 source material;
• individual summaries help with layer 2;
• synthesis reports and their supporting conversations inform layer 3.

Human judgement still matters. Review the source conversation before turning a summary into a durable finding, preserve contradictory evidence, and decide which findings affect the product.

If your team also learns from live interviews, support calls, sales notes, or usability tests, keep a broader index that links those sources together. A useful repository should follow the research question, not the boundaries of one tool.

Frequently asked questions

What is the best research repository for a small team?

The best starting repository is the simplest access-controlled tool that can search, filter, link to source evidence, and export your data. Define the questions it must answer before comparing products.

Should every interview become an atomic research nugget?

No. Preserve every source you are entitled to retain, create a per-interview snapshot, and add only decision-relevant observations to the shared evidence table. Keep each observation linked to its context.

How many tags should a research repository have?

There is no universal number. Start with a small, broad set. Eight is a practical first constraint for many product teams, then add, merge, or remove tags based on real retrieval needs.

How often should a research repository be updated?

Capture source material and a snapshot soon after each interview. Review the cross-interview evidence table on a regular schedule your team can sustain. Weekly is a useful starting cadence for teams doing continuous research.

The short version

Build the habit before you build the system:

1. Preserve the source with appropriate access and retention.
2. Summarise each interview without erasing its uncertainty.
3. Index only traceable, decision-relevant observations.
4. Start with broad tags.
5. Review the table every week.
6. Link findings to actions, contradictions, and source evidence.

A small research repository succeeds when it helps you answer an old question without repeating the research. If it takes more effort to feed than it saves, simplify it.