Storytelling with Design: How to persuade your team with narrative
Understand narrative and tension to engage them with your presentations
Design storytelling is one of those crucial skills people want, but it’s hard to know exactly how to learn it. Talking about it conjures images of the late Steve Jobs on stage, engaging and persuading the audience with the power of design.
Not to mention, the benefits of telling stories are immense. Not only are you more likely to engage and persuade your audience more easily, but stories are also over 20x easier for people to remember than pure facts.
We often create design artifacts centered on storytelling, such as storyboarding and journey maps, yet it’s not always obvious how to improve at telling stories.
However, it may be easier than you realize. To learn how to tell stories with design, keep one question in mind: what tension is the audience hoping to resolve?
Storytelling in design is about keeping your users in mind
Cole Nussbaumer Knalfic, in her book Storytelling with You, highlights an example of why many presentations fail to engage people and why Designers have an advantage with storytelling.
Imagine how people typically approach creating a presentation. It might typically follow a linear template, such as:
Now think of how many boring presentations you’ve listened to following that format. When you do, one thing should become clear: these presentations are not designed with the audience in mind. Instead, it’s designed to be easy for the presenter to read off their slides in an acceptable manner.
It’s also why we, as Designers, can probably do better: our careers are spent understanding user needs, wants, and frustrations. So designing a presentation with your ‘user’ (i.e., audience) in mind can easily result in more engaging and persuasive presentations that get your audience to take action.
However, storytelling isn’t just useful for presentations.
Design often uses storytelling as part of their process
I won’t touch on them in this article, but here are some other opportunities you might have to leverage storytelling within your design process:
This is the high-level overview of the user’s path, touching on some of the main driving factors, motivations, and emotions behind how a user interacts with your site.
Storytelling can help you engage your team with one person’s journey and where they struggle, or our site doesn’t match what they need. In particular, storytelling can help distinguish between what the business wants customers to do and what they actually do.
In addition, customer journey maps are often polished deliverables you can provide to visualize your user’s path through many different products and departments.
Personas/Use cases/Storyboarding:
How do you create a basic story with steps around how users address and complete specific tasks? I’ve lumped these artifacts together because Storyboarding requires both Personas and Use cases to be fully fleshed out.
While these storyboards may be meant for internal use, engaging your team with the Persona, and the specific context they face, will be the driving factor here.
For example, why does Mary seem to time out a lot while Dave doesn’t? When you establish the context, your team might see that Dave is an expert user who uses our systems constantly, while Mary is a novice senior citizen who spends all her time reading the massive amount of text on the site.
User stories are one of the smallest tasks that leverage storytelling and sometimes one of the most important. These small stories fit into Agile backlogs and tracking software, which are features people can accomplish within sprints.
However, the main storytelling element is keeping these stories user-centric and tying together the larger picture within the backlog.
Regardless, all of these processes have storytelling elements within them, and even though we’re focusing on presentations, they should all follow a basic 3-step process. That process starts with a question: Who is your audience, and who are you prioritizing?
Who is your audience, and who are you prioritizing?
You’re unlikely to get your entire team to agree on one action. As a result, you have to consider two things when you think about your audience: who is your audience, and who do you want to prioritize?
The first question will focus mainly on your audience's composition to help you figure out what you need to address. For example, if your audience is all close team members who’ve been with you every step of the way, you could cut summarizing every action you’ve taken until now.
On the other hand, if you’re talking with people who have never heard of your project, you may need to stay high-level and provide much context.
Most of the time, however, audiences tend to be a mix of people, especially if this is a large issue you’re addressing. This is where the following question matters: who will you prioritize?
Who would it be if you had to choose one person to target with your presentation? You often choose based on which one of the four categories you need the most:
People that provide access: Managers, VPs, or C-level executives can often provide access to specific audiences, tools, and more
People that provide resources: Project Managers can work in your requests (like additional user testing) into the budget and timeline
People that provide knowledge: Lead Engineers (or other Subject Matter Experts) can provide technical guidance into whether a design is feasible
People that provide approval: Product Managers, Product Owners, and a mix of Administrators can approve you for new tools, analytics accounts, and more.
Understanding who you prioritize helps you focus on the points you must provide. For example, suppose you’re trying to get another round of user testing approved.
In that case, you will want to focus on why that’s the case: perhaps users brought up a serious issue (like a law around data privacy you were unaware of) unexpectedly that would require us to change our design radically.
To assist us with this process, you must address the following question: what conflict/tension does your audience have?
Your audience has tension around something you need to resolve
Tension is at the heart of every good story; your presentation should be no different.
The core of storytelling in design revolves around one simple question: what conflict/tension exists for your audience?
This seems simple, but failing to address the audience's tension often causes presentations to flop. To explain this, let’s take a poor example of this.
Imagine you were presenting your user research, describing the ‘tension’ with the following problem statement: “Our problem is that users don’t know how to figure out how to complete task X.”
Is that really what your target audience member cares about? No. What they care about will likely be the ‘effect’ of that problem.
Whether it’s metrics being affected (like low Weekly Active Users) or our lack of knowledge around why this is occurring, that’s the tension your audience is facing. They’re looking to UX to guide them on why users aren’t engaging with the current design or what actions we need to take.
In our example, Product Managers have tension around whether we have everything we need to complete our product according to our timeline. If not, what do we need to do?
In that case, when they hear you define the problem that way, some will likely tune out and say, “This presentation is not targeted for me.” That doesn’t mean that they won’t always take appropriate action: it’s just that they’re not engaged (and persuaded) by what you’re presenting.
As a result, you sometimes find out that you didn’t engage your audience when you finish speaking, and there’s an awkward long pause in the meeting before someone speaks up and tries to summarize what you presented.
To truly get them involved, we need to take a step back and consider what tension exists for our audience. Once you’ve done that, you can finally start with the storytelling process for your presentation.
To do that, let’s take a look at the Narrative arc.
Create a narrative arc with your findings to address tensions
Once you understand what tensions your audience is facing, it’s time to draft an outline of your points that will form your story's basis.
This should be done as low-tech as possible, as the main goal is to have a rough draft where you can trash talking points, move them around, or consolidate them with little issue. For that reason, using Post-It notes, whiteboards, index cards, or sheets of paper allows you to draft without becoming too attached to certain ideas (like if you were to design them as Powerpoint slides).
Once you’ve drafted your talking points, it’s time to apply a basic story framework called the Narrative Arc:
It consists of 5 sections.
Plot:
What common ground and frame of mind must you establish with your team? This often consists of thinking about the knowledge you know tacitly and whether it would be helpful to communicate that directly.
For example, you may know the job titles and responsibilities of the users you tested with, but would it be helpful to elaborate on that with your audience?
Rising action: What tension exists for your audience? How can you directly address this and build it to an appropriate level based on your work?
For example, if Product Managers are concerned with whether we have everything we need for a good Product, this would be where you raise the idea that our users are skeptical that our design will address everything they need due to a legal constraint we may not be aware of.
Climax:
What is the maximum point of tension for your audience? This is often about conveying what’s at stake if we fail to take action. What’s at risk, and what does your audience care about?
In our example, this could be as simple as conveying that our current design won’t pass internal review because some serious legal concerns (around data privacy) aren’t being addressed.
Falling action:
While this sounds a little fuzzy, the main purpose is to ensure we transition from the climax to the ending. In this case, it might include additional details of user concerns, potential options we can take, questions to address, or solutions to employ.
In our example, this might be where we raise the idea of doing a quick re-design and another round of user testing. We might also bring in additional arguments, such as that the design must change so much that we can’t be sure that previous user feedback will apply to this design.
Ending:
This is the resolution and call to action. It’s rarely as simple as “We found X, so we should do Y.” Instead, this ending should be the following action we need our target to take, from setting up another meeting with people, deciding to choose an option, or checking whether we can approve such recommendations.
In this case, we need to ensure that the action we want our audience to take is clear and compelling.
By doing this, we’ve successfully laid out the basics for telling a story with our presentation. After doing that comes the following step: feedback.
Refine your story and ask for feedback
No story is perfect on the first draft, and your design stories are no exception. What you need to do once you come up with a basic story is to review the elements that you’ve written down.
For example, ask your team members (or other designers) if your story focuses on addressing your audience's attention or whether your key insights back up your argument.
Refining your slides and iterating on your stories can help you learn to tell stories about design much better. That, in turn, can turn your processes into things that engage your audience to a larger degree.
While storytelling is still a skill you’ll have to learn and practice, the basic framework I’ve laid out here is a great way to practice, learn, and master the art of storytelling with design.
Kai Wong is a Senior Product Designer, Data-Informed Design Author, and Top Design Writer on Medium. His new free book, The Resilient UX Professional, provides real-world advice to get your first UX job and advance your UX career.