How to effectively engage stakeholders with your presentation
By: Kai Wong
Tags: Productivity, Visualization, User Experience, Design, Work

How to effectively engage stakeholders with your presentation

Photo by Teemu Paananen on Unsplash

One of the hardest skills for me to learn was how to present to stakeholders effectively. After spending days, weeks, or months doing user testing, collecting data, and analyzing it, it almost seemed impossible to condense that into a single hour with stakeholders.

Many times, I either presented too much data, didn’t highlight key points, or otherwise confused stakeholders with the terminology they were unfamiliar with. I learned how to plan out my presentations, but they never seemed to be as effective as I wanted them to be.

But visiting the world of data visualization has not only taught me a better way of planning my presentations. It’s given me a new appreciation for a UX method that many of us already know: storyboarding.

To effectively engage your stakeholders and give an effective presentation, you need to create a story first. Here’s how.

Why stories work

To understand why stories work, let’s first examine a presentation that sticks only to conventional wording.

Red Riding Hood (RRH) has to walk 0.54 mi from Point A (home) to Point B (Grandma’s)

RRH meets Wolf, who (1) runs ahead to Grandma’s, (2) eats her, and (3) dresses in her clothes

RRH arrives at Grandma’s at 2 PM, asks her three questions

Identified problem: after a third question, Wolf eats RRH

Solution: vendor (Woodsman) employs tool (ax)

Expected outcome: Grandma and RRH alive, the wolf is not

Is this something that you’re likely to remember? More importantly, if you read this as a child, instead of the story of Little Red Riding Hood, would you have remembered it now?

Probably not.

Stories stick: Research indicates that people are more than 20 times as likely to remember facts if they’re part of a story.

Most presentations aren’t just about showing knowledge: you’re also trying to influence your audience to make certain decisions (such as approving design changes).

Well-designed stories, not plain information, have been the most effective method of exerting this influence.

But to create well-designed stories and reduce the burden on you, you first need to plan things out.

And part of that is making sure everyone’s starting at the same place.

Establishing common ground

One of the most important writing tips that any journalist or writer will tell you is that your first sentence or paragraph matters.

But have you ever noticed that many stories don’t start right with the action? For example:

Once upon a time, there was a little girl who lived in a village near the forest. Whenever she went out, the little girl wore a red riding cloak, so everyone in the village called her Little Red Riding Hood.

Part of the reason that stories start like this is to ease the reader into a certain scenario: it allows readers to become aware of the context, such as the environment or who we’re focusing on, regardless of their familiarity with the story.

You need to take a similar approach for a simple reason: you’re the expert on the data.

Through designing the studies that collect data, talking with users, reviewing and analyzing things, you’ve slowly become ‘the expert’ when it comes to the data over the course of days or weeks.

And it may not occur to you that others may not have that familiarity with that data until you see an audience of blank faces.

Sometimes executives are bouncing from meeting to meeting and need a quick refresher. Maybe they’re having a bad day. Or maybe they were out sick for a week.

Therefore you need to set the context at the beginning of your presentation to ensure everyone is starting on the same foot.

In Articulating Design Decisions, Tom Greever talks about some of the key points to establish context. These include:

Stating the goal of the project (that you all previously agreed to)

Summarizing the last meeting

Showing a Timeline

Stating the specific feedback you’re hoping to get out of this meeting.

Stating the goal again

After making sure that everyone is on the same page, we must answer the next most important question: “So what?”

What’s The Big Idea?

One reason why stories are so effective for wider audiences is that stories provide something for everyone: whether it’s the narrative, the characters, or the setting, people engage with them for different reasons.

When applied to work settings, the problem with stories is that you often don’t want people to come away with different messages. You want them to come to the same conclusions because it’ll help the decision-making process.

So the next step is to think about the conclusion you want them to come to at the end of your presentation.

For that, we can look to The Big Idea.

This is an exercise that is intended to help you figure out a one-sentence summary of your presentation. This way, even if your audience takes slightly different key points from your presentation, they’ll still have the same summary.

Figuring out the big idea consists of 3 components:

Who is the audience : If you had to narrow your audience (at the presentation) down to one person, who would it be? What do they care about, and what action do you want them to take?

: If you had to narrow your audience (at the presentation) down to one person, who would it be? What do they care about, and what action do you want them to take? What’s at stake: What are the benefits if your audience takes the actions you want them to? What are the risks if they don’t?

What are the benefits if your audience takes the actions you want them to? What are the risks if they don’t? What’s the big idea: How would you articulate your unique perspective that conveys what’s at stake in a single complete sentence?

The big idea is often a natural extension of the background in that case: after talking about the actions we’ve taken up until this point, we then can spend time talking about the actions we need to take based on your research.

For example, imagine if your project's goal is to re-design a poorly-designed website, and you did user research to learn the user’s current workflow.

The Big Idea could be something like, “The users are running into so many problems on this specific page that they’re abandoning the process, so we’re going to have to re-make it from scratch.”

In that case, regardless of whether people understand the specific examples you present of this, they know the key point you’re trying to make.

From there, the stakeholders can take actions you often might not pay attention to, such as planning meetings focused on that page, bringing new members into the team, or shifting the project’s budget and timeframe to accommodate for this change.

So now that you know the points you’re trying to make, it’s time to frame it as a story.

This is where storyboarding can come into play.

Extending the storyboard to your stakeholders

In case you haven’t spent any time working with storyboards, here’s a quick summary.

Storyboarding is a technique that is used in multiple domains. Still, within UX, it’s a way of showing the context and environment your user group or persona may perform a scenario.

For example, if you’re designing a website aimed at mothers of young children, you might highlight how they might not be able to deal with complicated checkout processes due to paying attention to their kids.

So why use storyboarding in this case?

First and foremost, is because it doesn’t take that much time. I’ve already asked you to consider establishing your background and doing an exercise to consider the Big Idea. If you give presentations multiple times a week, doing those two steps is already asking for a significant chunk of time.

But storyboarding can be an informal process, done with low-tech solutions like sticky notes, and it can be done both individually and collaboratively.

But the benefits are immense. Being able to visually present where bottlenecks or pain points might be, along with a quick overview of how your ideas are structured, will allow you to tell effective stories.

The first step for storyboarding is to make a list of sticky notes that illustrate all the key things you might want to touch upon.

So for our example of redesigning a website, here’s a list of all of the different pieces I might want to include in my presentation:

Historical Context (Background/Location)

What’s the current problem?

Our current process is (Bad/Good/Has some problems)

How did we gather our data?

What are the methods we used?

Here are personas we built based on users

Here’s a data viz/illustration of key point #1

Here’s a data viz/illustration of key point #2

Our current process is (Bad/Good/Has some problems)

Potential solutions

Recommendations/What this can solve

Resources needed

Decisions to be made

This is not a complete list, and this varies widely on the type of audience. I’ve found that for less-technical audiences, I don’t need to talk about methods that much, for example.

Or sometimes, I might want to skip recommendations entirely because I won’t have enough time to address them.

But after you have your list, that’s when you can begin to plan things out further.

Divide your list into Problem, Action/Analysis, and Outcome:

Basically, start dividing your list into 3 categories to kind of mark where they belong in the story.

Problem: This is setting up the background, context, or stakes. Why should your stakeholders care about what you did or pay attention to this issue?

Action/Analysis: What could become of the problem if no action is taken? How could things be better based on what you learned? This is where the majority of data visualizations and key examples that you did should be brought up.

Outcome: What do you want your stakeholders to do, now that they understand the issue more? What are your recommendations for resolving problems? What decisions do they need to make?

The list, sorted into 3 categories

After planning things out like this, get some feedback if possible. Ask a friend or colleague to look over what you have.

As a general rule of thumb, I usually like to have 3 minutes a slide, so an hour-long presentation (with 15 minutes for questions) is usually 15 bullet cards.

From there, you can start spending some time thinking about the visuals that can be paired with these possible slides.

For example, is it just okay to have a slide that says our current process has these problems, or would it be better to show some timeline of errors there?

This not only helps you decide if you need specific visualizations for a slide but helps make telling a story much easier.

And it will no doubt lead to more effective presentations, whether in-person or remote.

So if you’re trying to improve your presentations, try to leverage storytelling as a part of it. You may find that you can tell stories that resonate with your stakeholders.