How to find the right UX research repository in 5 steps (with evaluation template)

You've decided you need a user experience (UX) research repository, but you’re not quite sure where to start, and the number of software vendors and tools seems overwhelming. How do you find the right tool for your team, so you can keep your research organized and easily accessible to every stakeholder?

We're here to help. The 5-step evaluation process in this article gives you a structured way of finding the right and best digital tool for your team.

How extensive the evaluation process will be for your product team depends on the size of your organization and the number of people involved. It may take just a day to decide for a research team of one, but can last several weeks in a large enterprise or business.

So let's get started!

Note: we recommend following the five steps of the following process chronologically, but you may have to go back to earlier steps in some cases. For example, if you learn about an interesting aspect of a repository during a demo that you didn’t think of before (in step 4), you'll want to add it to your requirements list (back in step 2). Some flexibility is helpful here.

1. Define and prioritize your goals

A common mistake when choosing a user research repository is jumping straight to the tools and starting a comparison. But comparing repository tools is hard if you’re not clear on what to look for.

Instead, start by defining what you want to achieve with the repo. Having strategic goals is a crucial step in product development that helps your team understand the functions and benefits of a UX research repository. 

Then, set up a document to put your goals in writing. Here's a free goal and evaluation template from Condens that you can use, including the most frequently mentioned goals UX researchers have for a repository. Make a copy and fill it with the information you gather throughout the process:

Columns A–C: preliminary goals

A key element of the template is column B, which states the goals the repository should serve. A goal consists of: 

1. The desired result, for example, centralize existing research data

2. The end goal’s benefit, for example, to answer questions from colleagues more quickly

Simply delete the rows in the spreadsheet that contain goals that aren’t relevant to you and add goals that haven’t been listed yet.

Column A describes the overarching function a respective goal belongs to, which can help you organize your goals into categories so you can easily spot and prioritize them. 

Then, use column C to describe expected changes and desired results as concrete examples, potentially referring to concrete roles or scenarios from your organization. The template includes some example references, which you can easily adapt or change to fit your product and market.

Keep in mind: it's important to get buy-in and input from your team and stakeholders early on. Based on your initial draft of goals and use cases (what you fill in and select in columns A and B), you'll know who will be working with the repository and who will be affected by it. Beyond researchers, this can include designers, product managers, sales colleagues, and more. Keep reading to learn how to use column D to note the people involved.

Column D: involve the team and stakeholders

Next, talk to the stakeholders you identify in column D—ask about their pain points, stories, and goals with UX research. It might also help to conduct a stakeholder analysis at this stage to ensure buy-in and support from executives and investors. Involving stakeholders helps to see things you might have missed and increases acceptance once the repository is implemented.

When you involve your team and stakeholders at this stage, it's helpful to be as detailed as possible. For example, if you want to make it easier for stakeholders to find existing research, ask about the last time they tried to learn something from existing research and the research methods they used. Try to discover what a repository needs to offer so stakeholders can use it to reach their product and business goals.

Continuously adapt and refine the spreadsheet according to stakeholder input. You can also add a priority ranking by putting the important goals in the top rows and the less important goals below.

2. Identify your team’s requirements

Now that you have an idea of what the repository should help you do and who to involve in the process, the next step is to think about how to meet the team's needs. Perform a gap analysis to consider: 

1. The repository tool itself, and the features the software needs to offer

2. The changes in workflows and habits of the people involved. The larger your organization, the more relevant this aspect will be.

In the template, use columns E and F for each of the two requirement types:

Columns E and F: identify requirements

Column E concerns the capabilities of the tool itself—which features does the tool need to have? Again, be as detailed as possible, and consider things like accessing possibilities for stakeholders and how easy it is to share findings.

Next, column F describes workflow changes: what needs to change compared to the current process? What new tasks do you need to plan for, which procedures will change, and which tasks will disappear? Thinking about the challenges of product management will help you here.

The template includes example answers in columns E and F. Filling out these columns properly—and in collaboration with stakeholders—will help your team discover potential blockers or hurdles early on.

3. Create a shortlist of tools

Now you have a good foundation based on your team's needs, you can start looking for research repository tools. 

Start by checking lists of popular and reviewed tools from sites like G2. This quantitative research gives you different insights from UX designers and product teams. From there, you can create a long list of possible tools, then narrow it down by checking some of your non-negotiable or crucial criteria listed in Column E. 

Try to get to a point where you've only got two or three SaaS (software as a service) vendors to choose from, then do a more in-depth evaluation (keep reading to learn how).

💡 Pro tip: a question that frequently arises when shortlisting tools is whether to get a general-purpose tool, like Confluence or Notion, or a dedicated research repository tool. 

There's no right or wrong answer—it depends on your product and company goals and your team's specific needs—but here are a couple of things to consider: 

• The main advantage of a general-purpose research repo tool is that typically everyone in your organization already has access, so there's no need to add another tool to your stack, or onboard the team to anything new. 

• On the other hand, a dedicated tool for research can support your team beyond simply storing research data and is specifically designed to organize and structure UX data, including ways to search, cross-reference, and share.

4. Use demos and trials

With the two or three vendors on your shortlist, you can now collect more information. The tools' respective websites and help centers should give a good overview of their capabilities—but to tailor your search, contact their sales teams and share your specific goals with them to learn how their tool will meet your product and user needs. This step is where you will conduct usability testing to determine if the tool is a good fit for your team.

Use page 2 of the goal and evaluation template to structure your evaluation.

The first row is for entering the respective vendor’s name. Then, the template has two main categories: 

1. User experience, which evaluates how easy and fun it is to use the tool

2. Functionality, which evaluates whether the tool provides the features you need to accomplish your goals

Beyond the scores (1 is worst, 5 is best), also use the comments section to capture qualitative aspects of each tool.

We recommend you evaluate tools as a team, as employee feedback will help you make a choice that works for everyone. You can either fill in the sheet together, by blocking some time in your calendars to demo the tool as a team, or let each team member and stakeholder evaluate the tools asynchronously. 

Either way, have each person enter their impressions into the evaluation template so you can keep everyone's information in one relevant spot.

You'll find three more categories for evaluation: 

1. Security  and privacy are usually a question of 'OK' or 'not OK', and require the involvement of your security or legal team

2. Support and onboarding consider several aspects, like the scope of support and onboarding services included in respective plans; available channels to communicate with the vendor; or even time zone differences to ensure sufficient overlap during a workday

3. Pricing is (surprise!) about the tool’s cost for your team

Most tools offer a live demo to help you understand how the tool would meet your product requirements and achieve your business goals. We also highly recommend making use of any free trials that the tools offer. Ideally, you should use actual research data with a free trial (if your legal team allows it), which is the best way to assess whether the tool is right for your team.

5. Assign team roles and make an onboarding plan

After collecting information from demos and trials, it’s time to make a decision. You may want to set up a short meeting with the team, your manager, and other key stakeholders to discuss their feedback and make the final choice together. Cross-functional collaboration helps improve team alignment on the plan throughout the research process. 

Once you decide on a tool, assign someone to be responsible for implementation. This concerns purchasing the tool, defining data structures in the repository, coordinating migration of existing research material, providing access to all users, communicating the repository within the organization, and ensuring everyone is properly onboarded. Getting clear on these roles is especially important for onboarding and working in remote teams. 

Remember, introducing a repository takes time, and a proper implementation plan is critical for success. You don’t have to implement each goal right from the beginning—consider the ranking of goals (from Step 1) and focus on your most important goals first to make the task of implementing the research repository more manageable and create momentum.

Finally, assess the value of the repository after some time by benchmarking what you achieved against your initial goals. Ideally, you've defined success measures and metrics upfront (see column G in the template). Now you can collect data on these success measures, identify if you’ve achieved your goals, and determine where there's room for improvement.

FAQs about a UX research repository