Originally presented at Camp UX 2023
Every UX designer I have ever worked with can tell me what they designed. Very few can tell me why it matters. That gap is not a design problem. It is a storytelling problem, and it is the difference between a designer whose work gets approved and a designer whose work gets questioned in every review until they want to quit.
UX storytelling is, as Jeff White put it, the act of telling someone why a design decision is good or bad. It happens any time you present, communicate, or show your work to a stakeholder or colleague. Which means it is not a special skill you deploy in high-stakes presentations. It is the skill you use every single day.
Here is how to do it well.
Act One: Know Your Audience
Who you are presenting to determines everything about the story you tell them. Before you open a single file or build a single slide, answer these questions:
Who is the audience and what do they already know about what you are going to show them? What do they care about? What language will resonate with them? If you have presented to this group before, what worked and what did not? And most importantly: what is your goal? What do you hope is true after this conversation that was not true before it?
That last question is the one most designers skip. They prepare to present. They do not prepare to land somewhere specific. Those are different things.
Act Two: Establish Trust
Your story is only as believable as you are credible. Showing up unprepared, with a disorganized file and no clear plan, tells your audience something about your work before you say a word.
Be ready. Remove distractions. Have a plan and communicate it upfront. None of this is complicated but all of it is frequently ignored. The designer who says “here is what I am going to walk you through and here is what I need from you at the end” immediately reads as someone worth listening to.
Act Three: Use a Structure
Simple and repeatable story structures save you time and save your audience cognitive load. The oldest one still works: tell them what you are going to tell them, tell them, then tell them what you told them. Introduction, body, summary. It is not exciting but it is effective, and effective is the goal.
Everything we build is part of a larger story. That story has three acts: context (what are we working on and who is it for), struggle (what is the problem we are trying to solve), and transformation (how are we going to solve it). If you cannot map what you are presenting onto that arc, you do not yet understand what you are presenting well enough to present it.
Act Four: Ground Everything in Why, Not What
This is the single most important thing in this entire post.
There are two ways to present a design decision. Here is the wrong way:
“On this screen I used a list view with a search box and filters on top.”
Here is the right way:
“Our goal is to reduce the time needed for customers to perform key tasks in the admin console. We have data from contact logs and tests telling us that finding user records is a source of frustration. A common case is system admins needing to find a specific user so they can change their permissions. They are in a rush and it is a needle in a haystack: 50% of our customers have more than 10,000 users in their system. Search and filters make it easy to narrow down and the list view shows enough data to confirm they have found the right user.”
The first version describes the design. The second version tells the story of why the design is the right answer to a real problem. Only one of those will survive a stakeholder review.
When you present, make sure you cover: the goal, the user, what they need to do, why it is hard, and why the design you are showing is the right response to all of that. If you can answer all five of those things fluently, you are ready to present. If you cannot, keep working.
Act Five: Show AND Tell
There are two modes of design presentation and both have their place.
Formal presentations from a slide deck work best when you are presenting to a group that needs context before they can give feedback. Keep slides simple. One idea per slide. More visuals, less text. If you find yourself reading the text on your own slides during the presentation, the slide content needs to change. And skip the transitions. Nobody has ever been convinced by a fade animation.
Informal presentations from your source file work best in working sessions where feedback is the goal. If you are walking someone through Figma, keep your file organized enough that you are not apologizing for the chaos as you navigate it. Zoom to fit on the frame you want to discuss. Do not pan around frantically. Take notes in the file in real time as decisions get made. Document the outcome of the conversation in the place where the work lives.
The Epilogue
Storytelling is not a silver bullet. It will not solve every challenge you face as a UX practitioner. But it will differentiate you from other UX practitioners, because most of them are still describing what they built rather than arguing for why it matters.
You do not have to implement all of this at once. Take one piece and start using it. Ground your next design presentation in why before you say a single word about what. See what happens to the conversation.
It is the job that is never started that takes longest to finish.
Amber Hansford is a Director of UX based in Atlanta. She has spent 15 years leading design organizations and an embarrassingly long time writing fiction. She presents at Camp UX because she believes the best UX practitioners are also the best storytellers, and that is not a coincidence.
