Storytelling in Product Design: Achieving Team Alignment through Narrative
One of the most challenging aspects of designing a product with a team is getting alignment. How do you get all of your stakeholders on the same page and agreed on a direction? This is especially tricky in the early phases of strategic planning, when project goals are undefined and evolving.
At this fluid stage, when even simple ideas seem complex and vague, there is one design artifact that can be magically effective: telling a story. Nothing works better at slicing through complexity to get to a shared understanding of the project’s goals. It can help stop circular discussions and allow the team to focus.
Storytelling is especially effective when it comes to working with concepts that are highly complex and intricate, like an entire software cloud. But first let’s look at a simple feature-level example.
Imagine a team working on a new feature that allows a user to attach a comment to a graphic. It sounds straightforward, but it’s likely each team member is picturing a different version of what a “comment” means. Is it like a sticky note? Is it like social media? Can I draw on it? In trying to describe it, the team can create a kitchen sink version, with several conflicting ideas that only causes confusion about the core idea.
A designer’s job is to alleviate this confusion with some kind of artifact — typically a mockup, wireframe, or prototype. The artifact gives the team a common point of reference and forces choices to be made. Even if the artifact is poor, it will still help with confusion by creating some small shared understanding. “That’s not what we meant!” is still useful in terms of feedback.
Storytelling can have the same impact as an artifact, only it can address much more complexity.
Instead of a feature, imagine a project that involves multiple users across multiple products. In terms of design artifacts, we’d likely need several hundred to describe the full product design. That’s insanity when the goal is simply to get alignment on the big picture. In a scenario like this, the confusion to address is about the forest, not the trees.
Just like a standard design artifact, a story gives the team a common point of reference and forces choices to be made. By creating a scenario to follow, the team can see whether various ideas contribute to a cohesive concept, or fail to add up to an interesting “forest.” (Of course, the scenario may or may not be realistic to actual customers, but that’s a much easier thing to address after getting alignment.)
Building the Story
To create a story for alignment purposes, there are a couple of key elements.
To begin with, choose a simple goal for your story to address. Make it tangible — this is not the time for mission statement vagueness. Create a specific task with constraints for the characters to act upon. “The marketing team must produce a promotional microsite by Friday.”
Speaking of characters, create a cast. Complex scenarios involve multiple people, and it’s helpful to define how they relate to each other up front. What are their jobs? What are their relationships (boss, client, etc.)?
The most important item is a script. This is the master document of the production, and should be iterated over time just like a mockup. Formatting is unimportant — whatever works to capture the detailed step-by-step of the story. If you can base the steps on real-world research, all the better. But even if you are just making assumptions, try to be as detailed as possible. Include distinct chapters or scenes to break up the story into digestible chunks to help viewers follow along.
Whatever the format, the story presentation should begin with a prologue that describes the goal and setting, and introduces the characters. Establishing the scenario should set the context for your product.
After that, the bulk of the presentation should be visualizations of interactions with the product. These can be screen UX, examples of output, instant message transcripts, even futuristic holographic displays. Having fun with the visualizations leads to the best side-effect of storytelling: inspiration.
Don’t worry about whether the UX works at this stage. This process will often reveal what you don’t need to build, so it’s not worth getting into the weeds of how things work now. Conversely, don’t neglect delightful UX moments. They contribute to the inspiration side-effect. (Motion graphics and video are helpful too, but not critical.)
Creating a story artifact should be an iterative process. You might even consider showing a version to real users. Does the story make sense to them? Is it similar to their own story? What are the plot holes? Real user feedback will help you know if you’ve created a documentary or a work of fiction.
Once the story helps to get alignment, the story can provide a map to the actual product design and lead to the next stages of development. It can help prioritize an MVP, and identify areas that need more investigation. And it can even be used as reference to see if the project has stayed on track. If not, maybe it’s time to write a new story.