Building a business case

Creating a user research repository isn’t just about implementing tools. It’s about designing better ways to share knowledge and improve decision-making. 

As part of improving your current processes, you will have to introduce changes to stakeholders and teammates. This is where things can get tricky. Organizational initiatives can fail when people forget the emotional side of change.

Implementing any change within an organization requires a deep understanding of how to engage people with the project, especially those who will be impacted by the change. 

At this stage, you’re trying to understand and scope the actual project (data and workflow challenges) and trying to identify the hidden agendas within your team (people challenges).

Remember that even if your team is already committed to the idea of building a research repository, you will face resistance at multiple stages, not only within your team but also from adjacent teams. Building an airtight business case will help you navigate some of the inevitable friction more easily.

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 stakeholders:

• Do you talk to customers regularly or do any user 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?
• We’re thinking of building a research repository; what do you think could be the pitfalls or reasons for the potential failure of this project?
• 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? (This can help you understand a practical way to package the information stakeholders use or to identify what type of insights they are looking for)
• Did you share the impact of that decision or your decision-making process with somebody else?
• What are your thoughts on how research is shared and used in the business? Anything you would like to see improved?

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 can help you define success with your stakeholders in mind.

If you're building a presentation for stakeholders, make sure it covers:

• A detailed list of tools and channels your team uses to collect, store and share research data and customer feedback. 
• A robust analysis as to why the current setup is not helpful. This may include data flow diagrams, visualization of all the tools used to share and store information, etc.
• Quotes from colleagues articulating their pain points related to the lack of a centralized place for research data and insights. This may include stakeholders.
• A clear view of how other tools in the stack will interact with the repository
• A roadmap to solve the problem and who will be leading the project
• A clear view of the resources and time required to implement the changes.

Mapping your data sources and channels

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 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
• Transcripts
• 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.

Mapping your channels is about more than just reducing information overload for the team. It’s also about reducing the anxiety other teams experience when they don’t know if their shared feedback has been acknowledged.

Follow these steps and you'll be well on your way to preparing an effective business case that speaks to the concerns of stakeholders and teammates.