How we developed our repository strategy 

Soon after I started as the first user researcher at Lightricks, I realized that, though it was too early to have a fully baked repository strategy, I had to develop an MVP.

I had two main reasons for wanting a repository strategy: 

1. Insights were forgotten shortly after I released new ones 

2. Giving stakeholders access to specific data was nearly impossible 

Once we became a team of three, we created the first iteration of our repository using Dovetail. Adoption was low, showing that we needed to understand stakeholder perspectives better before we created the next iteration of our strategy. In this post, I’ll explain how we used internal research to guide our next steps in the hopes that you’ll consider doing it, too!

The first step in our repository journey 

After deciding Dovetail was the right tool for us, one of the researchers on my team explored the platform and schooled the rest of us on the basics. As a team, we agreed that our stated goals for version one of our repository were two-fold: 

• To organize all of our research in a way that was easily accessible for our team

• To give stakeholders easier access to raw research data in a way that was organized by topic (for example, a Product Manager who was working on a specific feature could view insights, interview clips, and data around that feature via tags without having to watch full interviews or dig through project reports) 

We developed a scrappy but functional workflow and began inputting all of our data. We tagged everything by topics that we thought were relevant for the majority of our stakeholders. We had initial ideas about taxonomy and started a Slack channel to discuss tagging situations as they came up. Once we’d found our groove, we presented the repository in Product meetings and also had short one-on-ones with relevant stakeholders to show them how to use the tool to find specific data and insights. 

Initially, the feedback was amazing—stakeholders were excited by a searchable database with user insights, the ability to populate and watch interview clips without viewing full interviews, and so on. So you can imagine our relative surprise when, a few months later, we checked and saw very few stakeholders accessing the repository.

New employees often poked around and even watched some interviews, presumably to learn about our target audience and current users as they eased into their roles. We also saw a few members of the product team had entered a few times, but in a large organization like Lightricks, it was underwhelming.

We were a small research team investing considerable time in maintaining the repository. It was concerning that we had no clear indication that we were accomplishing our stakeholder-related goals.

Beyond the spotty usage by stakeholders, we also discussed the utility of the repository as a research team. Some of us found the process of tagging interviews helpful for our data analysis, and we all really appreciated the practicality of finding relevant clips via tags for our presentations without skimming whole interviews.

We also had a vague sense that having our insights and raw data in one transparent place was important. But we all agreed that for the repository to be worth the effort it took to maintain, we’d have to revisit the strategy with our stakeholders.

As the team lead, I focused on our team’s overall goal with or without a repository: we want our stakeholders to further incorporate research findings and user insights into product development processes. I still had a feeling, and plenty of industry knowledge to back it up, that a repository could play a role in helping us move closer to our overall purpose.

Understanding stakeholder perspectives on the repository 

Before iterating on our repository strategy, we needed to explain the gap between initial stakeholder excitement and subsequent limited usage. I did consider the possibility that people were just being nice, but after going through the feedback that I’d diligently collected in a file, I had a hypothesis that there was a will to use more nuanced information from our projects but that for whatever reason, our current repository structure wasn’t answering stakeholder needs.

We decided to conduct short, relatively informal interviews to understand more from the stakeholder perspective. We spoke with Product Managers, Designers, Product Marketing Managers, and a few others. We asked both broad and specific questions to help us gather insights. Here are a few sample questions from our interview guide.

Does user research play a role in your work? Why/Why not? How?

Can you think of a specific, recent example when you felt you were missing some information about users to make a decision or do your day-to-day work? Did you do anything to fill the knowledge gap?

When you last accessed the repository, can you describe what you remember from the experience? 

If you were describing the repository to a new employee on your team, how would you describe it?

 What we learned from our internal stakeholder research

After analyzing our interview data, we came up with some core learnings about our first version of the repository from a stakeholder perspective. Here is a high-level summary of what we learned overall: 

• Stakeholders across the board aspire to use more research insights and raw research data in their day-to-day work. They can easily identify specific areas where they lack knowledge about users. They can also provide examples of how that knowledge could have improved previously completed work

• Significant barriers related to the repository prevent stakeholders from incorporating user insights in their day-to-day work. The top two are: 

  • There is immense pressure on stakeholders to get things out quickly, and there is a pervasive perception that adding yet another tool to their workflow isn’t feasible

  • Stakeholders are often looking for something very specific. The repository taxonomy doesn’t easily match the questions they’re asking themselves, so they aren’t sure how to find what they need quickly. For example, one Product Manager was working on onboarding. Because the app she worked on didn’t have onboarding, we didn’t have a specific tag in the repository. There is a ton of information in the repository that could guide her onboarding work: different user identities, use cases, and so on—but she wasn’t sure what to look for and gave up.

What did we do with these insights?

Based on our analysis, I felt a renewed empathy for stakeholders and motivation to create a repository strategy that fit within their constraints and advanced our team’s overall goals. I understood that we had one big decision to make before we created actual action items: do we want to adjust the repository and educate stakeholders about how to use it better within their current workflows?

Alternatively, do we want to use the repository for stakeholders when they need information and regard it as a tool for the research team to better deliver the nuanced information that they’re looking for?

I look at our repository and, more generally, our team’s involvement in product development as a journey. After reviewing our data, I concluded that the next right step in our repository strategy is to do the latter.

Currently, we’re working on creating the second version of our strategic plan where we use the repository to make it easier for the research team to serve information that helps stakeholders incorporate more user insights into their day-to-day work.

This approach seems more likely to work within current stakeholder constraints, and it’s educational in that we’re showing the value of the information in the repository as we go. I foresee a time when stakeholders will utilize the repository in a more scalable way, with much less of our team’s involvement. Still, our internal research convinced me that we jumped the gun on making that our initial strategy.

Repositories are iterative and internal research can guide you

Organizations change with time, and user research’s role in product development also grows and changes. Creating and maintaining a research repository isn’t immune to the need to continually check in and iterate on your work. Doing internal research—even if it’s scrappy and lean—can guide you when you aren’t quite sure that your current strategy is meeting needs and moving you closer to your team’s goals.