Practical steps to ensure the success of your research repo.
User research repositories (or repos for short) are all the rage these days. From a cursory glance, this makes sense. They are 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.
In fact, they make the last four steps easier, and the results become potentially reusable in other research projects. They are the perfect tool to build an atomic research practice.
Organizations using these repos quite frequently run into a pragmatic flaw though.
The issue doesn’t come from the tool but the way it’s implemented. Company-wide adoption of the research repo 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?
When repos are set up to align with a formalized multi-step research process, they tend to become an internal tool used by research for research, in isolation. In our article titled “Why You Should Build a Continuous Research Practice,” we argued that such a formalized research process is suboptimal.
These research projects are long and expensive, and are done in discrete sprints, organized around the questions product management has about the customer, and the static answers research provides to them.
This kind of formal research project has its place and value - when testing a new release or creating personas, for example. However, when it is applied to all research questions, it is 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 spent on the kick-off stages of initiation, planning, and recruiting. It uncovers 'unknown unknowns' about customers. Its costs are spread out more evenly. It provides a continuous flow of information on customers to every stakeholder in the organization.
Back to repos. The way you set up your research practice greatly influences how repos will be used. When research becomes a Q&A answering machine that answers product management questions in isolation, its repo becomes a simple project management tool for that single department, and a library of valuable knowledge that nobody else visits. Imagine cobwebs in the gloomy corners.
When we did our exploratory interviews for Airtime, we heard about many failed attempts at implementing research repositories. The UX researcher at a leading customer engagement platform said adoption didn’t go well, because colleagues outside of research viewed the repo simply as a new tool to learn. 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 repos saying that the amount of information used from these repos does not justify the costs associated with building and maintaining them. He said: “Repos are like a library, only 5-7% of the content is actually 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.
Imagine a different scenario where everyone in the product team (product management, developers, designers) works together with customers to uncover insights and implement them in products and features continuously.
Research becomes a regular collaborative exercise that equips everyone with firsthand knowledge of customers’ pain-points and needs. There are many benefits to this:
When all stakeholders in the product team are active generators of insights, they will understand the benefits of a research repo 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.
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 repo inside your organization. Here are the most important ones.
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.
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.
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 repo for synthesis will strengthen the practice of everyone regularly using the app too.
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. Dovetail posted a great article on taxonomy written by Tomer Sharon. The article’s first key takeaway is you need to 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.
Maintaining a clean database that’s relevant is key to the success of your repo. 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.
Using these steps, it will become a breeze to use your repo for anyone outside of research. The obvious next step is to involve the broader product team, but you can go even broader than that...
Truly everyone can benefit from user insights, they just need to get into the practice of doing so.
Research repositories are great tools to conduct and organize your research but that is 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 you can in a continuous customer-facing research process.
There is 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 repo becomes the next productivity tool or a rich living collection of customer insights will come down to cultural acceptance.
That will happen when the benefits of using your repository are not only understood theoretically but are tried in practice and their positive results experienced.