How to turn “UX storytelling” from buzzword to powerful tool
Practical advice, not vague analogies, on how to use UX Storytelling
UX storytelling is a powerful tool for communication, yet most of the time, it is a buzzword on a resume.
As a result, most people don’t know how to do it or think you can’t apply it to your weekly design process. You do it when you’re finally done with a project and have some spare time 3 months later.
Except that’s not the case. UX Storytelling is often most helpful while working on a project, in research presentations, talking with stakeholders, or in design meetings.
It’s much simpler than you realize to tell a UX story because UX only ever tells a single story.
UX Stories are only ever about one thing: change
Despite popular belief, you do not need any storytelling (or creative writing) experience to tell a good UX story. That’s because, in many ways, UX stories are more like copywriting than fiction writing.
Every story you tell about UX is centered around one thing: user behavior change.
Whether you’re telling the story of problematic user behavior, that you hope to change with design recommendations, or user behavior you want to utilize to design a new feature, everything centered on change.
As a result, there’s no need to learn traditional storytelling structures like:
The Hero’s Journey
Story Spline
Story Mountain
Freytag’s Pyramid
etc.
Instead, we can use Jeff White’s 3-part Story framework, which he’s used to present to Jeff Bezos (and other Amazon executives) 20+ times.
In his mind, there are only three parts to a UX story:
Context: What are we designing, and why do we have to change?
Struggle: How are users struggling, and what is the impact?
Transformation: What is the design solution you recommend?
This is the essence of what we might call the “Change Story,” which story UX can use to engage audiences.
Just enough Context: Who are you presenting to?
The first question you must ask isn’t about plot, characters, or story structure. Instead, it’s this: who is your target audience?
After all, you probably wouldn’t tell a raunchy story to a group of 4-year-olds, right?
Understanding the audience is simple because we’re telling a UX story. Ask yourself this: who in the audience can take the actions you need?
At its core, a “Change Story” has a call to action:
Approve these design recommendations
Please hire me
Schedule a meeting with someone
Please give me a bigger budget
Etc.
Figuring out who can make these decisions and targeting them as the story's audience is critical in understanding how much context you need to provide.
If you’re talking with a Product Manager you work with daily versus presenting to a CEO who checks in once a month, you probably don’t need to include that much context.
However, here’s a general guideline of what you might want to include in the Context stage:
What are we designing (i.e. high level design goal, like “Designing a new checkout workflow”)
Why are we designing this (i.e. high-level business outcome, like “People are abandoning checkout and it’s costing us a lot of money”)
Where/How is this being used (i.e. “5,000 people go through this process every single day.”)
Why can’t we stick with the current design?
Identifying that last question is often crucial, especially if your audience is less familiar. It’s often a one-sentence (or slide) summary that can easily transition us into the struggle phase.
Struggle, or what is the impact (beyond UX) of user behavior
Struggle often feels the most familiar to you, as this is where you would typically put findings like “3/5 users did X.”
However, in UX Story, you need to focus on one particular thing: how can you convey user struggles in a way that appeals to the person you’re targeting?
After all, ‘3/5 users did X’ often means nothing to a CEO who stares at dashboards and KPIs that measure what millions of users are doing. What’s more, it’s tough to make multi-million dollar decisions on what “3/5 users are doing”.
This is why I always recommend a data-informed design approach (link), like checking Analytics, seeing 71% of people abandon checkout at the 2nd screen, and tying that to behavior we see with “3/5 users”.
However, if you don’t have access to Analytics, two other data sources are often equally effective: Market Research and Competitive Research.
Market Research
It’s often the case of finding a ‘business statistic’ that pairs well with your user findings to help drive forward a better future.
For example:
We’re the most prominent company in a competitive industry that brings in $380 million annually. (Market Research)
That’s the case even with a broken checkout process that caused 3/5 users to give up on it (UX Research)
Imagine how much better (i.e., more revenue) we’d be if we fixed the checkout process. (Better future)
This often involves talking with your team, like Marketing or Sales, but it’s a great way to phrase your user insights in a way that a lot of the other team can understand.
Competitive Research
The other compelling Data you can lean into is your competitors. While it’s often not a fair comparison, it’s often a way to ignite your team's competitive spirit (or at least drive some action).
The simplest way of doing this is just taking screenshots of specific features and providing enough context to make it easily understandable. This is often where you can involve UX knowledge or best practices.
For example:
Users often only spend 10–20 seconds looking at a page before deciding to continue or leave (UX knowledge)
Which checkout process convinces them to continue: ours or our competitors? (Screenshots)
Our checkout process has the following issues….
By spelling things out in a way your target audience understands, your struggle goes from being a presentation on UX findings to insights that the business can understand and take action on.
Then, you talk about the transformation.
Transformation, or what we recommend to fix things
This section should be equally familiar to designers, but taking an audience-centric lens helps us see where we often fall flat.
One of the main issues is that designers often don’t recommend solutions. Many designers would instead address the problem and ask our audience, seeing this information for the first time, to decide what to do.
That results in hasty, bad decisions that make no one happy. Luckily, if you’ve followed this process, you should have some ideas on how to do this.
Again, it’s about creating enough context. The idea should be that this is not your ‘design opinion’: it’s a recommendation based on UX knowledge, talking with users, and more.
However, what also helps is having a visual aid with your recommendation. It doesn’t need to be a finalized design: often, having ‘boxes and circles’ to highlight the design change works.
This is especially important if there are a few design solutions and you want the audience to choose.
In many cases, you only need to emphasize that this isn’t your opinion. This is your recommendation based on your UX expertise.
I recommend the following design solution to fix X problem…
With this, you’ve learned the basics of UX storytelling, which can be used in weekly meetings.
Make UX storytelling more than a buzzword
Storytelling is one of those concepts that everyone, including business leaders, loves to mention.
However, few people try to implement it in their work, which makes those who do stand out.
Whether you’re presenting user findings to your team, design recommendations to executives, or negotiating potential design solutions in meetings, UX storytelling is a powerful tool that can effectively communicate your point of view.
Moreover, the UX storytelling skills you polish during those meetings provide a competitive edge to your design portfolios. If you can engage interviewers with a 5-minute story, you can drive more interest to your application.
So, if you want to level up how you communicate about design, learn a little about UX storytelling and how to use it.
It can often be the difference between people listening when you talk and people zoning out.
April’s Data Informed Design cohort is being updated with new material!
Kai Wong is a Senior Product Designer and writer for the Data and Design newsletter. He teaches a course, Data-Informed Design, on becoming a more effective designer using the power of Data.