When used effectively, research repositories help teams showcase their research and its value. A research repository can improve an organization’s UX maturity by allowing more people to utilize user-research insights. However, to achieve these benefits, you’ll need to overcome significant challenges. This article shares advice from people who have already been through this process.
The State of Research Repositories Today
I surveyed over 400 UX and ReOps professionals and conducted followup interviews with select respondents to identify the main barriers to creating a successful research repository. In the survey, I asked respondents about their research repositories.
Age of Repository
Research repositories have become more popular in the last few years, due to the emergence of ResearchOps and the rise of new tools designed exclusively to house repositories. These facts may explain why almost 80% of our respondents had a repository younger than 3 years old, with over 60% of those repositories being less than a year old.
Repository Maturity
It can take years for a repository to be fully established and gain traction. People need to contribute enough research to the repository for it to become useful — which takes time. Also, it can take a while for stakeholders and teams to get in the habit of contributing to or checking for relevant insights in a research repository. Given the young age of our respondents’ repositories, it’s not surprising then that many respondents reported that their repository was in the early stages of growth.
Sadly, 11% of our respondents said their research repositories were stagnant or forgotten about.
Adoption
Research repositories with good adoption have researchers regularly contributing research insights and teams regularly accessing the repository to seek research insights. Not surprisingly, respondents with more mature repositories reported better adoption: 65% of respondents with a repository older than 3 years reported good adoption (i.e., “good”, “very good”, or “excellent”), compared to 37% and 34% of respondents with a repository of between 1–3 years and less than a year, respectively.
Across the board, almost a fifth (19%) of our respondents felt that their research repository had poor adoption.
4 Big Reasons Why Repositories Don’t Get Adopted
1. Very Low UX Maturity
Some respondents strongly felt that their organization was not ready for a research repository because it did not have a sufficient level of UX maturity.
“A research repository will not address the root cause problem your company likely has, which is a broken decision-making process based on political power and gut feelings…”
Organizations not yet at the emergent stage of the UX maturity model often don’t see the value of a research repository. Without stakeholder buy-in and an understanding of research, it’s typically too early for a research repository to be needed or appreciated.
“I think the success of the adoption of a research repository is heavily dependent on the culture and design maturity of the company, so this is the challenge I’m trying to address first, and hopefully, adoption will increase from there once stakeholders and other teams understand the value of research and design practices.”
2. Many Practitioners Are Frustrated by Repository Tools
The 3 most popular types of tools our respondents used for research repositories were:
- Collaboration software (like SharePoint and Confluence)
- User-research platforms (like Dovetail and EnjoyHQ)
- Database tools (like Notion and Airtable)
In a few cases, respondents used multiple tools together to build their repositories. 10% of our respondents used other tools, like project-management software (e.g., Trello) or design software (e.g., Figma, Miro) to house their repository.
Across the board, 23% of respondents were dissatisfied with the tool they used to house their research repository. As a result, our respondents urged future repository creators to procure a specialized tool for the job and to research those tools and their capabilities thoroughly.
Collaboration Software: Often Used, Often Disliked
Since collaboration software is commonly available in most organizations, it becomes a natural starting point for a research repository. However, respondents using collaboration software were the least satisfied. The median satisfaction score was 3/5 for collaboration software compared to 4/5 for both user-research platforms and database tools. This difference was statistically significant (p<.05).
Additionally, respondents who used collaboration software reported lower levels of adoption than respondents using user-research platforms or database tools for their repositories, even though collaboration software is often accessible to more employees in an organization. This difference was also statistically significant (p<.05).
Respondents using collaboration software complained about the lack of tagging, poor search capabilities, and clunky interfaces. These issues make it hard to maintain and surface relevant insights for stakeholders, impacting the adoption of their repositories.
"I've worked at two organizations with SharePoint and it's a clunky tool and feels intimidating to use sometimes. I find that it's not only hard for stakeholders to find old research but also for me to find old research to reference. There's no way to tag usability problems or major insights across studies."
"I find Confluence difficult to navigate and find what you're looking for. Although team members have the link to our repository, they still consistently come to me to find documents and resources, somewhat defeating the purpose of setting up a repository. The repository is also not easily searchable unless much manual effort is put in, making it a hassle to maintain."
Research Platforms: Pricey but Powerful
Despite higher satisfaction and reported adoption, respondents still had complaints about user-research platforms (like Dovetail and EnjoyHQ). Common complaints surrounded the complexity of the interface and the exclusionary pricing — which put helpful features out of reach or limited the number of users added to the tool.
“It has great features and customer service but the learning curve is very steep, and it is off-putting to people who want to use it on a casual basis. Its advanced features are discouraging adoption.”
“Almost everyone has to be registered to have access. Nobody can go and browse around the findings; key people involved in a research project that are nonresearchers can't even comment.”
3. No One Owns the Repository
Research repositories are often owned by a ResearchOps function. However, only 8% of our respondents had a ResearchOps practitioner owning the repository. For most respondents, ownership fell to one or more researchers. 29% of our respondents reported that their repository had no owner.
When repositories have no owner, they quickly become disorganized or forgotten, as no one advocates for them and reminds team members of their existence and value.
“People aren’t adding their research to it and thus also aren’t looking there for past research. We haven’t been able to dedicate time to making it up to date. Because no one in particular is assigned to ensuring it’s useful and promoting it, it’s not widely used.”
Additionally, when researchers are responsible for managing a repository alongside their research role, maintaining the repository is often deprioritized.
4. It’s Too Much Work to Contribute
Several of our respondents and interview participants mentioned the additional work required to contribute to the repository. Some respondents found the required tagging to be too time-consuming, whereas others felt they were duplicating work by uploading or documenting research insights in different places.
“It's great in theory, what we find is that it's just an additional layer of work that needs to be done. And with a small team, like we have, we really just need to be able to continue to roll through our studies”
If contributing to a repository is too time-consuming, it won’t happen. Seek feedback from potential contributors on any new processes so you can learn how to make contributing to the repository an effortless extension of their existing workflows.
7 Tips from Practitioners
Survey respondents offered advice to anyone creating a repository. Here’s what they said.
1. Choose the Right Tool
Respondents recommended choosing a tool purposefully built for the job rather than trying to bend a tool to the job — which will only make it difficult to maintain and use. If you need to procure a new tool, respondents advised thoroughly examining the offerings on the market. Consider the features the tools offer, their sharing capabilities, and their likelihood of going out of business.
“Compare the tools properly before deciding on a repository. It can be very difficult to migrate the content if you’re not satisfied with the functionality.”
“Research a variety of tools and make a comparison sheet for them. Find one that has great usability, or you won’t intimately [sic: ultimately] adopt it.”
Additional aspects to vet are the tool’s compatibility with the organization’s existing tool set, workflow, and culture. A tool that can’t easily be accessed or that is too different from existing tools might be difficult to adopt.
While you research tools, be wary! Research repository tools often advertise specific features but then do not include those features in cheaper pricing plans. Respondents recommended exploring plan features before procuring to avoid disappointment.
2. Have Clear Goals
There are many ways to implement a research repository. Before creating one, think about who will access it, how it will provide value, and what its purpose is.
“Think about the outcome and work backwards. Why are you creating [it]? What are you hoping to achieve with it?"
“Set out clear goals (beyond put[ting] all our research in one place). Is it primarily going to be a tool for researchers? Or for sharing research with non-researchers? Why? What will it enable?"
The goals of your research repository will determine which data sources should feed into it, how it is structured, and what the process for contributing to it should be.
3. Take a User-Centered Approach
Respondents stressed the importance of involving those who will use the repository in the process of creating it.
"Interview your end users in the same way you would users of your product to understand their expectations, desires, unmet needs with how things are currently done and then strategize ways to meet those needs within the context of your organization’s limits: budget, time, a dedicated person managing it”
"Build out processes that integrate into researchers' current processes as much as possible and be consistent with reminding them how to use it. Involve them in the development of the repository and respond to their feedback."
Respondents recommended treating the development of a repository like the development of a new product. Start with discovery research to understand your target users and their needs. This discovery work will uncover what type of repository and contribution process would be useful and effective. Test any early repository designs with your users. You can learn whether organizational structures, tags, or contribution processes are intuitive and usable.
4. Create a Taxonomy or Organizational Structure from the Start
Some of our respondents allowed their repositories to grow organically without a preset structure. While doing so helped to understand how people might use the repository, they found it difficult to organize the repository as more content, folders, or tags were added. As a result, they advised putting in place an organizational structure from the start and ensuring this is well-documented and communicated to all contributors.
"Be intentional and strategic when tagging and categorizing information to ensure scalability; important to set tagging rules and standards when first setting up [the] repository (it’s difficult to go back and revise once you’ve got a large volume of data amassed)."
"Start with a strategy in mind (tagging taxonomy, organization, etc.) and put in place a way in which to assess and govern ongoing. Once it's too far gone, it's really hard to spend the time and energy to make the changes needed to get where you want to be."
5. Start Simple and Be Willing to Iterate
While providing some structure is important, our respondents also emphasized keeping that structure simple. Many advised against creating too many tags or tags that were too granular. They learned that not all use cases or tags can be predicted upfront and that some iteration will be needed over time.
“Don't be afraid to iterate. Have multiple revisions — and always improve your process.”
“Pilot it first, and see how templates and ideas evolve through use. Plan to change it until everyone settles into a rhythm that works well for your goals.”
“Start small and simple.”
“Be open to iterating the process. Use what works and adjust what can be improved, don’t just set it in stone because “that’s the way it’s always been”.
Additionally, some respondents mentioned the concept of an MVP (Minimum Viable Product). Creating a simple repository that provides value early can help you learn what to keep, what to add, and what to change.
6. Keep It Updated
An unmanaged repository quickly becomes unruly and difficult to use and manage. Some respondents recommended having someone responsible for owning the repository, whose job is to keep it up to date by overseeing tags and contributions while ensuring teams continue to add their research.
Respondents who had repositories without owners recommended running workshops or activities for the team to revisit and update the repository.
“Set up a regular cadence for governance and maintenance – revisit the taxonomies, document structure, etc. Have a repo spring cleaning party, and make it collaborative and fun! An untended repo becomes difficult to use rather quickly.”
7. Advocate for it
Many of our respondents and interview participants realized that the secret to successful adoption isn’t just creating a usable repository but also what happens after it is created. Advertising, training, and regular reminders are needed to get contributors to upload their research and to encourage teams and stakeholders to access and use it.
“Be prepared to just be the champion for it (....) when I started out, I was like, well, this is just a tool. It's gonna be easy (...) it turned out to be a process and a cultural change (...) you have to continue nurturing it along for a really long time.”
Some of the strategies employed by our survey respondents included:
- Linking to the repository in research documentation
- Talking about the repository often in team meetings
- Sharing from the repository during meetings
- Sharing from the repository to team chat channels (like in Slack or MS Teams)
- Automatic update notifications to subscribers when new research is added
- Creating and sending regular newsletters featuring insights from the repository
“Send out emails (or other company-wide communication) recapping the latest results in the repo with links into the repo. Socializing in other channels can really help keep it top of mind (and expose more folks to the wonderful research your team is doing).”
Conclusion
Creating a successful repository is difficult and can take time. Make sure your organization is ready before creating one. When embarking on a project to create a repository, apply user-centered design and Agile principles to its creation: start small and simple and design with your target users’ needs in mind. Plan to evolve and champion your repository for the best results.
