If you've ever struggled with writing a report for your research project, put your hand up. (I envision that scene in Mean Girls where everyone raises their hands).

I've never met anyone who did research that said report writing was a breeze. We typically view it as the opposite: a terrible slog we must get through that we are concerned no one will read in the end.

And that's the thing. The number of reports I've written that have died in the corner of a dusty Google Drive folder feels countless. 

This process took me years and is something I still work on because, as is the same with users, the needs of stakeholders differ depending on the situation.

Let's break down a research report and what goes into it so that you can stop stakeholders from leaving your research on read.

Four different UXR report types

Before diving into the different things to include in a research report, we must define what a report can be. There are all different shapes and sizes when it comes to reports, and it's important to highlight these, as certain reports can be best for specific situations. 

1. Just the executive summary

An executive summary report is a very high-level recap of the study's most surprising and essential findings or insights. It gives an overview of the outcomes, usually for someone who doesn't have time to read the report. 

I don't use executive summaries as standalone reports because they give people the excuse or idea that we don't need further context and information. I bake executive summaries into my more developed slides.

However, there are some cases for an executive summary:

1. When you’re reviewing what came from the research with people who were there for it and who are competent in the context of the research
2. When you’re sharing research with an executive (hence the name) who wants a recap on what happened 
3. When you have to share more widely what you’re working on and want to hone in on the most crucial findings or insights you've recently uncovered
   

2. The FigJam/Mural/Miro report

This type of report is a step above the executive summary and might have everything in a standard report, but it is laid out differently than something like slides or a document.

Typically, I bring my reporting to Miro in a few different situations:

1. When people have been hugely involved throughout the research, and I don't have to create anything formal for them
2. When I want to bring action to the findings and insights so I use the set-up of a Miro board to review the information and dive into solution-based activities
3. When I don't have as much time to create a more formal report
   

I use Miro for debriefs and synthesis, so if I’m strapped for time or have stakeholders who don't need a formal report, I’ll keep everything there instead of bringing it into a report. 

3. The slides report

Putting a report into slides is an additional step up in formality. Presentations are the most common report types I see from researchers. In this, we take the information from the study and put it into slides.

I typically use slides when:

1. Sharing research with people who have a limited context or weren't along for the ride
2. Documenting necessary research that people might need to go back to or new people might one day read without me present to explain it
3. Presenting research to a larger group of people
   

Putting research into slides is my favorite way to share because it's an in-between stage of Miro and a formal written report, giving me the flexibility to cater to my audience. It also gives me some peace of mind that if someone were to one day look at this research when I'm not there to explain it, they would get enough context (versus Miro or an executive summary).

Whenever I present my research, I schedule an accompanying activation workshop to ensure we collaborate on bringing insights into solution land.

4. The written document report

The written report is the most formal and—despite my love for writing—the one I dread doing the most. I haven't written many formal document reports as a researcher, but the ones I did were enough for me.

However, there are times when lengthy formal reports are necessary:

1. When sharing an incredibly complex study with people who have limited or no context of the study
2. To document a complex study for later or for people who are new to the company that won't have you to present it to for them
3. To avoid "insight distortion," by putting every piece of information into the report
   

These aren't the only reports that exist, but it is an excellent way to break down what type of report might apply to your given situation.

Now, let's look into what should go into these reports.

Report information and structure (+ a template)

Once I understood what I needed to put into reports, the best thing I did was create a few templates. I hate staring at a blank blinking cursor, so having a template reminded me what information I needed to fill in—and allowed me to jump-start my writing by not starting from scratch.

Since slides are the most common report I use and the ones I've got the most feedback on, I will review the information I include in these reports.

1. Executive summary

The purpose of an executive summary is to highlight the essential information as efficiently as possible. I strive to do this in one slide.

My structure for an executive summary highlights the top three to five findings or insights in my study. In general, I’ll cover the following:

1. One surprising finding/insight 
2. One pain point finding/insight
3. One need finding/insight
4. If space, an additional finding/insight

2. About the study/study summary

This section briefly gives an overview of the study and is especially important if you’re presenting to people who weren't part of the kick-off or planning.

In this section, I include the following:

1. Research goals
2. Our expected outcomes
3. The methodology 
4. A brief overview of the participants

3. The findings/insights

The section on findings and insights will be the biggest and most important one. There are three main ways that I structure my findings:

1. Research themes
2. Research goals
3. Affinity categories
   

If you’re structuring your insights by research themes, you report on the insights that came up the most during your synthesis process. Your structure will go one by one through what you found that emerged most from the participants.

If you’re structuring your insights by research goals (my favorite way), your report will list the goal and all the supporting evidence to help answer that goal, whether it be a pain point, need, or any other type of finding. I love this approach because stakeholders find it the easiest to digest as you share how each piece of information helps them answer their goals.

Structuring your insights by affinity categories means you use the overarching categories you used to tag your data to report on them. For instance, if you chose to use global tags, you would report all needs at once, then goals, and then pain points. 

4. Embedding mixed media

I always embedded mixed media within the insights, whether a written quote, audio clip, video clip, photo, or graph/chart.

Mixed media allows you to show people what happened rather than just telling them. It demonstrates the impact of a pain point or a decision someone made. By including this type of information in a report, you up the ante because colleagues sympathize more with the users and are more likely to take action.

5. Recommendations and next steps

None of our stakeholders (to my knowledge) went to "using insights school," which means they sometimes feel lost on what to do after you present the information.

That's why recommendations and next steps are vital to bringing your insights from something in a presentation to a solution.

Since I’m not a designer and never want to make whacky design recommendations or impractical suggestions that would get developers rolling their eyes, I have learned to be intentional with my recommendations. 

In these, I included:

• The insight (what happened and why it happened)
• A link to the evidence of the insight (such as a video clip)
• The consequence of what might happen if we don't do something about it
• Priority of the insight, based on how many users it could/is negatively impacting
• A How Might We statement inviting us into the solution land of creating ideas on how to fix it
  

With a recommendation like this, I’m not telling anyone what to do, but I am instead inviting people to come together, look at the evidence, and think through different ways to solve the problem.

As mentioned above, I always schedule an activation activity, such as an ideation workshop, to bring us from the HMW statement to a solution we can evaluate further through concept or usability tests.

6. Kudos to the team

I always shout out to the team, including any fun photos I can find, because it’s important to acknowledge collaboration. It’s also a nice way to end a report. 

Reports take patience and iteration

Writing reports can be a tricky part of our process, but as long as we’re intentional in what we include, open to feedback from stakeholders, and okay with constantly iterating, we enable others to use our insights in the best way possible.