Your Research Repository Doesn't Work. You Just Don't Want to Admit It Yet.

Somewhere right now a researcher is tagging a study in Dovetail with seventeen metadata fields and telling themselves this is infrastructure.

It is not infrastructure. It is hope with a color-coded taxonomy.

The research repository has become the UX industry's version of the gym membership. Everyone gets one. Everyone feels good about getting one. The first two weeks are genuinely exciting. And then the specific combination of friction, competing priorities, and the quiet realization that this is more work than anyone accounted for causes the whole thing to slowly stop happening. The repository does not get deleted. It just stops growing. It becomes a monument to the quarter when the team finally got serious about knowledge management, preserved in amber, increasingly out of date, still linked in the onboarding doc that nobody reads.

And then a year later, someone new joins the team and proposes building a research repository. And the cycle begins again.

I have watched this happen more times than I can count. The field has watched this happen more times than it can count. And yet the repository remains the canonical answer to "how do we make research stick," which tells you something interesting about how much the field is willing to sit with an uncomfortable truth versus how much it wants to feel like it is making progress.

The Repository Industrial Complex

Here is the uncomfortable part. The research repository, as an idea, has a lot of stakeholders who benefit from you believing in it.

The tools benefit. Dovetail, EnjoyHQ, Aurelius, and a dozen others are built on the premise that what your team needs is a better place to put things. They are not wrong that your current place to put things is bad. They are very invested in you not noticing that a better place to put things is still just a place to put things.

The ResearchOps community, which I say with genuine respect for the people in it, has built a significant amount of its professional identity around the repository as a deliverable. Setting up the taxonomy, getting the tagging right, migrating the old studies: these are real skills and real work. They are also, if we are being honest, much easier to point to as evidence of progress than the harder question of whether any of it is actually changing how decisions get made.

And researchers themselves benefit from the repository as a story. It sounds strategic. It sounds like you are building something that lasts. It is a much more satisfying narrative than "we run studies and then present them to stakeholders who nod and then largely continue doing what they were going to do anyway," which is the actual situation at most organizations and which nobody is putting in their end of year review.

The repository feels like the solution. That feeling is doing a lot of work that the repository itself is not doing.

What Actually Happens When You Build One

Nielsen Norman Group surveyed over 400 UX and ResearchOps professionals about their repositories and the numbers are, charitably, a disaster. Only 9% reported having repositories that were mature and thriving. Eleven percent described theirs as stagnant or forgotten. Almost a fifth said adoption was poor. The vast majority were stuck in what the report diplomatically calls "early stages of growth," which is a lovely way of saying "we built it and not enough people are using it."

These are not teams that did it wrong. These are teams that did it the way you are supposed to do it and still ended up with a very tidy graveyard.

The reasons are not mysterious if you are willing to look at them directly. Repositories require contributors to do extra work at the end of a project, which is exactly the moment when everyone is most exhausted and most eager to move on to the next thing. They require a tagging taxonomy that is consistent enough to be useful, which requires governance, which requires an owner, and 29% of repositories have no owner at all. They require stakeholders to change their behavior and go looking for evidence in a new place rather than just asking a researcher, which turns out to be a very high bar for people who already have seventeen other things on their plate.

And they require the fundamental premise to be true: that the problem is storage. That if you just had a better place to put things, the things would get used.

That premise is wrong. And it is the thing nobody wants to say out loud.

The Actual Problem Is Not Storage. It Is Retrieval.

Here is the test that exposes the real problem. It is not "can someone find this study if they look for it." It is "will this evidence show up in the places where decisions are being made without a researcher personally carrying it there."

Almost every repository fails that test. Not because the search functionality is bad, though it often is. Because the repository exists as a destination, separate from the places where decisions actually happen. It requires a field trip. And the people who most need to engage with the research, the product managers, the designers, the executives who are about to make a call that your team already has evidence on, are not taking that field trip. They are in a meeting, making the call, operating on their priors and whatever the loudest person in the room is saying.

Your study is in the repository. The decision is happening without it. The repository did not fail because it was badly organized. It failed because the problem was never about organization in the first place.

The problem is that research evidence does not compound in most organizations. Every new planning cycle, every new stakeholder, every new VP of Product who just joined with strong opinions about users starts essentially from zero. The institutional knowledge your team has been carefully building does not automatically show up in the places where it would change things. It sits somewhere accessible in theory and invisible in practice, and the researcher who built it has to personally intervene every single time to bridge the gap between "we know this" and "this is informing a decision."

That is not a storage problem. That is an architecture problem. And building a better repository is not architecture. It is furniture rearrangement.

What Would Actually Work

I want to be careful here because this is the part where most articles give you a framework with four steps and a diagram and you feel briefly hopeful before returning to your Dovetail instance.

So let me just say what the actual shift is, because it is conceptually simple even if it is organizationally hard.

Evidence needs to stop living in a research tool and start living in the places where decisions happen. Not linked from those places. Not accessible via single sign-on from those places. Actually present, woven into the surfaces where work gets done and choices get made. If your organization makes product decisions in Notion, the research needs to be in Notion in a form that someone can encounter without having to go looking for it. If decisions happen in Confluence, same answer. The goal is not "findable if you go looking." The goal is "present when you are not looking but should be encountering it anyway."

The unit of knowledge also needs to change. A study is too big to be reused. A forty-slide deck with an executive summary and a methodology appendix is not a piece of evidence that compounds over time. It is a snapshot that gets cited once and then slowly becomes historical artifact. What compounds is smaller: a single finding, clearly stated, with the source attached, that can be pulled into a product brief or a planning doc or a design review without requiring someone to reconstruct the full context of a twelve-week project. This is not a new idea. It is just an idea that requires more discipline than making a nice Dovetail workspace and tagging everything with the product area.

And someone has to own this actively, not as a side project, not as twenty percent of a researcher's time, but as a real role with real accountability for whether the knowledge is actually being used. Without that, you are not building infrastructure. You are building something with a countdown timer and pretending otherwise.

The Thing Nobody Wants to Hear

If you have a repository that is not working, the answer is probably not to fix the repository. The answer is to ask whether the repository was ever the right solution to the actual problem, and then to sit with the possibility that it was not, and that the six months you spent building it was six months spent solving the wrong thing.

That is a hard conversation to have. It is especially hard when you have presented the repository to leadership as evidence that your team is getting serious about knowledge management, when you have colleagues who contributed to it and feel invested in it, when the alternative to the repository is a problem that is harder to solve and requires buy-in you might not have.

But the alternative to having that conversation is what the field is currently doing: continuing to build repositories that do not work, explaining the failure as an adoption problem rather than a premise problem, and starting over with a new tool that will also not work for the same reasons, slightly better organized.

The repository is not going to save you. It never was. The sooner you stop expecting it to, the sooner you can start working on the thing that actually matters, which is making evidence unavoidable rather than accessible.

Those are not the same thing. The field has spent years conflating them.

👉 Subscribe for the UXR takes nobody wants to post, but everyone needs to read. Weekly essays, no nonsense.