10 Common Misconceptions About Research Repositories

I’m starting with this one because not so long ago I thought so too! Only after using trial versions of several tools did I realize that a repository is so much more than a digital library of results. In fact, the stakeholders’ view of all the published deliverables (insights, reports, journey maps) is just the tip of the iceberg.

The real magic happens behind the scenes — in the researcher's view. Here we store all the raw materials (like recordings and transcripts) and this is where analysis and synthesis happens. No need to do it with external tools ever again.

What is more, repositories can also be a place to store other documents relevant for researchers (like research plans and notes) and for stakeholders (like design guidelines and product requirements), which leads us to the second misconception:

That’s very far from the truth. They can enable researchers to involve stakeholders in co-analysis more easily.

Tagging, clustering, and deriving insights collaboratively go so much more smoothly in a dedicated repository tool.

Repositories can also make research results more accessible inside and outside of the company (for example when working with freelancers or agencies). When used well, they can boost product discovery. They can also make research more visible in the company.

However, it’s not true that…

I think a lot of disappointment regarding repositories comes from situations in which researchers prepared them in a silo, revealed them to stakeholders & expected them to embrace a new tool. The wake-up moment can be painful. Stakeholders have their own things going on (surprise!) and are much less excited about a new repository than researchers.

That’s why identifying and including relevant stakeholders should start way before even choosing a repository tool.

To decide who should use your repository, clarify who needs to make decisions based on the results you provide. Product managers? Designers? Developers? Then understand well how they plan, structure, and manage their work. What tools do they use? What is important to them? Knowing this will help you to embed the repository into existing processes as much as possible, instead of single-handedly starting a revolution. You will also know how to prepare the artifacts’ templates, for example, what metadata to use to make them more findable.

Different teams using a research repository

Let me highlight this once again: receiving an access link should not be the first moment a stakeholder hears about the repository. That being said, easy access is of course also important. At AirHelp our Condens repository is available for every employee with a single sign-on, which makes things smooth. All we need to do to include someone new is to send them a link to a published artifact. No account creation process or lengthy user management steps are necessary.

There is of course also a question of what we mean by stakeholders “using the repository”.

• Accessing results? That’s relatively easy, however, introducing self-service habits takes time.

• Taking part in analysis and synthesis? That calls for more advanced onboarding and possibly some training led by UXR.

• Regularly reviewing and acting on new insights? That requires introducing an insight management process and will not happen overnight.

One of the actions that can be helpful here is to tag potential insight owners in published artifacts — so that they are notified and can quickly filter deliverables that concern them, for example when planning a quarter.

Just take it step by step and don’t get discouraged! Implementing a repository takes time. But I don't think that…

There are different companies and different working cultures, that’s true. But (maybe besides small startups) I don’t believe in truly implementing a repository in a bottom-up initiative without management’s support. Sure, one can do that to streamline their own work, but it’s hard to make the most of a repository in such a way.

Using a repository is not just adding a tool — it’s changing how research is done and shared.

Certain UX maturity is needed to be able to make such a transition. Without having Robert Kowalczyk, our Director of Product & Brand Design and Jennifer Agerton, our Chief Product Officer, fully on board, I wouldn't have been able to implement a research repository so quickly and smoothly.

So the first step for a researcher, if the idea is coming from them, is to get buy-in. We don’t want a new UXR toy - we want the design and product teams to embed a research repository in their processes. We want them to feel it’s their tool as well.

By the way, this is a pretty common misconception:

Oh, how often I’ve seen posts asking for the best repository! Don’t start with this question. There are many products out there and to assess them you need to know what you want, otherwise how would you compare them? So:

1. First, think what are your goals,

2. Why do you want a repository,

3. Who will use it,

4. And how would you like your research process to look?

Don't focus too much on comparisons found in online articles or on Slack groups, because they may be concentrated on things irrelevant for you.

When I was choosing a tool last year, on my list of requirements were for example aspects like:

• data security (GDPR compliance, ISO 27001 or SOC 2 certificate, single sign-on),

• analysis features (advanced taxonomy, adding multiple tags and text summaries for each transcript fragment),

• synthesis features (creating deliverables on split-screen, the option to drag & drop highlights to reports and other artifacts),

• sharing results (stakeholders’ view with a possibility to add comments, sharing via public links with passwords, Slack integration, advanced search).

So what’s important to you? And what kind of approach do you have - would you like to try atomic research? There are repository tools specifically dedicated to that. However, it’s also a myth that…

Atomic research, developed by Tomer Sharon, moves away from reports and lengthy presentations towards “nuggets” — basic units of research insights. A nugget is an observation about a user’s experience backed by evidence (e.g. linked with a video highlight) and tagged. Being able to easily find individual nuggets is supposed to make research results more accessible and prevent the loss of organizational knowledge.

The atomic approach combined with a repository tool can indeed be very powerful. However, it comes with its own risks — like the time needed to report in such a granular way or the threat of a stakeholder using a nugget out of context. Besides, sometimes a team may just not be ready to implement the atomic way of doing research. And this does not mean that a research repository is not a solution for them.

First of all, as I already mentioned, research repositories can significantly support qualitative analysis. And that is game-changing regardless of the approach to storing and presenting results.

Secondly, it does not have to be all or nothing. At AirHelp we have adopted a dual approach. We publish two main types of deliverables in the repository: reports and insights. Reports summarize the results of requested research projects. They are tagged with metadata like “Product area” or “Research method” and follow a clear structure depending on the project type. (For example, a report from a usability study contains a severity rating and all issues identified in this study - color-coded according to severity and backed up by video evidence). A report like that is delivered to relevant stakeholders, who follow up with the identified issues.

However, in many research projects, we uncover insights that are not the main focus of the study or any ongoing product initiative, so there is little sense in adding them to a report. They are still interesting and relevant though & we wouldn’t like to lose them, so we publish them as individual insights — self-contained findings tagged i.a. with “Product area”, “Customer Journey stage”, “Feature”, “Vector” or “Magnitude”. In such an insight we mention potential owners so that they can review such observations easily and regularly when planning their work.

To sum up, we use both reports and more granular insights depending on the situation. But even if the stakeholders’ view was just a library of reports, the fact that it’s prepared in a dedicated tool can make it much more searchable than a traditional collection of slide presentations or PDF files. It just takes some effort not to let chaos creep in, sure. This leads us to the next myth stating that:

Creating a repository of research results for stakeholders in Condens takes very little extra time or effort for my team at AirHelp. We create it alongside doing research, our repository is a by-product of analysis and synthesis: we tag recordings, easily cluster video highlights in the report visible on split-screen, color code the clusters according to severity and then explain the findings. We would have to do it anyway in some form. With Condens though all we have to do at the end is to press “Publish” and a clearly structured report appears in our repository and is announced on our Slack channel. Ready to share on a video call too — no extra slides are necessary.

In pre-Condens times I used to take notes on a digital board first, then cluster them there, explain the results in an online document, and summarize them on slides, where I had to embed downloaded video snippets. Ouch! So much extra work caused by switching between too many tools and doing things manually!

„A dedicated repository tool was a game-changer.“

Aga Kaim

Senior UX Researcher at AirHelp

Besides, UX research always creates a kind of repository. It’s just that if there is no defined process and dedicated tool, then such a “repository” can easily turn into a bunch of slide decks, Google Docs reports, Confluence wiki pages, PDFs, and emails with results or findings mentioned in the Jira tickets. And navigating chaos like that is hard. Research gets duplicated or UXRs spend a lot of time trying to find past results and send them to stakeholders. Condens enabled us to introduce self-service in finding results — yet another source of saved time!

That being said, the following opinion is also not true:

Yes, repositories save time, but they are not self-sustaining. They require some maintenance, especially if more people publish artifacts. Do they use agreed templates to keep documents consistent? Are all the published deliverables of good quality and up to date? It’s good to allocate some time for a regular repository health check. And it’s even better to evaluate the repository with stakeholders from time to time.

Even the best-planned repository will change over time. You will need to adapt artifact types or adjust taxonomy, and that’s completely normal. So don’t try to make it perfect from the start — you will need to iterate like you do with everything else in the product world. Just be sure to choose a tool that will let you and the rest of the research team adapt your approach. You don’t have a team? No worries, it’s not true that:

As I already said, well-chosen and thoughtfully implemented repository tools are huge time savers. And who needs time more than a rather small team juggling a lot of research requests and initiating their research projects on top of that? Exactly.

I am convinced that repositories are useful not only for large in-house research teams but also for sole researchers, small teams, agencies, and freelancers. A centralized location to store research data and insights can help ensure that insights are not lost and can be easily accessed in the future.

Repositories make sense everywhere, where qualitative analysis, sharing results, and keeping track of what was done take place.

Hint: that is probably everywhere where research happens. And I mean many kinds of research, because it’s a myth that:

They can be useful for storing data from a variety of research methods, such as benchmarking, surveys, or A/B tests. And don’t limit yourself to user research — include market research too. Invite other teams engaged in research activities to upload relevant research results to the repository. This can help provide a holistic view of the product landscape and inform product decisions.

In conclusion, dispelling these ten common misconceptions about UX research repositories is vital in maximizing their impact in the field. By implementing a repository in a thoughtful and context-appropriate way, researchers can unlock their full potential and more effectively contribute to enabling informed decisions.

I strongly believe that repository tools can supercharge projects of all sizes and shapes. And the best first step? Discussing these myths with your team.