Building a Research Repository Turned Us Into Librarians

We built a research repository to make insights accessible. Instead, we created a full-time librarian job nobody wanted.

User feedback lives everywhere today. It pours in through in-depth interviews, quarterly surveys, and support tickets. To pull those scattered threads together and use them to influence a product roadmap is a full-time job in itself. Naturally, us researchers look for a fix, but then the operational slide begins, and we end up maintaining a digital library instead of actually running research.

I am seeing more and more brilliant researchers feel entirely defeated by this loop, openly asking questions like "What is even the point of being a UX researcher anymore?", when their days are consumed by filing data rather than uncovering insights.

This article is not a traditional step-by-step guide on how to build a research repository. If you want a checklist on how to structure nested folders or enforce naming conventions, you will not find it here. Instead, we need to talk about the central thesis behind this frustration: the problem with most research repositories is that they were designed around the wrong goal entirely.

What we hoped research repositories would help us solve 

Most research teams decide to build repositories for the same reason – their company’s feedback is spread across tens of sources. Valuable insights often stay buried until someone stumbles across them months later. Also, stakeholders ask questions that have already been answered, but nobody knows where to find the evidence.

In that situation, a repository feels like the natural next step. If research is hard to find, you create a single place for it. If insights get lost, you want to make them searchable. And if teams keep repeating work, build a shared source of truth, right?

It's easy to see why the idea caught on.

Some UX researchers become librarians

How does it happen? It starts innocently, usually with a spreadsheet or a fresh workspace folder. You set up a few tagging conventions, agree on a naming rule, and feel a surge of administrative satisfaction. But there is a quiet operational slide that happens right after.

What began as a simple taxonomy decision slowly changes into a full-scale maintenance system, with tagging conventions and nested folders. Each makes sense in isolation, but together they start eating away at actual research time. At some point, it becomes really hard to even understand everything you have in there.

This is how researchers accidentally become librarians. Nikki Anderson, User Research Consultant and Founder at Drop In Research, has pointed out a painful truth about this trajectory, saying that “teams often end up working on the repository forever, perfecting the system, only to finally unveil it to an empty room”.

The root of the problem is a tendency to design repositories in a strictly systemic way rather than a pragmatic one. Respected industry best practices frequently instruct teams to build their repositories around a rigid framework:

• Establishing strict roles and regulations
• Designing complex information architecture
• Mapping out extensive tagging systems
• Entering a permanent maintenance mode

This traditional framework optimizes heavily for storage rather than decision-making. When you follow it, you naturally spend your days answering operational questions like:

• How should we categorize studies? 
• What tags should we create? 
• Who can edit the repository? 
• or How often should we clean it up?

This is not what matters to stakeholders

While these questions keep the library neat, they have nothing to do with what stakeholders actually need to do their jobs. A product manager never wakes up thinking they need a repository with a great taxonomy. They wake up wondering if the team has learned anything about onboarding friction for enterprise users. And a purely systemic repository rarely gives them that exact answer quickly.

For a lone researcher, which is the reality at most companies, this creates far too much operational work. My colleague, Senior UX Researcher, Weronika Denisiewicz, noted that this creates a difficult split in priorities. On one hand, researchers need help analyzing current projects. On the other hand, they need a way to connect data and extract insights from everything already collected. Both use cases are critical, but the manual upkeep makes balancing them nearly impossible.

To see what this looks like without specialized tools like our Research Hub, consider how much time vanishes into the organizational void.

When asked to walk through a typical week factoring in repository maintenance, my fellow user researcher at Survicate, Kasia Jordan, shared her perspective:

"As a two-person research team, repository maintenance isn't something we actively work on every week. Most of our time is still spent planning, conducting, and synthesizing research rather than organizing past work. That said, creating the repository required significant upfront work, which we spent on developing research report templates, establishing a consistent structure and creating a simple tagging system to make findings easy to scan”. 

She added that today, maintenance usually happens in larger batches when they review whether the structure still serves the team's needs and make adjustments when necessary. As their repository grows and more people across the company rely on research insights, they’re starting to see that the lightweight system that worked well initially may eventually need to evolve. 

“We need to ensure that knowledge remains discoverable and useful as both the volume of research and the number of stakeholders increase," said Kasia. 

Not building 100% on what we already know

Even when a team manages to keep the administrative monster at bay, a systemic repository creates a deeper, more frustrating form of friction. It isn't always about completely repeating a study from scratch because the old report is lost. From my perspective, the challenge is subtler.

We are a SaaS scale-up company, so we are generally aware of the projects we run and we share knowledge. Because of that, I don’t think we’ve ever repeated an entire research project simply because we didn’t know it had been done before or couldn’t find the results.

The real frustration is starting new research without fully using everything we already know. Research always generates insights that aren’t directly relevant to the immediate project, so they don’t get documented in a way that makes them findable later. During interviews, support conversations, Slack discussions, or daily feedback channels, people raise points that seem secondary at the time but become highly relevant months down the road.

The annoying part is knowing the information exists. I can remember hearing it in an interview, reading it in a thread, or seeing it in a past study. But actually pulling it up when it matters is a different story. The feeling isn't "we accidentally duplicated a project" – it is the nagging awareness that we aren't building on 100% of the knowledge we already possess. We try to review past research and customer feedback before opening a new study, but connecting all those scattered dots manually is where the librarian workflow catches up with us.

Some repositories only create the illusion of impact 

At this point, I believe it’s important to acknowledge the effort UX researchers put into setting up the repository. It takes weeks (if not months) to bring research together, agree on taxonomy, clean up data, and make everything searchable. It's real work, and some of it delivers immediate value. People can find past studies more easily, avoid duplicating research, and spend less time hunting for information.

But it’s also easy to accidentally overcomplicate things. I've seen repositories that kept becoming more and more sophisticated without creating added value for end users.

During a recent webinar we hosted at Survicate, Nikki Anderson shared a story that stuck with me. She admitted that she'd spent months building a repository that never gained traction with the team.

Reflecting on that experience, she explained that researchers can end up acting like "little product managers." We become convinced we know what the organization needs, so we build the solution. Then we find ourselves maintaining it, answering questions about it, and teaching people how to use it.

At that point, the repository starts becoming a product in its own right. Ironically, a tool designed to simplify access to research can end up adding another layer of complexity for the people it's supposed to help.

The way we communicate findings matters, too

I've noticed a similar dynamic in how researchers communicate findings. There seems to be growing pressure to package insights differently for every stakeholder.

For example, a report for one audience, a one-pager for another. And a third group might work best if they’re given a presentation, a video summary, or even a real-life workshop. Each request is reasonable on its own, but the challenge is that, taken together, they create a growing layer of work around the research itself.

I suspect that's part of the reason so many researchers are questioning their impact nowadays. Conversations about AI have only amplified that anxiety.

The misframe nobody talks about 

Repositories are designed to organize knowledge, when they should be designed to drive decisions. This misframe changes everything. By everything I mean the architecture, the maintenance logic, the success metrics, and who the end user actually is.

A library optimizes for storage and retrieval; a decision engine optimizes for the moment a stakeholder needs to act. I think researchers want to be decision-influencers and they even should be, but often the problem is the mindset and the company culture.

That culture often gets stuck in a validation loop. At the 2026 UXinsight Festival, a constant refrain from researchers was: "We want to do more discovery." But it is hard to move into discovery when you drown in validation data that you cannot parse quickly.

That is exactly how it looked for Weronika in her past roles. Research was supposed to be part of the business, to help make decisions quickly. However, the bottleneck was how to extract insights from the collected data at speed.

"We didn't always have insights for every new topic that came up, but we had the data," she said. "This meant that the researcher had to constantly sort through this data just in case, because it couldn't be done quickly on request."

When a stakeholder comes to a researcher with an urgent question, how often can they pull a ready answer from a traditional repository versus to dig through it or run new research from scratch?

For Kasia, the reality without automated tools involves a lot of manual synthesis:

"In many cases, we already have some knowledge related to the question, so we can usually point stakeholders to previous research that at least scratches the surface of the topic. However, it's less common to find a complete answer that's immediately ready to use. Customer needs, product vision, and business priorities evolve, so stakeholders often require more specific insights than what existing research provides."

The segway to the decision engine

Our personas are probably the closest thing we have to a living source of ready answers, and we invest a lot of effort to keep them current and visible across the company. More often, though, to answer a question involves a combination of insights from multiple sources. These include our repository, Slack conversations, customer-facing teams, or previous studies done by different teams, or to plan a new research study from scratch.

This struggle highlights a shift in the research and CX market. Bill Staikos, Managing Partner at BCL, says that the next two years will be less about storage and analysis, and much more about how to influence actual decision-making.

"Summaries, themes, sentiment, and even decent recommendations are getting easier to generate. So the premium shifts lower into the real flow of work. The products that will matter most will change what the company does next, inside the systems where people already work.

In practice, that means deeper ties into contact center operations, service management, account management, digital product flow, or whatever the actual day-to-day engine of the business is."

A repository siloed from where product managers and executives make choices is just a digital warehouse – first on the budget chopping block.

What a decision engine actually looks like 

For me, it starts with a different definition of success.

If a product team can't find the right insight when they're deciding what to build next, it doesn't matter how elegant the taxonomy or repository design is.

The research teams I admire most are the ones that consistently get evidence into the right conversations at the right time. Their work shows up in roadmap discussions, prioritization sessions, and strategy meetings. Research shouldn't be something people revisit after a decision has already been made. It should be part of how decisions get made in the first place.

And this isn't meant as a humble brag, but I think our research team at Survicate already has meaningful influence in that regard. It's one of the reasons I enjoy working here.

We genuinely want to understand users, and our team members actively seek feedback and want to know what customers think before making important decisions. That openness isn't something I take for granted.

I see room for growth in connecting research more directly to business outcomes. Bringing the user perspective into a discussion is important, but it isn't always enough. The more influential role is helping stakeholders understand what a finding means in practice: what opportunity it creates, what risk it highlights, or what trade-offs it suggests.

That feels like a broader shift happening across the profession. The question for researchers today is less about “what did we learn?" and more "what should we do with what we learned?"

This is where AI can help to a certain degree. It can summarize interviews, identify patterns, and surface relevant findings faster than any human team could. That's genuinely useful. But if the underlying system is still built around storing knowledge rather than supporting decisions, AI mostly helps you search more efficiently.

How to start reorienting what you already have

You don’t need to burn down your existing repository and start over. If you find yourself trapped in the librarian role, you can begin to shift the weight of your current setup with a few deliberate changes in mindset:

• audit by decision impact, not by recency or completeness – look back at your past three projects and trace them to an actual product or business change. If a study did not change a roadmap, alter a design, or stop a bad feature, analyze why. 
• identify your real end users and anticipate their needs –  stop building structures for other researchers. If you are a solo researcher, or part of a small team, your main users are product managers, designers, and marketers. 
• stop treating maintenance as a sign of rigor – when you spend hours to align tags and police naming conventions, you take time away from actual discovery. Rigor belongs in your methodology and your insights, not in your digital filing cabinets.
• acknowledge the limitation of manual systems – to do this alone is incredibly difficult. For a long time, the industry playbook told researchers to just work harder, build better structures, and enforce stricter rules. But the tooling simply did not support a decision-first approach.

The shift happening now is a move away from manual upkeep entirely. This is exactly why we built the Research Hub. While it serves as an AI research repository to keep all connected user research and feedback in a single place, the real change is that you do not spend manual hours to maintain it. The focus stays entirely on running projects and using ready-made reports to influence where choices happen in the organization.

When you adopt a project-first approach, the way you spend your time and the outcomes you achieve change completely.

Let’s consider a common scenario. Something is wrong in your onboarding flow, and the quantitative data clearly shows a drop-off. Instead of spending days digging through various folders and tagging old studies, you open a project in the Research Hub. You pull in onboarding surveys, support tickets, and customer success check-ins from the past month, then define your learning goals.

Meanwhile, your Customer Success Director needs answers fast, ideally in a short-form format with clear visuals.

Once you set the project, the system synthesizes data across all three distinct sources. It automatically surfaces the recurring friction points, grounded by direct customer quotes and trend charts as evidence.

Instead of spending two weeks to manually comb through raw text and align spreadsheets, you just review the automated findings. You customize the report for your stakeholder, cut out anything irrelevant, and deliver a polished, stakeholder-ready output in two days.

The researcher stops acting as the manual gatekeeper of past data and steps into the role of a strategic partner who delivers fast, actionable clarity when the business needs it most.

Moving from knowledge storage into decision support

Most of us researchers built repositories because we wanted our research to matter more – to actually move the needle on decisions. Unfortunately, somewhere along the way, some started measuring success by how well information was organized rather than by whether it shaped decisions.

How can you tell whether your research work is effective, though? For me, it’s about checking whether your insights show up when decision-makers start discussing priorities.

That's the shift us researchers need, i.e., less time tending the archive, more time shaping what happens next. It's also the thinking behind Research Hub – we built it to surface the right insight at the moment someone needs it, not to give people one more place to store research.

AI can already find the information. The real question is whether that information helps someone make a better call.