What is storytelling? More and more, in design, we’re told that we need to be great storytellers. But what does storytelling actually mean, and more importantly what does it mean in the context of design?
Webster has a few definitions for story: “an account of incidents or events”, “a statement regarding the facts pertinent to a situation in question”, or “a fictional narrative shorter than a novel.”
For many, when the term “storytelling” is thrown around, it’s that last definition that frames its meaning, “a fictional narrative shorter than a novel.” But that definition carries with it a significant amount of baggage and deeper cultural meaning, which I believe drives anxiety and confusion about what storytelling in design is actually supposed to be.
A good narrative, fictional or not, has a set structure and key elements that carry a person through it. This includes an exposition (beginning), conflict, rising action, climax and denouement (ending), as well as characters, settings, plot points, etc. With the pressure for all of us to be storytellers, we find ourselves contorting our processes and artifacts to fit each of those elements. Personas become characters, flows take on narrative structures and so on. In many cases, the comparisons are loose at best and the contortions quickly feel like an overreach. Further, if the majority of the story structure we are creating is filled by the steps in our design process then whatever story we are telling is a story we are telling ourselves, not a story we are telling our customers (unless you publish your personas and user journeys as part of your product releases).
However, this doesn’t mean that we aren’t storytellers. But, foundationally, I think we are zeroing in on the wrong aspect of what makes a good story. A narrative structure is just a mechanism, the how, it is not the end result. What we are really talking about when we say we need to be great storytellers is that we need to be able to elicit emotion. The end result of a great story is that a person feels an emotion, but emotion can also be felt without telling a story.
With this in mind, there are two key areas where emotion can play a critical role in delivering great design.
I. Emotion in the things we create
We want people to love our products and enjoy their experience. These goals are actually another reason the narrative metaphor breaks down. A truly compelling narrative creates tension, often making the person experiencing it feel uncomfortable, sad, or concerned. These are not typically feelings you want your product to elicit. If we are actually telling stories in our products, then almost all of them are going to be boring, contrived fluff pieces with no real conflict. Luckily we don’t have to worry about that, because we are not telling stories. We’re just trying to make people feel good.
To accomplish this, we need to create an emotional narrative, which is very different from a literal narrative. An emotional narrative is just about tone, it’s not about story arch. Copy, visuals, and interactions can all connect to convey and elicit positive emotion throughout an experience, with no tension, no conflict, no characters, and no plot points.
Ultimately, your product may become part of a person’s story, as in “I lost my keys last night and I had to call an Uber to get home.” In this case, Uber is a plot point in the story, but it is not the story. As a product designer, your goal is not to write that narrative, your goal is to ensure that when your product becomes part of that narrative it plays a positive role.
A note on process. I’ve seen a number of discussions where the design process is framed as storytelling using user scenarios, personas, etc, as narrative elements. Something similar to the Uber example above. Developing scenarios and use cases that place the product into a person’s story. While there can be validity to this approach, it is important that it is done carefully.
Developing UX deliverables like personas, user journeys and scenarios is already a deeply fraught process. It is so easy to slip into biased, best-case scenario thinking. This can result in artifacts that conveniently portray target customers and use-cases that perfectly validate the vision you already had for the product, but which might not actually exist in reality.
The further you push yourself into “storytelling” mode the more likely you are to end up in the realm of fiction because you feel compelled to create a narrative. Further, it’s also easy, when taking this approach, to build the narrative around the product, as opposed to building it around the person. It’s a fine line and sometimes this happens unconsciously. When this happens, it can cause you to overestimate the role a product will play in a person’s life, building false justification for extra features and creating unrealistic expectations for engagement.
I have found that it can be more beneficial to strip a lot of narrative storytelling out of UX deliverables. It helps keep them objective and focuses the team on the critical insights and information. Those insights can sometimes get lost when you add a bunch of extra, non-critical details for the sake of building a story. So many deliverables are full of useless data points designed to make the persona or scenario “feel real”, but that do nothing to actually help make design decisions. These are just distractions.
II. Emotion in the way you present your work
The skills required to effectively present and “sell” your work are arguably the most important skills you can build as a designer.
In their book, The Leadership Challenge, authors Kouzes and Posner lay out five Practices of Exemplary Leadership. One of the most critical (and challenging) is to “Inspire a Shared Vision.” This is about envisioning the future and enlisting others into that vision.
We focus heavily on building the hard skills of design, with a feeling that usable and aesthetically pleasing design is like a magnet that will just draw people in with awe and wonder. This, of course, is not the case. If you can’t get your stakeholders on board with your vision, you’re design skills mean very little. I’ve watched countless great ideas and excellent designs die because the designer couldn’t get anyone to care, and I’ve had my own ideas killed because I failed in that task as well.
Part of effectively presenting work is in the way you build a “story” around it, but here again, this isn’t about traditional narrative structure. In this case, there are different elements to consider:
- Setting Context (tell me why this is important)
- Showing the Solution (why does this solve the problem)
- Defining Success (how are we going to know if this works)
Setting Context: This is the most critical component. No one will sign onto a vision if they don’t understand why it matters.
This isn’t about communicating why the work is important to you, this is about communicating why the work should be important to the audience. This is an important distinction because often we approach the idea of setting context by walking people through our process. What research we did, how we did it, what we found, our personas, our flows and so on. These are the important things to us, these are not important things to most other people. The key is to use the information you’ve gained from the design process to get others excited about the project. Why should they care? Answering this question means you have to have an understanding of the many roles within the company, the individuals who fill them and be able to conceptualize your work through the lens of their goals and needs.
When I was head of UX in my previous job, my team and I decided that we needed to build a new app to solve a specific challenge. We couldn’t do this on our own so we had to sell the idea across the company. This meant enlisting not just the design team, but the leadership and staff in engineering, marketing, finance, and content, not to mention the CEO.
The context required for each of these groups was very different. Enlisting the marketing team meant helping them understand not only the value for the user and business but why it would enhance their strategy. The content team had to understand that the effort to create new content for the experience (in this case videos) would be time well spent. Finance needed to understand the business case and the expected resource requirements. And so on.
This wasn’t just one big meeting with key stakeholders, this was many individual and small team meetings which allowed us to get the project done.
In setting context, as in most things, less is more. Your goal is to determine the minimum information needed to get someone on board and keep it at that. Just like having personas with too much information, too much context distracts from the important points. Sometimes we feel like we need to show everything we’ve done to prove that we’ve been working hard or to get recognition for the amount of effort we’ve put in. The goal is not to show your work, the goal is to enlist people into your vision.
Finally, it is important to remember that context requires repetition. People are flooded with new priorities every day. To keep an organization focused and on the same page you need to constantly remind people why a project is important. Every check-in at each stage of a project should include at least a brief reminder of the context at the outset. This even includes one-on-one design reviews with the person who assigned you the work. It may feel redundant but it frames all conversations around what’s important.
Showing the Solution: Once the context is set you can show the solution. Depending on the stage of the work this could be anything from a conceptual discussion to high fidelity designs.
The key is to always anchor your work back to the context you set. Reinforce why this is solving the problem. You want the audience to not only feel like the work is important but that what they are about to help you create is heading in the right direction.
The level of detail here is relative to the audience and goal of the meeting. A functional design review with engineering is probably going to require a significantly higher level of detail than a walkthrough for the executive team. Understand your context, both through the lens of goals and individual expectations. This is not one size fits all.
Defining Success: In terms of importance, defining success is a close second to setting context. Defining success does two things in building a vision and eliciting emotion. First, it allows people to conceptualize and take ownership of what is important in a project. You can’t win the game unless you know how the score is being kept. Being clear on the definition of success empowers each team to determine the best way to win.
Secondly, it codifies a shared goal across teams. This is what we are trying to accomplish and here is how we will all measure it together. Setting this expectation and getting buy-in on the definition means that if the project succeeds everyone gets to celebrate and if it fails everyone gets to work together to determine why and figure out next steps. Without defining success everyone is just left to wonder if the effort was worth it.
How You Show Up
The final and most important piece to effectively presenting your work is in how you show up. Your level of enthusiasm for the work will set the tone for the entire discussion. This doesn’t mean you need to do an over the top musical number but it does mean that you need to be intentional in your approach. Everything from body language to the words you use and the way you deliver them plays into the story others create about your work.
This isn’t always easy, sometimes you aren’t excited about the work, or you’re having a bad day. It’s important to remember that your work represents you and you represent your work. Finding a well of energy, even in those low times, is important in putting yourself and your work in the best possible light.
This doesn’t mean you need to sugar coat things or always be overly positive. If you aren’t happy with how something is turning out or are having a bout of imposter syndrome you can be honest about that, but be intentional about the way you approach it. For example, you could say — “I’m really not happy with this. I wasn’t sure what to do and I don’t love where I landed.” This primes whoever you’re meeting with to feel like the work is going to be bad, and that progress isn’t being made. A negative expectation has been set for the entire discussion. Versus something like — “I’ve made some progress, but I still have a lot of questions I’m working through. I’m really interested to get your feedback and ideas.” This communicates the same thing but the tonal shift tells a completely different story. The emotion you are eliciting is positive instead of negative. Now everyone is going into the discussion feeling like progress has been made, and though there are still things to figure out, this a chance to do it together.
—
In design, story is all about emotion. Our goal is not to build characters and plot, it is to convey and elicit feelings. This can fold into your design practice through clarity, understanding, and intention. If you are clear on the emotions you are trying to drive, understand the people who will engage with your work and are intentional with your approach, the story writes itself.
—
“What is storytelling in design?” was originally published in Medium on March 28, 2019.