Building a research repository?
3 tips to help you navigate some common challenges
Research repositories can add tremendous value to your team’s research practice, but take time to build and maintain. As the first UX research hire at my current company, I spent hours last year researching options on the market and setting one up for my team.
The tool selection process was relatively easy (we went with EnjoyHQ), but implementing it proved to be quite cumbersome.
“How are we going to organize our data? How are we going to elevate particularly insightful findings? How are we going to get team members regularly in the tool?” These are just a few of the things we had to solve for this past year and are still figuring out. Our team is consistently iterating on our repository implementation but there are a few key lessons I learned that I hope can help you and your team on this journey.
Tip #1: Make sure your team has conducted some research before deciding how you want to organize your data
If you’re like me, you may have joined a team that didn’t have a lot of published research yet. A repository means nothing without the data meant to be stored within it. Trying to figure out how to organize your repository before you’ve conducted any research studies is like trying to build a map without knowing any of the streets or highways to include.
From my experience, it’s helpful to have a handful of completed research studies under your belt before deciding on your data organization approach. Another suggestion is to look at your product roadmap as a way to categorize information. If your product team will be frequent consumers of research, organizing studies and insights aligned to product work streams and priorities will probably make it more consumable in the long run.
Tip #2: Create a tagging system for repositories gets complicated quickly; keep it simple to start and build over time
One of the best things about repository tools on the market are the built-in tagging capabilities; but they can also lead to the biggest headaches. It’s easy to fall into the trap of over-tagging because of how easy it is in tools like EnjoyHQ or Dovetail.
It’s important for you and your team to decide how you plan to use a tagging system. Is it just to help in the synthesis process — making it easy to find and reference observations that support a key takeaway or insight? Or, will your tagging system be a way in which you expect teammates and stakeholders to search and find relevant information long after a study is published. If it’s the latter, I recommend starting small and adjusting as needed.
In an effort to avoid over-tagging, ask yourself these questions before tagging a piece of data:
- Will this be something I (or my team) will need to refer back to again?
- Does this support a major takeaway or theme?
If the answer is no to both, it’s probably not worth the tag.
Tip #3: Be a constant advocate and champion for your repository and the data in it
Stakeholders and non-UXRs will likely need frequent reminders on when and how to navigate the repository to find information important to them. It’s easy for the other UX researchers on my team and me to forget how frequently we’re in the repository — whether it’s to add new projects, upload data, or write and publish our summaries. Our partners in UXD, Product and Operations don’t think about the repository (or what’s in it) as much as we do. It’s our responsibility as the gatekeepers to consistently remind others where research lives and when it might be helpful to reference.
One idea for putting this into practice is not to wait until your report or summary is published before you let others in on the juicy data. For example, maybe as you are tagging and analyzing an interview transcript, add a comment for a designer noting an interesting observation relevant to their current project.
Or, when you do publish a summary, don’t just share it once. Identify multiple opportunities over the next few weeks to share and distill information to your core team and any stakeholders involved in the initial planning process. Small actions like these will help keep the repository top of mind for your team.
Building a research repository might feel like a never ending task but my advice is to approach it as you might any other product initiative– launch an MVP, learn, get feedback, and iterate over time.
