How to maximize the use of UX research repositories in your organization

User research repositories are all the rage these days. From a cursory glance, this makes sense. They're well-structured searchable databases of user insights. They align with the general research process of initiation, planning, recruiting, data collection, synthesis & analysis, reporting, and follow-up. 

They make the last four steps easier, making the results potentially reusable in other research projects. They are the perfect tool to build an atomic research practice. Organizations using repositories quite frequently run into a pragmatic flaw, though.

The issue doesn’t come from the tool but from how it’s implemented. Company-wide adoption of the research repository remains very low despite efforts to democratize insights. The research team builds a searchable database of insights that could help their future work, but these insights don't reach the others.

Why does this happen?

These research projects are long and expensive and are done in discrete sprints, organized around product management's questions about the customer, and the static answers research provides them. This formal research project has its place and value—when testing a new release or creating personas, for example. However, when applied to all research questions, it's detrimental. Big projects can only be executed a few times a year, provide their answers, and conclude. Everybody forgets them and moves on to the next topic. 

I would argue that a lightweight continuous research practice achieves customer-centricity better. It consists of smaller regular customer touchpoints that are automated as much as possible. It saves resources on the initiation, planning, and recruiting kick-off stages. It uncovers 'unknown unknowns' about customers. Its costs are spread out more evenly. It provides a continuous flow of customer information to every organizational stakeholder.

When people are not interested in insights

Back to repositories. Setting up your research practice greatly influences how the repository will be used. When research becomes a Q&A answering machine that answers product management questions in isolation, its repository becomes a simple project management tool for that single department and a library of valuable knowledge nobody else visits. Imagine cobwebs in the gloomy corners. 

For example, the UX researcher at a leading customer engagement platform said adoption didn’t go well because colleagues outside of research viewed the repository as a new learning tool. Without understanding the benefits, it became a nuisance instead of a hub of customer knowledge, and people didn’t even create an account.

The Design Lead at a petrochemicals company said their vast collection of insights is not used because “business decisions are made based on economics and technology, and insights introduce a new variable that makes everything more complicated.”

The Director of UX Research at a company developing collaboration tools expressed skepticism about repositories saying that the amount of information used from these repositories does not justify the costs associated with building and maintaining them. He said: “Repositories are like a library. Only 5-7% of the content is used. Compared to that, significant work must go into structuring the data. Otherwise, it will be useless. This is a big overhead.”

All these arguments are valid.

• People outside of research need to see the benefit of research repositories
• Decision-makers need to understand the importance of customer insights for areas outside of research
• The costs associated with repositories need to be justifiable

A proposed solution: collaborative continuous research

Imagine a different scenario where everyone in the product team (product management, developers, designers) works together with customers to continuously uncover insights and implement them in products and features.

Research becomes a regular collaborative exercise that equips everyone with firsthand knowledge of customers’ pain-points and needs. There are many benefits to this:

1. It builds empathy and makes internal stakeholders interested
2. It aligns incentives of different teams toward the customer
3. It makes the maintenance of the research repository a cheaper ongoing process
4. It makes the use of the research repository regular practice so insights actually get to where they need to be
5. It generates insight much quicker than formalized and siloed research processes

When all stakeholders in the product team are active generators of insights, they will understand the benefits of a research repository and use it regularly. The cost of maintaining a clean set of relevant data also becomes cheaper. When everyone is invested in the database, maintenance can be ongoing instead of resorting to large cleaning projects that everyone hates to do, a crowdsourced effort if you will.

For example, Microsoft’s Human Insights Library was built with this in mind. In his article, Matt Duigan places equal emphasis on the quality of the insight database and the company culture that supports its use. One without the other is not enough.

Five tips for maximizing the use of your UX research repository

As you see, I am big on the concept of continuous collaborative research practice but cultural shifts aren’t easy. 

There are also very specific practical steps you can take to disperse and maximize the use of your research repository inside your organization. Here are the most important ones.

1) Making user sessions relevant for colleagues

A common problem of user researchers is convincing product team members to join a session. Once people join, they will start experiencing the benefits of attending.

It’s worth finding early adopters in the organization, inviting them, and writing success stories on how attending user sessions helps achieve amazing results. Distribute the success stories to others in the product team and have those early adopters present their experiences to widen the circle of adoption. 

2) Note-taking

This is a simple and easy way to involve colleagues outside of research when you’re doing interviews. Rather than have them sit idly, distribute work among attendees and have non-researchers take notes.

During synthesis, you can compare them and uncover insights from multiple viewpoints. When note-taking is done in the repository app, people will also get used to working in it. You can also go one step further and differentiate note-taking roles. One person takes notes on facial expressions/body language, the other on key points the user makes. Everyone writes down three to five key learnings.

A powerful example we’ve heard is when the user researcher asks the others to write three core assumptions about the user related to the topics to be uncovered in the session before joining the session and then checking if those assumptions are valid during the session.

3) Synthesis

Involving non-researchers in synthesis sessions also highlights problems that researchers may have glossed over. Developers will be able to add technical viewpoints, designers their UI best practices, and so on. Once again, using your repository for synthesis will strengthen the practice of everyone regularly using the app too.

4) Taxonomy

Create a tagging system that focuses on stakeholders' search requirements. There is no point in tagging every little detail – focus on what needs to be found and how. Consider how tags will be consumed. Sounds straightforward, but it’s easy to get lost in details, and build a system for its own sake. Don’t.

5) Maintenance

Maintaining a relevant clean database is key to your repository's success. It is also a major pain if you do it in irregular projects. It takes a lot of time and it’s drone work, so no one wants to do it. When everyone’s using the database, you can make maintenance an ongoing crowdsourced effort. This way, it requires less resource investment. It’s also a great idea to use timestamp notifications to see when certain insights become too old to use.

Next steps

Using these steps, it will become a breeze to use your repository for anyone outside of research. The obvious next step is involving the broader product team, but you can go even broader.

• Marketing looking for the tagline of their next ad campaign? They can take ideas from your repository.
• Sales building a strategy for your new product? They should read the insights from the beta testing interviews.
• C-level preparing for the annual investor presentation? They should check the trends in your CSAT scores and then combine them with customer quotes.

Truly everyone can benefit from user insights. They need to get into the practice of doing so. 

Conclusion

Research repositories are great tools to conduct and organize your research, but that's what they are—tools. To unlock their full potential, all stakeholders in the company need to understand how and why to use them. We believe this is best achieved by involving as many of them as possible in a continuous customer-facing research process.

There's no silver bullet. Both collaboration and continuity help, but it is up to you to decide the level and frequency of engagement inside and outside the company. Whether your repository becomes the next productivity tool or a rich collection of customer insights will come down to cultural acceptance.

That will happen when the benefits of using your repository are understood theoretically and tried in practice, and their positive results are experienced.