Perfecting the art of the UX Research report

There’s a lot of debate on what makes a good user research report and if a report is even necessary. I’ve heard the argument that if stakeholders are involved throughout the research process, then a report isn’t needed. Or if your raw data is clean, tagged, and easy to find, then stakeholders can simply look at it themselves.

Well, I’ve found that a good report is useful. Even with super involved stakeholders and perfectly accessible raw data, a report still helps everyone easily get their heads around research findings.

There are different elements that make a report “good.” I’ve written or edited about 150 reports in my current role. It turns out that the maturity of the research practice in your organization is what determines the type of report that makes the most impact. And good reports are part of what helps a research practice mature.

The Collaborative Document

Context: At this time I was the only UX researcher at the company and research was a new practice.

At first, I wrote collaborative reports. I often had designers, product managers, or other team members observe test sessions. We’d all have a copy of a research plan, and after the session we’d all debrief and write our own answers to each of the research questions. I’d clean up the answers so that they represented some sort of consensus. Then I’d share the end product with the team. These reports looked like this:

1. Driving goal and research question
2. What we did to answer the questions
3. A question-by-question breakdown, with personalized answers from each team member

Pros:

• Simple and quick! We often wrote the bulk of the report during the debrief after the test session.
• Collaborative!

Cons:

• Outside the team, these documents were meaningless. They didn’t provide enough context for someone unfamiliar with the project to understand the main insights.
• The report didn’t tell a story. The simple question-and-answer format felt all-over-the-place, especially when the research questions were seemingly unrelated.

The Fun Slide Deck

Context: I was evangelizing the value of UX research around the company and finding allies.

It became increasingly clear that folks outside the product team needed to understand the research reports. People were interested in how the work of one product team applied to larger company initiatives. These people needed something quick and easy to read, with a clear explanation of the research and why it was conducted.

I started creating research reports as fun slide decks. I split parts of the research process on to different slides to make the whole thing easier to digest. The structure of these decks usually looked like this:

1. Goals
2. Methodology
3. Answering the Research Questions
4. Emergent Findings
5. Recommendations and Next Steps

I separated “Answering the Research Questions” and “Emergent Findings” to help non-researchers see that user research can uncover insights that are not related to the research questions but still valuable to the goals of the project.

I also focused on how these decks were shared and presented. I had a copy of the deck that served as the formal report, and another copy that was the presentation deck. During the presentation I’d involve stakeholders in activities like “guess the finding” (something I learned from Tess Rothstein). Or I’d let stakeholders look under the hood and see the raw data. (I gave a talk about this report and presentation style. See the slides here.)

Pros:

• Stakeholders understood the process and the importance of the research.
• People actually read the whole thing.

Cons:

• The decks got very long, very fast.
• I had to cut a lot of good, relevant detail to make the information fit on slides.

The Not-Quite-White Paper

Context: At this point, I’d hired a research team and we were conducting rich research across the product lifecycle.

After presenting one particularly enormous deck, a member from my team suggested we go back to writing documents. The appetite for research had grown. The research questions were broader, larger, and more important to the business of our company. We needed to take care when proving our methodology and explaining our findings. We started writing rigorous papers (with footnotes, graphs, and other things that made me feel like I was back in grad school). We worked on the aesthetics of these reports, choosing fonts and colors that made them inviting instead of daunting. And people read them!

Pros:

• No important information was skipped.
• Reports felt like narratives. We were able to tell the story of our research.

Cons:

• They were hard to write (lots of proofreading and writer’s block).
• Key stakeholders would read them, but no one else would.

The Insights-Forward Report

Context: The user research team is a trusted entity. We spend less time evangelizing and more time building our capacity.

So here we are, many reports later. We have lots of allies to work with and lots of research questions to answer. Stakeholders want information from users just-in-time and on-demand. In a climate like this, the long deck or report doesn’t cut it even with a succinct summary at the beginning. So now we’re creating “insight-forward reports” where the report starts off with actionable, bite-size takeaways. The methodology section is shorter and the supporting user quotes are picked more carefully. This report can be a deck or a doc; what matters more is that the spotlight shines on quick insights instead of answers to research questions. The structure of this report looks like:

1. A list of key insights
2. Goals of the research
3. Each insight contextualized with supporting details or user quotes
4. Recommendations
5. Appendix: methodology and research questions

Pros:

• Stakeholders get the most important information upfront.
• There is a sense of usability. Product and design folks know what to do with this information.

Cons:

• If your company doesn’t completely trust the value of user research, a report like this will just elicit questions like, “But how do you really know that’s true?” or the dreaded, “Don’t you need a bigger sample size?”

I’ve had success with each type of report, but it all depends on organizational context. If your organization is brand-new to research, then it’s more important to get your colleagues to witness user testing than it is to hand them a nice report. If your organization understands and trusts user research, then the most important thing to do is give your colleagues actionable insights.

If you can identify how mature research is in your organization and how much stakeholders understand and trust the research practice, then you can write the type of research report that will be most effective. In turn, a good report will build trust in research and cause your research practice to mature.

‍