Research Repository

A research repository is a searchable store of what research has found, with the evidence attached. Its purpose is retrieval: a question asked today should be answerable from work the team already did.

Without one, findings live in documents named after the study that produced them. That organisation serves the person who ran it and nobody else, because the next question arrives phrased by subject, not by project.

Organise by subject, not by study

This is the decision that determines whether the thing gets used.

Somebody asking what is known about the invitation flow should not have to remember it surfaced in March's onboarding research. The study is one attribute of a finding, alongside the product area, the user role, the date and the method.

The practical form is a tag scheme agreed in advance and applied consistently: area, role, method, date, and confidence. Consistency matters more than sophistication; a simple scheme applied the same way every time beats an elaborate one that drifts.

What each entry should carry

The finding, in one sentence. Stated so somebody can disagree with it.

The evidence. A quote, a clip, a number. An entry without evidence is an opinion with a date on it.

Who and how many. Four of six participants in one role reads very differently from one person in another.

When, and against what version. Findings expire. A conclusion about a flow that has since been redesigned is history, and should be visible as history rather than as current knowledge.

What was decided. Including what was considered and rejected, with the reason. This is the part most repositories omit and the part that prevents the same rejected idea being rediscovered annually.

Why they fail

Almost never for technical reasons.

Nobody owns it. Tagging drifts, two names appear for the same concept, search stops returning what it should, and confidence collapses.

Everything goes in. Raw transcripts and full recordings deposited without synthesis turn the store into an archive. Archives are worth keeping; they are not repositories, because nobody reads them to answer a question.

Contribution is slower than not contributing. If filing a finding takes half an hour, findings stay in the researcher's document.

No expiry. Old findings sit alongside current ones with nothing marking the difference, so the store gradually becomes untrustworthy.

The smaller version that works

Most teams do not need a platform. They need a habit.

A single document store, one page per finding, a short agreed tag list, and one person who tidies it monthly will outperform any tool without those things. Start there, and let the volume of findings justify software rather than the other way round.

The one rule worth enforcing from day one: every finding carries its evidence. A repository of unsupported claims is worse than no repository, because it lends the authority of a system to things nobody can check.

Making contribution cheaper than skipping it

Repositories die from friction, so the design question is how little work a finding costs to file.

One page, five fields. Finding, evidence, who, when, decision. Anything longer gets deferred to a quieter week that never arrives.

File during synthesis, not after. The moment the team agrees a finding, it goes in. Writing up a week later means reconstructing from notes and competing with whatever arrived since.

Let the entry be the deliverable. If the repository page is also what gets shared with stakeholders, filing stops being extra work and becomes the work.

Review monthly, briefly. Half an hour to merge duplicates, retag drift and mark superseded findings. Skipped for two quarters, this is what turns a repository into an archive.

In practice

A team is asked for the third time in two years whether customers want a mobile app.

The first two answers were researched properly. Both concluded the same thing: customers want notifications and a way to approve something quickly, and describe that as "an app" because it is the nearest available word. Neither finding could be located, because the first lived in a deck called Q3 Discovery and the second in an interview document named after the participant.

The third round of research repeats work that had already been done twice, at a cost far exceeding what filing it would have taken.

What the repository needed to contain was one page, tagged mobile and notifications, holding one sentence, three quotes and a note that a native app had been considered and rejected, with the reason.

Where teams get it wrong

• Filing by study. Findings arrive by subject and cannot be found by project.
• No evidence attached. Claims with a system's authority and nothing behind them.
• Everything deposited, nothing synthesised. An archive wearing a repository's name.
• No owner. Tagging drifts and search quietly stops working.
• Nothing marked stale. Old conclusions read as current ones.