Research Repository: Keeping Findings From Getting Lost

What to store in a research repository, how to tag and search it, who maintains it, and why most repositories end up abandoned, according to NN/g.

info Quick Definition
A research repository is a central system for storing, tagging, searching, and sharing what a team learns from users: recordings, transcripts, quotes, insights, and reports. It exists so that a finding can be useful more than once.

What problem does it solve?

Most teams research more than they remember. A study ends with a report in a folder, a few slides in a meeting, and a finding nobody reads again. Six months later, another team starts the same research, and the knowledge was already available.

NN/g defines it as a central place where user-research artifacts and outputs are stored so other people in the organization can access them. Its value is not in storage, but in others finding and reusing what they need.

Why does this matter for a junior designer?

Because every study you run leaves material others could reuse. If each interview sits in a document with a different name, the work becomes invisible. A junior who proposes a naming convention, a one-page summary per study, or a shared tag is already contributing to the team’s memory.

A repository also forces you to think about what really matters in research: the finding, the evidence behind it, and how confident the team can be in it.

What is worth storing?

In Research Repositories 101, NN/g reports a survey of 411 professionals on what their repositories store. The results show a clear pattern:

  • Reports: stored by 70%.
  • Recordings, transcripts, notes, and insights: more than half.
  • Clips and study materials (plans, screeners): a third to a half.
  • Participant information and consent forms: less than a third.

That last figure is the one most worth reviewing. Storing a recording without its consent record can be a legal and ethical problem, and without participant data it is hard to contact the same person again. A healthy repository stores the finding, the evidence behind it, and the basis for using that evidence.

How do you organize it?

NN/g distinguishes two models. Document libraries are easy to contribute to and maintain, because each study is uploaded as one block, but specific insights are hard to find. Insight bases make specific findings easy to find, but they lack context, take time to contribute to, and need upkeep: updating, refining, or retiring insights. A hybrid, where the insight base links to the folder of the study it came from, is possible and is often the practical choice.

For tagging, NN/g recommends:

  1. Start with a few broad tags. A small taxonomy is easier to learn and to change.
  2. Avoid over-granular tags and expect to iterate.
  3. Test the structure with tree testing or card sorting, as you would test a product’s information architecture, to validate labels and folders.
  4. Allow search by keywords such as user group, product, or feature.

To get started, NN/g proposes four steps: gain buy-in (with expected return if you need budget), do discovery research before choosing tools or structure, start simple and migrate the most useful content first, and plan onboarding and change management, because change aversion is common. It also lists features that help adoption: easy access, flexible permissions (it should not be public), clear navigation, and strong search.

For the logic behind these decisions, the article on information architecture covers principles that apply here too.

Who maintains it?

This is the most neglected part. NN/g says creating and maintaining a repository is often a ResearchOps responsibility, and that insights need updating, refining, or retiring. In practice, though, the owner is rarely that profile, as the next section shows.

A three-year-old finding about a flow that no longer exists is not an asset: it is a risk, because someone may take it as current truth. That is why a repository needs a review cadence, even a small one. For the role of that function in a team, see ResearchOps.

Why do repositories fail?

In Why Research Repositories Fail, NN/g analyzes a survey of more than 400 UX and ReOps professionals, with follow-up interviews. Some findings:

  • Few thrive. Only 9% had a mature, thriving repository, and 11% said theirs was stagnant or forgotten. Fewer than half reported good adoption, and 19% rated it poor.
  • No owner. 29% had no owner, and only 8% had a ResearchOps practitioner as owner.
  • Four reasons for failure. Very low UX maturity, frustration with tools (23% were dissatisfied with theirs), no owner, and too much work to contribute. NN/g does not rank them by frequency.
  • Wrong tool. Generic collaboration software such as SharePoint or Confluence had a median satisfaction of 3 out of 5, against 4 for research platforms and database tools. The difference was statistically significant.

NN/g’s recommendations: set tagging rules and structure at the start, because they are hard to change once content piles up; document the taxonomy and share it with contributors; keep it simple; and schedule a regular cadence for governance and maintenance. That few thrive does not make a repository impossible: it shows that maintenance is the hard part.

When should you NOT set up a repository?

  • Without clear research goals. An empty repository, or one full of things nobody looks at, is not useful. That is why NN/g recommends discovery research before choosing tools or structure.
  • If nobody will maintain it. Without an owner, a shared folder with a simple format beats a complex system nobody keeps up.
  • If the study is so small that a one-page summary per study is enough.

Example

Illustrative example: a logistics company has three teams researching its driver app. One team has just found that drivers do not understand the delay notification.

  • Before: the finding sits in a 40-page report in another team’s folder. Nobody finds it.
  • After: the team writes a one-page card with the question, the participants (with no personal data), the finding, the evidence, and the tag “notifications”. It goes into the repository.
  • Maintenance: six months later, the notifications team reviews the cards under its tag, marks one as superseded by a redesign, and retires it.

A one-page card does more for the team than a perfect report nobody opens. If you want to work with synthesis of these cards, the article on AI interview synthesis shows what can be automated and what should be reviewed by hand.

Common mistakes

  • Uploading research after the fact, instead of during analysis.
  • Storing recordings without consent or participant data.
  • Tagging with too much detail from day one.
  • Buying a repository before defining how findings are stored.
  • Letting old insights stand as current truth.
  • Not assigning an owner with time to maintain it.

Sources

Frequently asked questions

What is a research repository?
It is a central system for storing, tagging, searching, and sharing research artifacts, such as recordings, transcripts, quotes, insights, and reports. Its purpose is to make findings reusable.
What types of research repository are there?
Nielsen Norman Group distinguishes two models: document libraries, easy to feed but poor for finding specific insights, and insight bases, easy to search but with more work to contribute to and maintain. A hybrid, where an insight base links to each study’s folder, is a middle ground.
How should you tag a research repository?
NN/g recommends starting with a few broad tags, setting tagging rules from the start, and validating labels and structure with tree testing or card sorting.
Who should own a research repository?
Someone with explicit responsibility. NN/g says creating and maintaining the repository is often a ResearchOps responsibility, yet in its survey only 8% had a ResearchOps practitioner as owner and 29% had no owner.
Why do research repositories fail?
In an NN/g survey of more than 400 professionals, four reasons stand out: very low UX maturity, frustration with repository tools, no owner, and too much work to contribute.