At UX Studio, we’ve been working on various research projects over the years. Some were bigger, others smaller. However, at some point, we needed more than just weekly presentations to share the insights from our research with our clients. We needed a way that allowed us to centralize and structure the research insights and observations, especially on long-term projects. This solution should also allow us to share research insights with stakeholders.

In the next 6 weeks, we’ll post a new article every Wednesday to cover everything you need to know about research repositories for UX research.

• What is a research repository?
• What are the key guiding principles for Research repositories?
• How to build one that fits your needs?
• How to get your teammates on board?
• How to build-up a research system with Airtable?
• And last, but not least - how to keep the research repository going once you’re up and running?

What is a research repository?

A research repository - or research library - is any system that stores research data and notes which can be easily retrieved, accessed, and used by the entire team. Let’s explore the three key important elements of this definition.

1. Storage system

Such a system represents any tool you use to store and organize your research data. This can take different shapes and structures. It can be an all-in-one tool, a file-sharing system, a database, or a wiki.

2. Research data

Any bit of information that contributes to understanding your users can be considered research data. It doesn’t matter what the format is. Research data can be text, images, videos, or recordings. It can also be notes, transcripts, or snippets from customer feedback.

3. Ease of use

Ease of use means that anyone in your team can access, search, explore and combine research data. This includes developers, designers, customer success representatives, or product managers. Any one of them can access the research repository to learn more about users. The researcher is no longer the gatekeeper for understanding users.

Since it’s a massive collection of research, the research repository is also the team’s go-to place for learning about users and their pain points. Instead of searching three different locations for reports, all research information is centralized in one single place.

Fun fact: classic research repositories are in fact used in academic environments. Especially by universities that perform a lot of studies. In that setting, a tool that helps you organize all the research is essential.

What has changed? How have research repositories become a thing for UX research?

Two things happened. 

First - companies started doing more and more user research. This means more studies, more reports, and a whole lot of information that you cannot really access unless you know who worked on what. 

So, let's say you wanted information about some secondary insights from a past usability study. In the current report-heavy setup, you would have to: 

• Find the researcher who ran the study. 
• Reach out to schedule a call or a meeting
• Hope that they remember the answer for your question.

Realistically speaking, that would take at least a day - if not more. 

Or - if you’re the one who performed the research, you’d have to go through many different reports until you find the one you’re looking for. 

The second reason how research repositories became a thing can be attributed to Tomer Sharon - now Managing director, Head of user research at Goldman Sachs, then VP, Head of User Experience at WeWork ran into a similar issue. To solve it, he came up with a new approach, based on atomic design principles. Tomer applied those to UX research, breaking down reports into small, easily digestible bits of information. That pretty much led to what we now call research repositories.

Why do you need a research repository?

We briefly touched on these points when we wrote about how if research piles up, it’s hard to track down information. Also, standard reports become hard to search for after a while.

That’s not the only problem with reports. Really, we have LOADS of issues here:

Searchability

The biggest problem when you have a lot of reports is searching through them. Often, the report content is not accessible by search. This means that you have to shift through a lot of documents to find the one you need. And this is the case for pretty much any file management system you’re using: Dropbox, OneDrive, Sharepoint or Google Drive to name a few of the most popular. Additionally, if multiple files match the phrase you’re searching for, you have to check a few of them to find the one you’re looking for. This becomes more of a problem as new researchers join and they have to search through other people’s reports.

No one actually reads reports and they get lost

Even if they're the go-to format for sharing research results, reports often go unread. What’s more, they have a short shelf-life after the deadline passes for turning them in. Usually, after they’re reviewed, research reports get lost in Google Drive, Dropbox or whatever document management system you’re using. If they don’t get lost there, research reports end as an attachment in a full inbox or in a chat window. Now, the problem is that none of your teammates would think about searching there in case they want to learn more about users.
Reports are disconnected from the raw data
By definition, reports present the conclusions or the findings from a study. More often than not, this means they leave out the raw data and the evidence that supports those findings. For skeptical product managers or executives, the lack of hard proof can make them doubt the conclusions since there is no hard evidence present in the report.

Secondary insights get lost

The main purpose of these reports is to answer the initial research question. In reality, while you’re running a study, you probably find additional insights and observations. These could be very valuable later on. But if you don’t have a system to track them, you cannot reuse them. Still, it's pretty much a Catch-22 situation. If you add the secondary insights, you might distract attention from the main research objective.

Comparing insights

Currently, there is no widely accepted standard for what a research report should include from a content or format perspective. Yes, there is a generally accepted structure for reports: introduction, methodology, results, and conclusions. But right now, one report can feature videos while the other can contain just screenshots. This makes it hard to compare information from different reports. If they're not formatted in a similar manner, it's almost impossible to see whether observations or insights from different reports are connected or different.

The next big problem is silos within departments. Whether they know it or not, every department collects information, one way or another. Customer success learns about the users’ problems during help chats or calls. Sales probably do the same on pitches and sales calls. Most likely, marketing and analytics also have a fair knowledge of users. And as Tomer Sharon suggests, they’re probably all doing surveys without the others knowing. Don’t laugh - there’s a big chance that that’s true.

Now, by default, each of these departments presents their findings every now and then in a report or over an in-person presentation for upper management. And we’ve talked earlier about what are the problems with reports. There’s one more big issue with silos: that no one connects the dots between the different bits of information that each department collects. It’s a bit like that old saying: you walk through the forest, looking at trees one by one. In this case, you can not see the forest because it’s broken down into too many trees.

Last but not least, we have repeated research. This happens in two situations. First, when a new researcher joins the team and they start performing studies. Chances are they will come back with something that’s already known. This is understandable in a way - they’re new to the team and they didn’t know. But for experienced researchers, this is mostly a waste of time as there’s nothing new there. Additionally, in time, this can chip away at the effectiveness and the usefulness of performing user research. 

The second situation is where someone - either a product manager or a designer asks if anyone has information about a specific topic. If it hasn’t been too long since the study, probably someone will answer that they do. However, it will take some time to track down the information and see if it can be used to answer that particular question. If the results of the original study cannot be repurposed, that means going back to square one to answer the new research question.

Besides repeated research, you can also have lost research. If you have mainly a research team of one and they leave the company, the knowledge about reports mainly goes with them. 

Ok, we’ve covered all the reasons why you need a research repository. But how will one actually help you?

How research repositories help?

Research repositories save the day in a number of ways.

It’s the #1 go-to resource for learning about users

Having all the research knowledge in one official place will make it easier to actually find information about users. You don’t have to wonder where the information is. You know where to go look for it. No more searching for reports across Google Drive, Dropbox, inboxes, or chats. Also, this can be helpful for newcomers to the team.

Speeding up research

Whenever you have a new research question, you can start by reviewing existing data. Since it’s all organized according to tags, you don’t have to go through multiple reports to find it. This way, if there’s relevant information, you get the answers faster.

Get more value from original research.

If research observations are no longer tied to report findings, they can be reused to answer other questions. Of course, if they’re relevant. This builds on the previous point of speeding up research. Also, it allows you to get more value from original studies.

No more repeated research.

As reports get buried and lost in file-sharing systems, so does the information they contain. We briefly mentioned this before. But you’re probably familiar with the situation. Someone performed a study on a feature at some point. Let’s say that another person joins the team and wants to learn about that feature. Without any knowledge of existing research, researchers start a new study for the same question. If, on the other hand, all the research data is centralized, you can see what questions have already been asked.

Enable evidence-based decisions.

Probably this is one of the biggest wins for a research repository. It allows teams to see the big issues that need to be solved. Also, teams get to see on their own, how these issues come up. On top of that, they can now use that data to prioritize projects and resources. This makes it easier than using gut feelings or personal opinions.

Anyone can learn about users.

By default, the researcher is the person who knows everything about users and their problems. A research repository opens up this knowledge to anyone who is interested. With a bit of time and patience, everybody can get to know users.

You can prioritize your roadmap

Putting all the data together will give you an overall view of the user experience. This, in turn, will help you see what areas you need to prioritize on your roadmap.

Yes, it takes time and resources to set up and maintain a research repository. But the benefits are clearly worth that investment. Even more so since information, along with access to it are essential for high-performing teams. 

And this is not only about research. It’s also about building trust and transparency across your team. It’s about giving them what they need in order to make the right decisions. 

Now that we have talked about how important research repositories are, let’s see when you should be using them.

When to use a research repository

There are two main situations when you really should be using them: In the case of long-term, ongoing research, and when there are multiple researchers on the same project

Long-term, ongoing research

Usually, this happens for in-house research. It can also happen if the user research is outsourced to an agency. For long-term, ongoing research, data will start to pile up at some point. Once it starts piling up, it will become harder to track down information. Also, we’ve talked about problems that may come up if you rely only on reports. In this case, you definitely need a solution to organize and structure all the research insights.

This is the first big case when you should definitely be thinking about a research repository. Even if you’re a team of one and you’re the one performing the research, it might be a good idea to start promoting research repositories. Talk to your manager or your team, explain why it’s useful and how it will help you in the long run.

There are multiple researchers on the same project.

This can be either a short term project or a longer-term one - it doesn’t really matter here. When there are multiple researchers working on the same project, they need a solution that would help them put together all the data. With a research repository, you can put together all the observations. Even if the two researchers talk about their findings, using a research repository increases the chance that important data won’t be left out.

There are also cases when setting up a research repository may not be the best idea.

• Short projects with only one researcher.

What do we mean by a short project? Basically, anything up to a month. If it’s a one or two-week long research project, the amount of research doesn’t justify the time you need to set up a research inventory. Again, the case against research repositories is even stronger if it’s a research team of one. In this case, the time and resources needed to set up a research repository will be much better invested in actually performing the research.

• During an ongoing research.

If you’re performing minimal user research every two to three months, you probably have a small amount of information. Research repositories are great for organizing large amounts of data. However, if there’s not a lot to begin with, then a research repository is not needed. 

Remember that a research repository is a tool. Its purpose is to help you structure research data so you can reuse it. If it doesn’t serve your team’s needs, don’t add it just for the sake of having a research repository or being up to date with the latest trends. The truth is that setting up a research repository will take some time. For ongoing research, especially for an in-house setting, the effort is totally worth it. When you have a large amount of data to go through, an organized system will make the task a lot easier.

Now that we see when it is beneficial to use a research repository, and when it is not, let’s talk about the principles behind research repositories. 

Popular examples of UX research repositories

To get a better idea of what a research repository looks like in practice, let’s take a look at a few examples.

WeWork’s Polaris
This is probably the most popular example out there. Built to meet the internal research needs at WeWork, Polaris was built using atomic research principles. The core of the system is the nugget - and we talked about this in an earlier lesson. Polaris had two major goals. The first one was to help teams prioritize projects according to data instead of a gut feeling. Its second goal was to democratize research by allowing all WeWork team members to explore existing data. What’s more, team members could also add new nuggets or create and share playlists of interesting nuggets. When it launched, Polaris contained over 4000 nuggets collected from various interviews and it was available internally to anyone who wanted to explore it. (link to article)

Uber Kaleidoscope

Uber’s research repository brings together data from all its teams around the world. What’s more, it integrates observations both from science-based discipline as well as from operation-based roles. According to Uber, all insights are valuable. With this in mind, the main goals behind Uber’s Kaleidoscope were to enable information sharing across teams from all over the world and to inform decisions about how projects and resources should be prioritized. In creating the research repository, the team in charge followed the step-by-step process. They started with an MVP using an external database, tested, and iterated on it. Once they arrived at a stable solution, they integrated other internal collaboration tools to facilitate working with insights. Their nuggets come with a predefined format: an insight statement containing who + where + what + why happened, accompanied by facts, evidence supporting the statement, and potential solutions for that insight. The repository also features two main roles: insight creators and insights consumers. For more details, check the link in the recommended links section. (link)

Microsoft’s Human Insights System also known as HITS
According to a June 2019 article,Microsoft's research repository contains 5560 articles, 15185 links, and 221 component networks. Yes - that's an extensive resource about the company's products, users and their habits. Still, the system supports flexible search so its users can make sense of all that info. It also allows them to build upon existing knowledge, which is great. Like the other examples, Microsoft's HITS is accessible across the company. (link to article)

GitLab’s UXR Insights repository

GitLab’s research team started with a team of 1 in 2017. Back then, research was mostly feedback that came from different sources. Since then, research grew to a project with more than 50.000 issues. Reports weren't efficient - we talked about that in a previous video. So GitLab decided to use its own tool to build a research repository. They made small changes though. Instead of nuggets, they use the platform's issue functionality to report observations. Also, they’ve adjusted other default GitLab features to organize these and to tell which research projects are ongoing. Sarah O’Donnell shared their experience on the GitLab blog. You can find the link to that post in the recommended reading section. (link to article) You can preview the research repository yourself (link to article)

Also, Aaron Walter - director of user experience at Mailchimp has a nice case article on how they built up their internal user research repository. If you’re interested in how they did it, check out the link in the recommended reading section (this is the link to the article)

So, with this lesson, we’ve covered the most important the theories of research repositories.

Now let’s see how to get started in building your own research repository.