The Ultimate UX 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.
Define success together
Creating a 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.
Define the content of the repository and its shelf-life
The type of data you decide to centralize in your repository should help researchers connect the dots more easily, 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
- Customer feedback
- Testing sessions
- Video interviews
- Short user stories
- In-depth summaries, etc.
Now that you have identified what data you want to centralize it's time to look at it through the lens of its shelf-life.
Identify what's worth keeping and what's not useful anymore. Would the user testing sessions you ran two years ago still be useful today?
For example, insights of human behavior tend to have a longer shelf-life than usability testing videos, but you may want to consider storing data that supported those findings in the first place so you preserve the context behind the research work.
Information architecture and general organization
Think about the first-time users of the repository, what would be the most intuitive way to find information on a specific topic?
Would they search for research done in a specific product area? Strategic goals? Hypotheses? Personas? Journey touch points?
Should they access generative research alongside your evaluative research?
Defining a high-level structure for your repository will lay the fundations for your next step, creating an intuitive taxonomy.
READ MOREComplete Beginner’s Guide to Information Architecture
Define a common vocabulary
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.
When we asked taxonomy expert Heather Hedden how she would recommend getting started building a taxonomy, she responded:
"Any taxonomy must reflect both (1) the topics of the queries of the taxonomy users, such as the employees who are using it to analyze data, and (2) the scope and detail of the specific set of content that will be tagged with the taxonomy. Designing a taxonomy requires both talking to the intended users to get their input about topics of interest and looking at representative samples of content to discern common topics and issues. The taxonomy is then built with a combination of a top-down (desired topics of the users) and bottom-up (specific topics in the content) approach".
In other words, it’s important to take into account both the intended users of the information and the content of the data itself when designing your classification system.
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. You won’t really know if your taxonomy is working for you until you and your team start to use it.
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 rolel?
- 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. READ MORE:
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 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: