The Anatomy of a Research Findings Presentation

This post is about giving a presentation on qualitative research findings, including building credibility, storytelling and persuasion. It is not about writing a report. There are many great resources on that already, as well as some constructive debate about whether or not it’s worth doing; I highly recommend opting for a presentation if you’re choosing between the two, although there are alternatives as well.

Some of the reasons to choose giving a presentation over writing a report:

• It gives you an opportunity to build your presentation and storytelling experience
• It provides your audience with a clear opportunity for engagement and discussion
• Folks who need an artifact afterwards can dig more deeply into the deck, or other artifacts coming out of the research — they don’t necessarily need a written report (let’s get real, very few stakeholders are actually digging into a written report anyway)
• I find it much easier to create a deck than to write a paper, and I know I’m not alone in that

If those don’t convince you, check out Kyle Soucy’s excellent presentation on storytelling from this year’s Boston UXPA conference, Gather Round: How to Share the Stories from UX Research.

Pretty much everything below is optional; I will often include things or leave them out based on the size of the research project, the level of awareness of the audience or the amount of time I’m committing to.

Intro

This can be as simple as a title slide. I love a clever title, but it’s obviously not necessary; do include your name and the date, though. I didn’t think those were necessary in a Google Drive world, but we use PDFs in our repository, so we need that information in the actual artifact.

Also, name the file the same thing as the title of the slide. It should include the name of the product, team or product area (if applicable) and the word “research” somewhere so it’s easier to search for later.

The Why

This is the business context for the project. If you’re using Tomer Sharon’s The UX Research Plan that Stakeholders Love (which I suggest you do), you can include the background, the goals and/or research questions here.

Other information that can be helpful here, especially if you can have a PM present it (it demonstrates collaboration!):

• Quantitative data from analytics, surveys or secondary research
• Sales or support data, especially if it addresses win, loss or churn rates
• Competitive intelligence
• Any kind of projection or prediction, especially if it highlights some assumptions the business is making

If you’re presenting qualitative findings to a group that includes some quantitative thinkers (and almost all groups of stakeholders do), this is an opportunity to demonstrate that you’ve done your numbers homework too.

Process

Including information about process is a double-edged sword. It could build your credibility as a researcher and educate audience members about the amount of effort that goes into research; it could also bore your audience, further the stereotype that UX is process-heavy or open the door to endless questions about sample size and validity.

Include more process when:

• You can present it confidently; the more confidently you present it, the fewer questions you will get about sample size
• You feel prepared to answer endless questions about sample size or other aspects of the process
• You have an engaged audience thirsty for more details about process (this is rare; if you think you have this, I suggest you think again)

Include less process when:

• Your audience doesn’t have the patience for it, or already trusts you to handle it
• You think it may encourage your audience to focus on the methodology rather than the findings
• You don’t have a lot of time, or want to use the time you do have to focus on other information

The elements of process I typically include (if any) are:

• Sample size, plus any details about the sample breakdown I believe my stakeholders will need to feel confident about the findings
• Method, with a brief description of why I chose that method for the project
• The team, including co-researchers — I love to bring stakeholders with me so this list can get a little long!

You may have noticed I am what some might call “overly concerned” with questions about sample size. I freely admit that they are the bane of my professional existence, which I actually don’t think is a super mature attitude for a researcher to have. I’m working on it.

Workflow

This is where you really start to dig into the findings. I usually break this down into high-level findings and then in-depth detail; if you have a M-XL size project with multiple themes, you can treat each theme as its own section and do this for each.

If there’s a workflow we’re discussing, I usually try to lay this out in the order of the workflow, or the order in which users are making decisions. This gives the audience a loose sense of chronological order that can help them orient themselves, and it gives me a framework that makes my life easier.

High Level

This can take any form that makes sense. You can use a one-sentence statement here to introduce a theme, you can break it down into a job to be done — whatever makes sense in terms of fidelity for the story you’re telling.

If your research findings contradict assumptions stakeholders, or the business as a whole, have previously made, I like to use a “What We Thought vs. What We Learned” format. You have to frame it carefully or it can come off a little abrasive: I include myself firmly in the camp that made the assumption, and then present the findings with a “wow! Can you believe?!” tone. I know when I’ve done it well when my audience follows the story through that plot twist (although I recommend socializing the twist with your stakeholders beforehand).

In-Depth

I tend to think in workflows, so when I go into detail it’s often an in-depth look at the microdecisions users are making during the interaction I’m studying with the social, emotional and functional factors in play throughout. I’ll visualize this as a timeline, a storyboard or a series of steps, or if I’m lucky I’m collaborating with a designer who steps in here.

Synthesis often leads to an overview of the path most users take; that’s often what I present here, but if there are other common workflows or workarounds those deserve coverage here too.

If I’m presenting to leadership or fitting into an otherwise tight agenda, this becomes part of the appendix. If I’m presenting to an audience that’s enthusiastic about research or will be working on any roadmap items resulting from the research, I’ll go into this kind of detail during the presentation.

Can You Believe!?

You will probably have some really interesting findings that don’t fit into the framework above, but that you really want to share: great details that humanize your users, or wild workflows you felt lucky to catch even if they were outliers. If there are details that don’t fit but you feel are too powerful not to share, you can include them here.

Wrapup

This is the party favor section; you wrap things up in neat little bows so your audience can walk away with something tangible.

Takeaways

These are the sound bytes your audience can use to talk about your research outside of the room and the project. One of my personal metrics of success is hearing research I’ve been a part of discussed when I’m not part of the conversation — this can really help here.

This should be 3–6 major themes coming out of the research, ideally framed in language familiar to your stakeholders and IDEALLY ideally tied to larger strategic themes important to the business. If you’re using Slides Carnival, most decks have a slide with about 6 small sections of text; this works really well here.

Next Steps

You know you’ve told a great story when your audience asks “How can I be involved?” This is where you tell them. It’s also important to demonstrate that research has impact beyond furthering the organization’s knowledge about its users; concrete next steps here suggest momentum.

Here are some kinds of next steps I typically include — again, it’s especially helpful if you have a PM, designer or other partner who can co-present:

• Designs based on research findings
• Roadmap items resulting from research
• Business opportunities uncovered by research
• Research findings framed as hypotheses the team is interested in testing
• Design thinking exercises you might use to get the most out of the findings, like ideation

If your culture is very solution-heavy, there can be a lot of anxiety around presenting findings from a research project that didn’t lead to clear solutions. There are so many reasons this can happen — many of them are permutations of “the problem was more complicated than we thought.” There are several things you can do to socialize this:

• Set expectations with key stakeholders early and often, so no one is surprised
• Frame discussions of the findings around the immense value of what you learned —it’s so much better to be diving deeper into a problem than putting effort into a solution that won’t solve it

And remember you’re not alone! Human beings love to solution; we’re built for it, and taking a step back to investigate the problem space doesn’t always come naturally to us. That means UXers are change agents no matter the culture they’re working in.

Questions

The final slide I present is generally a “Thanks! Questions?” slide with my contact information. I always dedicate about 1/3 of the time I have to questions because I think it’s important for the audience to engage, and have an opportunity to be heard. It also allows me to focus on the story I want to tell rather than trying to predict every question and answer it as part of the presentation.

Appendix

As a librarian, I love to cite my sources! And an appendix can be useful for the occasional stakeholder who wants a deep dive, or for new folks who are getting up to speed.

The kinds of things I usually include in an appendix are:

• Slides I put effort into buy ultimately didn’t make the cut
• Process information, if I didn’t include it up front
• Links to research plans, scripts, prototypes, designs and any other artifacts used in the research
• Relevant secondary research

A Few Logistics

Touchpoints

If you’re still building credibility with your stakeholders, using existing touchpoints like demos and regular update meetings will help integrate research into the team’s vocabulary and regular cadence. My general rule is that if there’s an open agenda, I can add a findings presentation to it.

Once you’ve generated some excitement around research, these touchpoints are still valuable but you can also reach for a larger audience and try out things like brown bag sessions or webinars.

Templates

I highly, highly recommend Slides Carnival. The templates are free and easy to use, you can import them right into Google Slides, and they have slide formats that work well for most of the sections I outline below. And if you work in a PowerPoint-heavy culture where folks tend not to think outside the company template, they can really make a splash.

Repository

Presentations like this should live in a research repository. Like a written report, very few folks will actually dive in, so it’s not necessary to put a ton of effort into but it’s an important marker of what research has accomplished and a great place to send new hires.

Thanks! Questions?