How Do You Build a Research Repository a Small Team Will Use?

How Do You Build a Research Repository a Small Team Will Actually Use?

Start with one searchable place, four tags, and a rule that every study adds three findings written as sentences. Most repositories fail because they were designed as archives. A small team needs a lookup tool, and a lookup tool is judged on whether someone can answer a question in two minutes.

We design product interfaces and marketing sites for B2B companies, and we see the same pattern. A team runs good research, writes good reports, and six months later nobody can find the finding that would have settled this week's argument.

Here is the smallest version that works, and how to grow it only when it earns the right.

What Is a Research Repository?

Nielsen Norman Group defines it as a central place where user-research artifacts and outputs are stored so that they can be accessed by others in the organization. That definition is deliberately broad, and the breadth is the problem.

A folder of PDFs meets that definition. So does a fully tagged insight database with linked video clips. The gap between them is enormous in effort and in usefulness.

The question is not whether to have a repository. You already have one, somewhere, badly. The question is how much structure is worth paying for.

Why Do Most Repositories Fail?

Because the cost of contributing falls on one person and the benefit falls on everyone else, later. That asymmetry kills systems quietly.

Nielsen Norman Group names the underlying tension directly: document libraries are easy to maintain but difficult to search, while insight databases make discovery easier but require significant time to populate and maintain. You are choosing which end of that trade to sit on.

For a team of under ten people running a handful of studies a year, we think sitting near the document library end and adding one small layer of structure is right. The elaborate version does not repay its cost at that scale.

What Are Teams Actually Using?

General tools, mostly. In Nielsen Norman Group's survey of 411 respondents, 43% used collaboration tools such as Confluence or SharePoint, 32% used specialised user-research platforms such as Dovetail or EnjoyHQ, and 14% used database tools such as Notion or Airtable.

That distribution is worth sitting with. The most common answer is the tool the company already had, not a purpose-built product.

We read that as permission rather than as a failure. If your team lives in Notion, build it in Notion. Adoption beats capability, and a tool people already have open has a large head start.

What Should Actually Go In It?

Findings first, artifacts second. The survey found the most commonly stored items are research reports, at 70% of respondents, followed by recordings, transcripts and notes at over 50%.

Reports are the right thing to store and the wrong thing to search. Nobody reads a forty page report to check whether users understood a pricing term. They want one sentence and a link to the evidence.

So store both, but make the finding the primary object. Each finding is a sentence stating what you learned, a confidence level, a date, and a link to the study it came from.

What Does a Good Finding Look Like?

A claim, not a topic. Write it as something that could be wrong. Users could not tell the difference between our two mid-tier plans is a finding. Pricing page feedback is a folder name.

Add the evidence strength inline. Six of eight participants, or one strongly held view from one customer. Those are both useful and they are not the same, and a repository that flattens them leads people to overclaim.

Include the date and do not update it. A finding from eighteen months ago about a screen you have since redesigned is not wrong. It is old, and the reader needs to see that to judge it.

How Many Tags Should You Have?

Four to start. Nielsen Norman Group's recommendations include starting simple with broad tagging systems rather than granular taxonomy, and we would take that further for small teams.

Our four are: the part of the product, the type of user, the stage of their journey, and the kind of finding, meaning whether it is a problem, a preference or a behaviour. That is enough to narrow any search to a readable number of items.

Resist adding a fifth for at least a year. Every tag you add is a decision every contributor has to make, and the failure mode of a rich taxonomy is that people tag inconsistently, which is worse than not tagging.

Who Owns It?

One named person, with a recurring half hour. Not a committee, not the whole design team, and not whoever ran the last study.

Nielsen Norman Group's implementation recommendations include gaining stakeholder buy-in before launch and putting onboarding and change-management plans in place to encourage adoption. On a small team, that translates to something simpler: one person whose job includes this, and a manager who asks about it.

The half hour is for tidying, not for entering. Contribution happens at the end of each study as part of the study. If the owner is doing the entering, the system has already failed.

How Do You Make It Worth Searching?

Use it in public. When a design decision comes up, look the answer up in front of people and paste the finding into the conversation. That does more for adoption than any onboarding session.

The second thing is to make the absence visible. When there is no finding, say so out loud, and log the question. A list of open questions is one of the most valuable things a small repository can hold, because it turns into your next research plan.

Searchability is also a tool requirement. Nielsen Norman Group's recommendations name searchability, flexible permissions and intuitive navigation as things to ensure. If your candidate tool cannot do full text search across findings, it is not a candidate.

Can AI Help With This?

With retrieval, yes. With judgement, no. Pointing a model at your transcripts and asking what participants said about onboarding is a genuinely good use of the technology, and it makes an unstructured pile more useful than it was.

What it does not do is decide what a finding is. Summarisation flattens confidence, and a summary that treats one comment and a consistent pattern as equally true is actively harmful in a repository.

Use it to find candidates for findings and have a person write the claim. That is the same split we described in building an internal AI knowledge base.

What Does the First Month Look Like?

Week one, pick the tool your team already uses and create one page with a table. Week two, back-fill findings from your three most recent studies, no more. Week three, run a study and add findings as part of finishing it. Week four, answer a real question from it in a meeting.

Do not back-fill everything. Old studies you never reference are not worth the hours, and a repository that launches with two hundred stale items feels like an archive rather than a tool.

And keep it connected to what you already do. If you are running small studies, the format in usability testing with five users produces findings in exactly the shape this system wants.

What Would We Tell a Team Starting Today?

Build the smallest thing, use it loudly, and let the friction tell you what to add. Every structure you add before you feel the need for it is a cost you will pay on every entry and a reason someone will skip it.

The measure of success is not how complete it is. It is whether somebody answered a question with it this month without asking the person who ran the study.

If you want help setting one up, or turning research you already have into decisions about your product or website, we are happy to talk it through. Find us at phoenix.studio.