The Research Repository Paradox: It's never too early (or too late) to start

Many UX teams struggle to determine the right time to set up a research repository—a system for organizing and sharing past research insights across a team.

When they have little to no past research, a repository can seem unnecessary. On the other hand, teams with a large archive of past research face a steep implementation challenge in structuring everything into a useful repository. 

This creates the feeling of a paradox: it never feels like the right time to build a repository. But the truth is that the amount of past research you have shouldn’t dictate whether or not you set up a repository. Whether you have a little research or a lot, you can still reap the benefits of a repository. The key is adjusting your approach to fit your starting point. 

Why teams put off establishing a research repository

In theory, the more past research insights a repository holds, the more valuable it becomes. This creates friction when deciding when to implement one. A team that just completed its first user research study could establish a simple tagging and storage system fairly easily, but they would see little immediate value. Conversely, a large company with years of past studies could benefit immensely from organizing, tagging, and making them searchable, but the investment of time, money, and sheer effort required can feel overwhelming. 

We call this dilemma the Repository Paradox. On one end of the spectrum, teams may choose to wait until they have more research before setting up a repository. On the other end, the perceived hurdle of organizing years of studies can make them hesitate to start at all. This leads to the insights management equivalent of technical debt. Other challenges, like the need to add new tools and a focus on generating new research to address incoming questions, can make the idea of dedicating resources to implementation even more daunting. However, the longer a team delays, the harder it becomes to get started. 

When should a UX team set up a research repository?

The truth is that it’s never too late, or too early, to start a research repository. Regardless of whether you have many or few past studies, building an insights repository creates a single place where anyone can quickly search for and access findings. It helps prevent duplicated research, increases the discoverability of insights, and extends their shelf life. Delaying the decision to build a repository only postpones these benefits and makes implementation more challenging down the line.

The Repository Paradox isn’t a problem of optimization—where at some magical point, the value and effort curves intersect to justify the investment. Instead, the real question is whether your team faces certain challenges that a repository can solve. If you can answer "yes" to these three questions, then it’s the right time to start a repository:

1. Do stakeholders frequently ask about users, their behaviors, or attitudes?
2. Is your research data scattered or not centralized in a single location?
3. Do you want to democratize access to user insights across your organization?

If the answer to all three is yes, it’s time to start—whether you have 10, 100, or 1,000 studies in your archive. When building a repository, there are many considerations, such as:

• The type of software you’ll use—whether a purpose-built UX research tool or a more general database.
• The repository format—whether a document library or an atomic insights database.
• The process and steps involved in structuring and maintaining it.

These are worthy topics but outside the scope of this article. Instead, we’ll focus on how to approach building a repository based on where your research practice stands today—whether you’re starting fresh with only a few studies or working with a vast archive of past research.

What to do if you have little to no past research

It can be easy for a young research practice to procrastinate on building an insights repository. Despite the temptation to wait, if your team meets the key criteria outlined earlier (i.e., frequent stakeholder questions, scattered research, and a desire to democratize insights), now is the time to start organizing and managing your insights. Instead of thinking about a repository as something that only provides value once it has a critical mass of information, think of it as a habit of organizing your work and an infrastructure that will scale alongside your research team.

When starting an insight repository at this stage, the key is to set yourself up for success and scale without over-complicating things:

1. Identify the minimum viable repository: A repository doesn’t need to be highly structured with a complex tagging system from day one. Over-engineering your repository and its organization places unnecessary friction and pressure, making setup much more overwhelming to get started than it should be. Ask yourself: “What is the simplest possible solution that would be useful today?” This could be as simple as ensuring that all of your insights are in a single, searchable location with a simple set of broad tags or basic organization.
2. Avoid the urge to go high-maintenance: Nielsen Norman Group's research shows that one of the key reasons why repositories fail is that researchers find it takes too much work to contribute to them. So when building your repository early on, ask yourself how you can reduce the friction for researchers who are adding their studies. Decide on the bare minimum information that makes an entry useful, while keeping the effort relatively low. Additionally, consider how adding something to the repository can be incorporated into existing processes, such as tying it to project retrospectives or other regular workflows.
3. Use a flexible schema:  The way you organize your repository today doesn’t need to be perfect, but it does need to be flexible enough to accommodate the future. Your repository should scale with your research team. Failing to build in flexibility now can lead to a situation down the road where adapting it is so difficult that you have to rebuild from scratch, effectively undoing the investment made in the beginning. Ask yourself: “How can our work be sorted today?”, “How might that change in the future?” and, most importantly, “How can we build things now to accommodate those future needs?” Your team's needs will evolve, but you might not know exactly how, so your repository should be structured to adapt accordingly. Starting with broad categories and a flexible tagging system today allows you to grow and refine the structure over time.

By approaching building a repository this way, even a team with little to no existing research can quickly build an insights repository that provides immediate value and has room to evolve as their research team and projects change.

Enjoying this article? Subscribe to Depth by Drill Bit Labs, a newsletter about UX research and digital strategy. You'll join 5k+ subscribers advancing the practice of user research one issue at a time.

What to do if you have a lot of past research

With a huge backlog of insights, building a repository can feel like an insurmountable effort. In the face of such an effort, the easy temptation is to put things off and wait until your team has the capacity to handle a project of that scale. In practice, that moment rarely comes. 

Again, research teams in this situation should build a repository if they regularly receive questions from stakeholders about users, have disorganized past findings, and desire to democratize access to those insights. However, it is wise to scope things down, turning the rollout into a more manageable project focused on the highest-importance items rather than attempting to restructure all past projects completely. 

1. Make it smaller with a gradual rollout: Focus your initial repository rollout on the highest-impact materials. That could mean prioritizing past research by specific methods, projects, products, or document types. Additionally, you might decide to only include research from a certain timeframe—for example, the past 18 months. A thorough review of the research projects that have been most frequently referenced will help you identify the most critical studies for decision-making within your organization. You could even create a scoring system to prioritize the most valuable projects. By the end of this process, you might produce something like this example from Marianne Carpentier, to illustrate what is and isn’t in scope for the initial rollout.  

2. Consider how automation can assist you: Some tools offer automated tagging, which can further reduce the manual work involved in organizing and categorizing past research. Consider how these tools might help, and review options to see which are the most appropriate for your team. Automated tagging will not be perfect, but it will help you produce something useful. 
3. Pilot and build as you go: After completing your initial rollout, treat the next few months as a pilot period. Use this phase to assess the scope and effectiveness of your repository. You might track requests for materials or information that aren’t in the repository yet and create an updated list of things to add. Focus on adding new research and insights within the scope of your repository. After assessing if your team has more bandwidth, you can consider adding second-order priorities.

Starting a repository when you already have a significant archive might seem daunting, but you can manage the challenge by taking things in stages. Focus on adding your highest trafficked and most impactful work first, making use of automation where appropriate, then expand on your pilot as demand reveals itself. 

The bottom line

Research repositories are essential for making UX insights accessible across an organization, but teams often delay setting them up. A team with very little past research may not see immediate value in building a repository; on the other hand, a large company with years of past studies may see immense potential in organizing its information, but the scope of that effort can feel daunting. This often leads to the Repository Paradox—a feeling that it’s never the right time to roll out an insights repository. 

The truth is, as long as you have frequent questions from stakeholders about users, the desire to democratize access to insights, and a current system that is either disorganized or not centralized, you can and should start building your repository. This applies equally to teams at all stages of their practice: 

• Teams with little to no past research can begin with a minimum viable repository designed for scalability, using a flexible schema that grows with their team and ensuring that the process of adding new insights remains simple and low-maintenance.
• Teams with a large archive of past projects should start by narrowing the scope of their repository rollout, prioritizing the highest-impact and most frequently referenced studies for the initial release. Afterward, they should pilot the repository for a few months to assess its effectiveness before expanding its scope.