Rethinking Research Reporting: A 5-Step Guide for UXRs

Many UX researchers now work on a product or design team, surfacing the insights needed to inform decisions for a specific feature or experience. This integration is a welcome change to UXRs previously siloed nature, since it provides proximity to stakeholders and, with it, elevated knowledge of what data is needed, in what format, and when. However, due to improvements in platforms and technology including AI, product teams are designing, building, and shipping faster than ever before. In turn, the window of opportunity for research to shape this process is narrowing. 

Over the past few months, I’ve been talking to professionals involved in research across product, design, and operations to see how they’re adapting to not only this new positioning within organizations, but the new associated time crunch. A common theme I’ve come across: While recruitment, fielding, and analysis cannot be compromised, traditional reporting is antiquated. 

To put it simply, the “juice” of a longer-form, traditional UX research report–especially for evaluative projects with clear outputs and results that may not require much additional context such as usability tests–is not worth the “squeeze”. Time is better spent actioning on insights.

Of course, insights and findings still need to be communicated, so how can folks adapt their UX data into actionable outputs for stakeholders and leaders? I have some tips(!) that I’ve picked up in conversations with other professionals, but before I reveal those, let’s dive deeper into the context researchers are now reporting within: 

Maturity

Product, design, and engineering workflows are very different from the academia-informed workflow of research. As a result, researchers have worked to better integrate into these workflows, maturing their understanding of the business along the way. For maximum impact and legibility, researchers have found ways to translate many of their key concepts and indicators into business terms: Instead of methods, they’re talking revenue; instead of fieldwork, it’s OKRs and KPIs; and instead of “How might we?" statements, it’s “Here’s what I recommend we do.”

Awareness

Just as researchers have matured their understanding of the business and the teams they now sit in, so too have their collaborators, grasping foundational research principles through initiatives like democratization and enablement training. Now, internal consumers of research insights often don’t need the full account of background, methods, etc., often included in reports. Stakeholders often just need the results and can formulate the “So what?” and “Now what?” on their own. 

Learn how to quickly turn UX data into actionable outputs for stakeholders and leaders with our free course, Business 101 for Researchers

Report: Now a verb, not a noun

Reporting is still a valuable part of the research process, but the shifting context in which research occurs means adaptations are necessary. Reporting, especially for evaluative research, now requires iterating with stakeholders along the way. As folks across the organization collaborate earlier within the research process, researchers start to hear what information doesn’t make sense without context and what resonates. They also have a clearer understanding of how to connect the data they produce to decisions the larger team needs to make. 

Because of these shifts, some professionals said that research is now more likely to be effectively acted upon when surfaced within the context of a workflow rather than reported in a free-standing document. 

For example, some researchers: 

• Compile notes from live sessions or outcomes from unmoderated tasks directly onto prototypes so designers/PMs can see insights next to the tested design.
• Summarize the most pertinent information into five bullet points (e.g., “We tested this, saw this, learned this, recommended this, are doing this”) to stakeholders via team communications channels or project management software. 
• Have their PMs, designers, and engineers join for interviews or watch unmoderated sessions. Together, they organize notes/themes/observations then discuss and make decisions live as a group.

Effectively, the report has moved from noun—an artifact a researcher creates—to verb—an action a researcher and their team takes.

How to improve your research reports

So how should a UXR “report”? Beyond the requirements that still hold true due to methods or sensitivity of collected data, there isn’t a new industry standard for traditional reporting. Rather, each UXR must build their own process that fits the maturity and awareness of the team they’re reporting to. 

To make this process more concrete, I’ve compiled 5-steps to help streamline reporting for you and your team:

1. Audit your existing report process

Before making any changes to reports, set aside time to interview key stakeholders and research consumers to zero in on what alterations need to be made. Ask what’s working and what’s not. Identify what the ideal reporting function looks like for each party. This includes not only what information to report and frequency of communication, but also the format in which it’s delivered (e.g., written vs. audio/video; asynchronous vs. live updates). 

💡 Learn how to visualize your UX results into comic-like stories.

2. Ditch one-size-fits-all

The readout a researcher provides to another researcher should be much different than the one provided to an executive. Create different sections or versions of the report tailored to each stakeholder group, making it clear what details matter, and pointing them towards consuming additional information they might want to be aware of. 

This allows parties to choose their own adventure and consume more information based on their needs and interest level.

For example, when sharing my research with decision makers, I sometimes opt for a deck with recommendations and key evidence. I include a single slide with 4-5 sentences that summarize the most important results, another slide with an executive summary that provides more detail, and then slides that dive into the nitty gritty insights for those directly involved in tackling any recommendations. Information like the background, method, participant details, or more niche findings are compiled in the Appendix.

Other report types I’ve seen are: 

• Receipts, which are posted in the stakeholder team’s project management space to document a request was seen, prioritized, actioned, and delivered (this always includes a TL;DR of findings and key action items, and also might include the basics of a traditional report, including methods and some raw data)
• Quick summaries, tailored for indirect stakeholders who might want to be updated on findings that further understanding of the customer persona, but whose work isn’t directly implicated. (These are similar to what is known as a “comms update.”) 
• Traditional reports, right-sized to the type of project (e.g., lighter summary and rationale for evaluative work; more description and references for generative and exploratory). 

3. Build your delivery strategy into fieldwork

Being clear about what the end result should look like before you begin fielding data will help streamline the reporting process.

For every report make sure you know: 

1. What was the goal of this research project?
2. Who will need these insights immediately?
3. In what format does that audience prefer consuming?
4. What do I need to compile to create those formats?

Notice #1. Remember #1. Never forget #1. Build the deliverable around the project’s goal and your audience’s preference. Everything included should only highlight and clearly connect your research and the goal of the work.

4. Document based on priority

As any researcher knows, documentation is important. However, all documentation does not need to happen at the same time! A UXR’s primary goal after a project concludes is to deliver recommendations to key stakeholders based on insights derived from user data. After that, the longer-tail process of documenting and creating reports for other audiences can commence.

This will vary by organization, team, and other factors, but the order of operations might be:

• Recommendations and key evidence for most immediate stakeholders
• Receipts for documentation
• Summaries for indirect stakeholders
• Complete reports for documentation and repository purposes    

5. Experiment with your process

Although your tried-and-true way of tagging, compiling, and summarizing results in a start-to-finish report with every piece of evidence might feel good, it may not be supporting your stakeholders. 

Instead, you might try a scrappier way to compile evidence to support your recommendations, like the “notice > mark > clip > annotate > repeat” method. 

• When the study commences, keep the goal in mind and notice when any specific answer or datapoint relates to that goal. 
• Mark these answers or data points as you go. Tag inside interview tools or bookmark quotes in survey open-ends. 
• Then, make scrappy clips from usability software or other exports/links to include and annotate where relevant in stakeholder sharing. For example, you can pair your “Here’s why I think we should X…” summary with a snippet from an interview or usability session. 

💡 Use what you have, especially if timelines are really tight.
‍
Many of the ways researchers organize their work—digital whiteboards, spreadsheets, note documents—can powerfully stand in as reports with a summary at the top. 

Finally, there’s AI. Surveys show steady increases in its use, especially for research analysis and reporting. AI can summarize, restate, clarify, and combine your disparate datapoints into something ready-made for busy stakeholders. Don’t offload the hard and important work of synthesizing and digging into the why of the data—that will only dull your ability to make a case for the importance of it. But definitely leverage AI to speed up organizational tasks or refining text.

More resources

• Want research action? Try a research roadshow.
• Here are presentation templates for inspiration.
• No one is listening to your reports—here’s how to change that.