We’ve talked about why stories can work and how they’re typically structured to try and get the reader to pay attention.

They’re one of the easiest and most effective ways to convey whatever factual information you may have. But you may not have any idea how to begin telling a story like that.

While learning to write a compelling fictional story is something that I have yet to learn, writing a compelling informational story has been studied in greater detail.

You can follow a process that will allow you to make sure that you can convey the information correctly.

And it starts by making sure 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 town called her Little Red Riding Hood.

The reason why stories start like this is to ease the reader into a scenario. It allows readers to become aware of the context, like the environment or the characters, regardless of their familiarity with the story.

You need to take a similar approach for some of the reasons we discussed earlier: you’re the expert on the data, and not everyone’s starting at the same place. By designing the studies that collect data, talking with users, reviewing and analyzing things, you’ve slowly become ‘the expert’ regarding the data over days or weeks.

But 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 perhaps they were out sick for a week. Therefore you need to set the context at the beginning of your presentation to ensure everyone starts on the same foot. There’s nothing worse than losing people 5 minutes into an hour-long presentation.

So what are some ways of establishing common ground?

Tom Greever, the author of Articulating Design Decisions, talks about some of these methods. These include making slides for:

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.
Naming the meeting properly (in your e-mail invites)

Besides, there are many other things that you can do throughout your presentation to make sure that people don’t get lost in transition. You can do this by optimizing memory: chunking your presentation into clearly and visually distinct categories help break up content in people’s minds.

People tend to remember the first and last things that we say, with them getting lost in the middle. Breaking things into smaller chunks by visually distinct methods (such as the use of tabs) can help your stakeholders remember more of the presentation, as it registers as several mini-conversations rather than one long meeting.

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

What’s The Big Idea?

One reason why stories are so compelling for wider audiences is that they provide something for everyone. Some people might love Little Red Riding Hood’s themes or setting, while others might like individual characters like the Red Riding Hood or the Wolf. However, no matter which aspect your audience engages with, the story has the same ending and message at the end.

Informational stories are no different. Some people will naturally gravitate towards technical issues you present, others about time and budget regarding recommendations, or perhaps the scope of these issues and how we can fit them into Agile sprints.

However, the conclusion that they should draw should be the same: their call to action is the only difference. So the next step is to figure out what that conclusion might be.

How do you figure out this conclusion? One way is to look for 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 critical points from your presentation, they’ll still have the same outline.

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?
What’s at stake: What benefits your audience if they take 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 activities we need to take based on your research.

For example, imagine if your project’s goal is to redesign a poorly-designed website, and you did user research to learn the user’s current workflow. Based on your research, it seems like we’d have to make extensive changes to the current system for it to be worth it: our users have said they’d rather keep the bad system rather than spend the effort to learn a slightly better design.

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, they know the conclusion you’ve drawn. If they were to leave the meeting with just that idea, you could consider the meeting a success. Why?

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.

And if they’re not convinced with the conclusion, they can spend more time exploring the examples and data you provide through the rest of the presentation.

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.

Creating a storyboard outline

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

Storyboarding is a technique used to show the context and environment your user group or persona may have while performing a specific scenario.

For example, if you’re designing a website aimed at mothers of young children, the storyboard might be a walkthrough of our websites’ checkout process, but through your user’s context. So your target user, Jenny, maybe a mother of two kids, Johnny and Sarah. The scenario might be to check out while applying a coupon code, but the storyboard might walk through how Sarah’s been crying and Johnny’s being very loud today, so she often has to take breaks to get them to quiet down while trying to complete the task. As a result, she keeps getting timed out and restarting the process, which is frustrating.

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 assess the Big Idea. If you give presentations multiple times a week, doing those two steps is already asking for a significant chunk of time.

Storyboarding can be an informal process done with low-tech solutions like sticky notes, and it can be done both individually and collaboratively. It is often a quick sketch of a larger story and can describe a fragment of the user’s journey.

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 compelling stories. This allows you to see the story's outline, which you can then build on with further effort.

At this point, you might not have all the information you need to complete the entire process, but you might have the basics down to answer that initial question.

So how do you start?

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

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

Context (Background/Location)
Our user group/persona
What’s the current problem?
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 crucial point #1
Here’s a data viz/illustration of crucial 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 in a single meeting.

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:

Start dividing your list into three 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 critical 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 three categories

Get user feedback

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

There are multiple things that you need to test at this point, which include:

Do they understand the Big Idea: Is the conclusion lost in the organizational structure, or do they get the point?
Are the slides ordered correctly: Would they change the ordering of slides based on the three categories?
Do we have too many/too few slides: I like to have 3 minutes a slide, so an hour-long presentation with 15 minutes for questions is usually 15 slides. However, are we missing any information that we need to include on a slide?

Should we change the wording/format of a slide: Perhaps it might be better to show a timeline of errors versus just saying that our current process has these problems.

If everything looks good to them, you can start spending some time thinking about the visuals that can be paired with these possible slides.

But from here, you already have a basic, user-tested outline for the story that you want to tell. This story outline will help guide you in making stories that resonate with your stakeholders and get them to draw the same conclusion that you’re trying to get them to notice.

After that, there’s one last step: figuring out what type of story you want to tell.

What type of story are you telling?

According to Karl Gude, Graphics Editor at the University of Michigan’s School of Journalism, a story is how all the information elements are held together. So here are some of the different types of stories you might want to consider as part of this process.

Beginning, middle, and end:

One of the most common stories, across fiction and non-fiction. This type of story is based on having all three elements and having them fit together logically. For example, if everything fits cleanly in our Problem, Action/Analysis, Outcome model, with each category being pretty well defined and leading into each other, we would use this format. For example, “The checkout screen is a problem. These are the reason why. This is what we need to do about it.”

Cause, Effect, and Impact:

Another type of story is a structure where it’s more important to highlight a change over time. One way to think about it is “Beginning, End, Impact”: we skip over a lot of the analysis and talk more about the effect that certain actions have had on a project. For example, “Since we implemented this change, productivity has gone up 20%. Here are the impacts of that change.”

Then and Now:

This story focuses on a snapshot of two time periods, focusing on specific aspects, elements, or metrics. For example, “Our budget deficit used to be very big, now it’s very small.”

This, this, and this:

This story highlights many forms or elements of a single subject, such as how the word “dog” can refer to different breeds. This is usually used in scorecards or other analytics: for example, “Our team consists of X employees, who generated Y in profits, and Z in industry awards….”

Problems, Solutions:

This can refer to having problems aligned on one side, with solutions aligned on the others. This is typically used for checklists or other reference materials. For example, “If this light is blinking, do this. If there’s a weird sound, do that.”

There are many other types of forms that stories can take, which means that you can think about this issue as it comes along.

How to outline stories

Create your profile

Only paying subscribers can comment on this post

Check your email