The Ultimate User Research Repository Checklist
Helping your team to store, organize and share research findings and insights shouldn’t be complicated. This Checklist will help you understand the most important aspects you need to consider when implementing an effective UX research repository.
Internal Research and Defining Success Together
Creating a user research repository is less about implementing tools and more about designing better ways to share knowledge and improve decision making.
As part of improving your current processes, you will have to introduce changes; this is one of the most challenging aspects of any organizational project.
Implementing any kind of change within an organization requires a deep understanding of how to engage people with the project, especially those who will directly or indirectly benefit from the change. If your team is already committed to the idea of building a research repository, it’s time to talk to people outside your team.
Your goal is to understand your stakeholder's expectations and how they will use the data you are planning to centralize. To get started with those conversations, here are a couple of questions you may want to ask:
- Do you talk to customers regularly or do any customer research?
- If so, what is your process and where do you store your findings?
- How do you use research findings to make decisions?
- Do you share that information? If so, how?
- If you don’t do research, do you use any research done by other teams? If so, what type of research and formats do you find most helpful?
- Could you tell me the last time you did research or used research data from another team to make a decision?
- Did you share the impact of that decision or your decision-making process with somebody else?
- What are your thoughts on the way research is shared and used in the business? Anything you would like to see improved?
- We are thinking of building a research repository, what do you think could be the pitfalls or reasons for failure for this project?
These conversations will help you identify the gaps in communication and processes that you need to consider when implementing your repository. This is a crucial step in your implementation process and one that can help you define success with your stakeholders in mind.
Audit & Inventory
Mapping Feedback Sources
The type of data you decide to centralize in your user research repository should help researchers connect the dots more quickly, gain more context on the research that has been previously done, and facilitate their analysis process.
It should also help the product team answer questions quickly and build on top of existing insights.
Ultimately, it should help other stakeholders to make better decisions and empathize with customers.
Here are some examples of datasets that can be centralized in your repository:
- Research notes
- Video Interviews
- Support tickets
- NPS surveys
- Testing sessions
- App Reviews
- Short user stories
- In-depth summaries, etc.
Mapping your internal communication channels will help you understand where information can fall through the cracks and identify the most reliable channel to capture your team’s inputs.
It can be as simple as creating a matrix of the teams who provide feedback to the product team, the type of feedback they provide, and the channels they typically use.
Here’s a handy template that can help you map your feedback channels.
Mapping your channels is about more than just reducing information overload for the product team. It’s but also about reducing the anxiety other teams experience about whether feedback has been acknowledged.
Auditing Existing Research
Once you’ve reviewed the type of data sources you would like to centralize it's time to look at your existing research. Maybe you have years of research reports accumulated in on Google Drive or SharePoint or maybe you just got started last year. Either way, you need to check whether or not the research you did in the past is still useful.
You can look at your decks, research summaries, and raw data and answer the following questions:
- Is this still true?
- How is this helpful?
- How much evidence/raw data do we need to keep?
- Are we legally able to keep this data?
- Do we want to bring this data to the new research repository?
The outcome of this exercise is an inventory of the data worth keeping, worth revising, and a list of the data you will be migrating or centralizing in your Research Repository.
Here’s a quick template that can help you do a quick inventory of your research insights.
Define a common vocabulary
Here's one of the most practical masterclasses about building taxonomies for research repositories. Watch Taxopalooza!
When it comes to classifying your data, whether your goal is to help people find documents easily or use a better tagging convention for data analysis, sharing a common vocabulary will set the right foundations for success, and taxonomies are designed to help you do just that.
At its simplest, a taxonomy is just a way of naming and classifying things according to their similarities and differences.
A taxonomy allows you to divide and group a large set of information into more manageable chunks. It helps you visualize how you want to organize your data.
Keep in mind that when you’re designing a system to classify your qualitative data, you aren’t just designing for the output. Your team members are going to have to implement it, so your categories and labels should be unambiguous and clearly understood.
A taxonomy is not set in stone. As you get deeper into your data analysis with your initial taxonomy, new categories and attributes will almost certainly emerge. Qualitative data is rich, and uncovering patterns and themes is an iterative process.
Be flexible. One way to test your taxonomy before you formalize it is to build a treejack exercise using Optimal workshop. Here's an example.
Access & Empowerment
Define the roles and access levels for your repository. Here are a few things to consider:
- How many people in the organization can freely browse the whole repository?
- What type of user will access only high-level summaries vs. raw data?
- Who is in charge of designing and maintaining the taxonomy?
- Are multiple teams able to access all the data or only data that is relevant to their areas of operation?
- Which type of users can submit/upload information to the repository?
- How many administrators do you need and what is their role?
- Who will be in charge of connecting the dots across multiple projects and business units
No matter how automated your repository is, once it's up and running you will need somebody in the organization whose role includes making sure the repository is organized, easy to use, and most importantly useful.
Privacy and security
If your repository is going to store identifiable information about your customers or users, here are a few things to consider:
- Your customers need to know that you are storing that data and where it is stored. Normally this information is communicated in your terms and conditions.
- Your research subjects may need to fill out consent forms accepting the use of their information for research purposes.
- Make sure you work with tools that are GDPR compliant.
Documentation and policies
In the same way that online communities establish guidelines to help their members build an environment where everybody can contribute and benefit, documentation and policies are needed when it comes to building an effective repository.
Providing transparent rules of engagement can help guide users to make the most of the repository and encourage each part of the organization to engage in productive ways.
Make sure your rules of engagement include clear information about:
- How to contribute to the repository
- What type of customer/user information can be stored
- How to request access
- How to share information from the repository to another tools, teams etc
- What labels, tags or categories can be used to organize the information
- How to record new insights
- How to collaborate on information stored in the repository
The rules of engagement will change over time so make sure you keep the documentation up to date and easily accessible.
For inspiration, here's Medium's Rules of Engagement
Selecting the right tool
Here are a few things you should consider when selecting the right tool for your user research repository:
Search capabilities: Team members and stakeholders should be able to search the content of the repository easily. The search functionality should allow for a deep search of aspects like metadata, tags, authors, customers/users and any other type of classification you want to use to label your research data.
Taxonomy management: Since your taxonomy will evolve over time, you want to make sure that you have the ability to manage your labels easily. Consistency is a key part of keeping your repository useful.
Data security: Hosting research data that may contain identifiable customer information can be tricky. You want to work with companies with the highest standards of data protection and security. Make sure vendors can share comprehensive documentation on their data and security practices
Scalability: You want to make sure that as your team and your business grow, you can scale the way you store and share insights. The ability to manage multiple teams and multiple levels of permissions becomes an important part of your tool selection process.
Data formats and integrations: Make sure the tool of your choice can support all the data formats you are planning to centralize. Additionally, being able to integrate your repository with other internal tools that are part of the current workflow may become handy when onboarding other team members.
Metrics and Impact
Design an initial set of metrics
How will you know if your research repository is working and whether it is fulfilling its purpose?
Assessing the impact of research work and insights can be difficult, but if your goal is to understand whether or not centralizing your research data is helping the organization to make better decisions, you can define an initial set of metrics around internal engagement.
Here are a few examples for inspiration:
Number of shares by team members: If team members are sharing information from the repository, they most likely found something of value. You could identify users sharing data and ask them what triggered the share and how the data helped them.
The number of contributions by team members: Users outside the research team who are adding data, research, or any other artifact to the repository could be a sign of trust. They believe it is worth contributing to and that their contribution will be used or helpful to other team members.
Time to insights: If one of the goals of your repository is to help researchers identify insights more easily, understanding the time it takes them to get to insights would be a good indication of success.
Think about your repository like any other product. In order to understand whether or not it is effective, you need to define a metric that allows you to track progress.
Here's a post for inspiration: