How can you make user research accessible to cross-functional teams?

No matter how big or small a research project is, it's always good to create a research brief at the start. This should have some kind of back ground on why you're doing the research. A list of goals and objectives for the research. It's helpful to also add in any open questions or hypothesis that the research will answer or validate. Then based on the type of research that is provided next, you can expand the brief to include user demographics, any assets or URLs needed, test questions (that the team can comment and add to), repository location (or related Slack channel), and even a rough timeline so your stakeholders will have a clear understanding of what the research is, how it is being done, and when to expect the report.

Making user research accessible begins with defining clear goals and identifying your audience. Understand the primary questions your research aims to address, the assumptions to be tested, and identify key stakeholders and decision-makers who will benefit from the findings. This clarity allows you to tailor your research methods, scope, and timeline to ensure the results are relevant and actionable for all involved teams, facilitating better alignment and informed decision-making across the organization.

In a previous project, we initiated user research without clearly defined goals, leading to confusion among team members and inconsistent outcomes. This highlighted the importance of establishing clear objectives before diving into research activities. I've found that aligning research goals with business objectives and stakeholder needs enhances the relevance and impact of research outcomes, facilitating more informed decision-making throughout the product development lifecycle. Clearly defining research goals and audience parameters upfront not only ensures research efforts are focused and efficient but also promotes collaboration and alignment among cross-functional teams, ultimately leading to more successful product outcomes.

First, figure out what you want to achieve with your user research. What questions do you need to answer? Who needs to know the results? Maybe you want to know if users like a new website layout or if a product feature is useful. Next, think about who will use this information. It could be designers, developers, or managers. Once you know your goals and audience, you can plan how to do the research and when to do it. For example, if you're making a new app for dog owners, your goal might be to find out what features they need most. Your audience would include the app designers, developers, and anyone else involved in creating the app.

Based on my experience, a recommended approach to initiate your research is to systematically outline key elements such as background, desired outcomes, research methods, considerations, and potential results. This structured approach aids in clarifying your research objectives and refining the focus of your inquiry. Additionally, it provides a foundation for effectively communicating your research across various cross-functional teams in the long run.

Selecting appropriate formats and tools is essential for making user research accessible to cross-functional teams. Tailor your presentation methods—like reports, dashboards, personas, journey maps, or video clips—to effectively convey user behaviors, needs, and challenges. Utilize online platforms such as Miro, Airtable, or UserTesting for creating, storing, and sharing research artifacts. Opt for formats and tools that ensure clarity, engagement, and actionability, enabling all team members to easily understand and apply the insights in their respective domains.

To make user research accessible across teams, distill findings into easy-to-understand summaries, store documentation centrally, and offer workshops to educate on interpreting insights. Encourage collaboration, use visualizations for clarity, and integrate findings into existing tools and processes. Regular feedback loops ensure ongoing refinement of accessibility and usefulness.

To help everyone on the team understand user research, use different formats and tools. For example, you could create reports, personas, or journey maps. You could also use online platforms like Miro or Airtable. The goal is to make the information easy to understand and useful for everyone. For instance, imagine showing a video clip of a user struggling with a website's checkout process. This helps the team see the problem firsthand and come up with solutions together.

Your tool choice should flow from your scope and your audiences. If you are delivering to Designers, use output formats that make sense to them. This is what follows from defining a scope and key audience stakeholders - you then have to go and define with them what success looks like, what sorts of outputs they will want, and how this will feed into the next steps of their work. Hopefully your stakholders have thought through what they really need, but you may need to have overlapping expertise with them to help the do so.

No. Free. Work. The sea was unusually wavy, When a cook in the Royal Navy, With a roll of the ship, Accidentally slipped, Inundating his captain with gravy. He spends one more day in his bed. To-do-lists run all ‘round his head. Noon came and then passed, he’s still on his ass. A hard day of work, he most dreads! “If man had created man, he’d be ashamed of his performance.” – Mark Twain One day, I’ll fin’lly align This horrible, putrid design; I’ll start at the crown, And work my way down,” Said the sheep at the end of the line. Sometimes my work is the pits - Designers popping their zits With consummate art They burp and they fart … I still love my job to bits! No free work!

Involving cross-functional teams in research is integral to promote across your organization of the importance of doing research. Having non-researchers sit in on tests you're running with users, watching replay sessions, as audience members when presenting your research or even actively participating in the research can showcase key insights uncovered from testing or hearing first-hand from users providing feedback on a particular flow or feature. Having other teams involved and as a part of the research will aid to build credibility and confidence in the value of doing research.

Stop asking me to "collaborate" in your corporate initiatives for free. You should consider a different way to request help from professionals. If I want to collaborate in writing a professional article, this will not be for a LinkedIn article in exchange for a badge.

I strongly advocate for incorporating multiple teams in the research processes. For instance, when testing a second iteration of a prototype, it is crucial to engage other teams influencing the project, as well as stakeholders. Their firsthand observation and note-taking during the testing phase can save valuable time and contribute to successful buy-in when needed. Additionally, I have partnered with Business Analysts (BAs) during user feedback sessions to enable them to witness the feedback directly. This approach has proven effective in facilitating buy-in from technical teams based on the observed feedback.

You have to balance stakeholder involvement with the comfort of those involved in the interviews. Therefore it is wise to get interview sessions booked in in advance and then set an attendance limit for each interview. Then you can publicise this to stakholders and have them choose which sessions they attend (and note-take). This can be achieved with something like a Polly poll in Slack for instance.

To help everyone understand user research, try telling stories instead of just showing data. Stories bring out emotions and make things easier to grasp. For example, you could share a story about a user struggling with a product, and how improving it made their life better. Use simple language, pictures, and examples to make it engaging for everyone in the team.

It is actually worth studying creative writing and character development and story arcs. Personas make so much more sense when connected to a story arc, even a day in the life. This is a way to connect personas, service maps, use cases and decision moments more meaningfully, so use narrative theory to connect the dots between your outputs.

At the start of my research, I will meet with the Product Manager to review the product brief so that we can align on the type of research needed and any product goals or objectives to keep in mind for the research. Often this includes the PM outlining the feature(s), functionalities or flows required, and any gaps in the current experience that the feature(s) will hope to enhance or optimize the user experience. In my analysis, I will then ensure that any insights found are mapped back to the goals and objectives or if it directly relates to any of the items noted in the product brief. Also, If you can make a checklist of items that the research needs to cover, it can make it easier to then determine what kind of research you need to do.

Part of the debrief means returning to your pre-discovery work where you connected the scope to the wider strategy, in order to contextualise what you have learnt in that wider landscape. Keeping the true north of the wider meaning of the project, also helps you keep a red thread through your storytelling narrative, so that all you reporting elements are aligned with this.

Ensure your narrative is cohesive by incorporating both qualitative and quantitative data to support key points and findings. At a leadership level, customize research presentations for each specific team, especially when seeking buy-in or investment for project continuation. Tailor the content to address the unique concerns of each team; for instance, highlight cost considerations for the finance team and delve into technical implications for IT. It is crucial to consistently bring the presentation back to core business objectives to maintain alignment across all stakeholders.