This is a sample chapter from Donna Lichaw’s new book The User’s Journey: Storymapping Products That People Love. 2016 Rosenfeld Media.
Chapter 7: Using Your Story
“As for the story, whether the poet takes it ready made or constructs it for himself, he should first sketch its general outline, and then fill in the episodes and amplify in detail.”—Aristotle, Poetics
When I first started to teach people how to map out stories for product and service design and development, I gave them the choice: use your story as a loose guide, or plot methodically onto a narrative arc diagram. I don’t like to dictate process, nor do you want to be told exactly how to do your work. That said, I will tell you this—at least while you’re starting out using this technique, map everything. And do so visually. On a squiggly narrative arc. Then as you explore your stories in different mediums and fidelities, expect that story to change. Your story maps are more like guides than skeletons—they are loose paths for how you intend for people to experience something. As such, they can and should evolve as you explore, as you plan, as you build, and as people interact with what you put out into the world.
I map stories out on a narrative arc because it’s my preferred (read: simple) story diagram of choice and the one that most of my clients and team members grasp most quickly. The narrative arc also models how humans interact with products as moments in time with its linearity and peak near the end. Mapping concepts and flows onto a narrative arc helps you see the flow of ideas and interactions as your users might emotionally experience them.
If you have a background in film or creative writing, you might have another type of diagram you prefer. If so, use that. There are almost as many permutations of narrative architectural diagrams as there are stories. Just remember: the key to all of this is making sure that you have a story that flows through everything you build, not what type of diagram you use.
Squiggly lines on a piece of paper or a whiteboard are cheap. Not having a storyline or losing your thread is expensive. Once you’ve got that squiggly yarn, you can and should thread, prototype, test, and build it into many of the things that you already do: diagram, sketch, write, pitch, analyze, communicate, prototype, build, test…everything. You can explore and evolve your stories on your own or with a group—on the fly or as an organized workshop.
Illustrate Your Story with Strategic Tools
One way to bring your storylines to life is to explore them visually. It might start as a squiggle and then grow into something much bigger and more complex. Activities like diagramming, storyboarding, or journey mapping are strategic tools you might already have in your arsenal. They are each that much more powerful when you use them to uncover, support, or convey your story with your team, stakeholders, or clients.
Flow charts and diagrams are visual stories. You can start off a flow-charting session on a whiteboard by inserting your storyline so that you remember what the story is.
If you do so, as you should do with all flow charts, remember to build around your “happy path” or ideal storyline of how you want someone to experience something. Then, if need be, consider branching paths, edge cases, and alternate scenarios. Systems are branching, and time and experience are linear. Always plan for how you want things to work out and then deviate accordingly. Doing so will not only help you retain your sanity while creating diagrams, but will also remind you how to help people navigate what otherwise might be really complex spaces and systems.
You can also turn your storylines into storyboards or comics, a visual representation of your story that is laid out as panels in a grid.  You can use storyboards to visualize the big picture of how someone thinks about or uses your product (see Figure 7.1) or how to get more detailed and map out specific steps in a flow or interface.
It’s best to keep your storyboards as short as possible—ideally, no more than nine panels. Doing so helps you ensure that your story is there, because it’s easy to lose your storyline when your scope gets too big or your details too plentiful. Keeping your storyline to nine panels also helps you remember to get to the point—plot points. When illustrating a storyboard, you’ll want to make sure that your inciting incident happens as quickly as possible and that your climax or resolution leads to a very swift ending. This means that the climax and end should happen on the second and eighth panel, respectively (see Figure 7.2). Nothing is worse than a beginning or an end that drags on longer than it needs to, whether it is in the telling of a story or experiencing it. Storyboards, just like your squiggles, are essentially a prototype of an experience. Visualizing in this way helps you make sure that your scope and pacing are tight.
“There’s always going to be an entertainment factor that goes into what you’re designing. [But] no matter what, you’re designing to support the story.”—Tim Flattery, “Future Consultant,” Back To The Future Part II 
Storymapping is an excellent way to visually map out a customer or user journey. It will also help you quickly, effectively, and collaboratively assess all the things you need to support the story and make that journey successful for your user and your business. You might already do similar mapping exercises: journey mapping, customer journey mapping, user journey mapping, experience mapping, or agileuser storymapping. I’m sure I’m missing a few names here. No matter what you call it or how you do it, if you want to engage your audience, start with a story map as your framework. Then build on (and under) that map to determine what you need to support your story for your user and your business. Literally, map out the story first and then flesh it out and fill it all in afterwards with Post-it notes or cards (see Figure 7.3).
Here are some ways that you can use story maps to solve different problems:
Gap analysis—You might want to figure out how to get more customers to sign up or get through a flow. Mapping the story as a gap analysis exercise is a great way to visualize the gap between the current state of a journey and the future state that you will build (see Figure 7.4).
Behavior analysis—Sometimes, you want to know what the story is for different types of users. In this case, you might map out your story using different color Post-it notes on an arc (see Figure 7.5). Each color would be for a different user type. Or maybe you want to analyze a more complex set of data so that you can figure out what the story is. In this case, you might map out lots of data points as a narrative (see Figure 7.6).
Needs assessment—What are all the things you need to support your story? Visualizing your story on a wall will help you map out your requirements. This can be simple, where you add Post-it notes as you see fit, or more complex with different rows for different things like front-end requirements and back-end requirements, or haves and don’t-haves (see Figure 7.7).
SWOT analysis—Storylines are a powerful, yet lightweight way to explore and visualize strengths, weaknesses, opportunities, and threats in a journey and more importantly in a product or service. Mapping your storylines out in this way will help you uncover not only what a story could be, but also what works, what doesn’t work, what’s missing, and what could be (see Figure 7.8).
Write Your Story
While visualizing stories is the first step toward making sure that you’ve got a solid, good story, writing that story out helps you uncover additional strengths, weaknesses, gaps, and opportunities that you might otherwise miss. Writing stories out with words is also the first step toward doing something else: communicating your stories, both internally with a team or stakeholders and externally with the world and your users.
No one is sure where the format originated, but there is an origin story that goes something like this: Ernest Hemingway was hanging out with his literary friends. He claimed that he could tell a story in under 10 words. They didn’t believe him. Bets were placed. In a bout of inspiration, Hemingway wrote these six words: “For sale: Baby shoes, never worn.”
While this story might not actually be true, it has inspired an entire literary subgenre of microtales or six-word stories. When you write a story with words, you don’t need to spell out every single thing that happens. Sometimes, you only need a few words to allude to something, and you can let your reader fill in the blanks. In fact, sometimes less is more—more engaging, in this case, as your brain starts parsing meaning and completing the picture.
A short, minimally worded story, when carefully crafted, can act as a prototype for something much larger. More importantly, a short phrase or sentence can help you remember what your story is about as you find, explore, develop, and test it. Think of a short phrase in this case as your shorthand to use internally or externally.
For example, the book you’re reading is a product. I’ve got a Post-it note on my wall reminding me what this book is about as I type. Think like a storymaker. I’m not a marketing professional, and that sentence might never see the light of day in any marketing capacity. But what it does is remind me of my goal, what I’m writing about, and keeps me on point. I want you to think like a storymaker and make awesome stories for your users and business.
At FitCounter, we had a shorthand sentence for our concept story: bite-sized, personalized fitness training, on your own time. It wasn’t marketing-friendly copy by any means. But it kept us on track. Our origin story was something like: feel what it’s like to get fit. It wasn’t pretty, but it also kept us on track.
While short punchy phrases and sentences are helpful to get and stay on track while, during, and after you explore and build your stories, writing longer scenarios gets a different part of your brain functioning. Writing scenarios works much like journey mapping, except that it’s a writing exercise rather than a visual exercise. Scenarios help you use words to uncover how someone might interact with your product or service, as well as what will be required to support the story.
Use Cases and User Stories
Use cases and, more specifically, Agile user stories are a tool that technology teams, especially Agile development teams, use to organize, make sense of, and phrase requirements. Outlining use cases and user stories helps give context to what you build, why, and how. For developers, these tools are important because, much like other humans, developers are story-based creatures. They want to know what the story is before they spend hours, weeks, months, or [gasp] years building something. While Agile user stories are an excellent tool and artifact to envision, articulate, and communicate a body of work with a team, they’re even more powerful if they have a story arc at their foundation. This architecture can bolster an entire body of work, as well as the smaller stories that make up that body of work.
Agile user stories typically are written out in this format:
As a [type of user], I want to/can [do something] so that [result].
At FitCounter, we used to have user stories that read like this:
As a [visitor], I want to [sign up for an account] so that [I can watch videos].
And you know what? No one wants to sign up for an account so that they can watch videos. That’s a terrible story. I have the data to prove it—both quantitative and qualitative.
After we finally figured out what all of our storylines were and could be, we eventually started crafting stories that sounded more like this:
As a [visitor], I want to [sign up for an account] so that [I can save my personalized fitness plan for future use].
What we eventually figured out was that people would sign up for an account if they got value (climax) rather than just got access to something (anticlimax).
While most of this story development happened before we wrote our requirements out as user stories, we made sure that the story was apparent so that developers weren’t building without context. This not only helped the product team align and communicate goals to designers and developers, but it also helped us quickly and effectively assess when our story was missing or when we were building things for no good reason.
Act It Out
Once you’ve got an idea of what your stories and storylines can be, you can also act them out. Doing so helps you uncover more strengths, weaknesses, and opportunities than you do visually or with written words. Additionally, acting your stories out is a great way to prototype and test your stories with real-life humans. Stories need structure, yes. Stories also need to be human-friendly.
Improv and Role-Playing
A good interaction between a person and a product or service functions like a good conversation. As such, you can and should test this conversation out with your team (or even stakeholders or clients) to make sure that the flow is not only sound, but also moves your story forward.
At FitCounter, we live-action prototyped our initial proof of concept, as well as many of our flows and storylines, internally and with potential customers to make sure that we were on the right track.  We even reversed engineered stories from real-life conversations with physical trainers so that we understood how the product could work.
Here’s how a real-life interaction with a trainer and our internal improvisation (improv) sessions played out: imagine you want to start training. You join a gym and get assigned a trainer. When you meet with your trainer for the first time, she might ask you a series of questions so that she can determine your goals and fitness level. At that time, she will make sure to hit on your pain points so that you really know why you’re there (exposition).
Then she might affirm or adjust your goal and tell you that if you work with her, you can attain this goal (inciting incident). Next, you’ll do a series of exercises (rising action) where your trainer might purposely test your strength, endurance, or agility to see how far you can go. These exercises should be easy enough to partially complete (more rising action), but difficult enough so that you either find them physically strenuous by the end or cannot complete them (crisis). Fear not, the trainer tells you. If you stick with her, within a few weeks, you’ll be that much closer to running that 5K or easily doing 30 push-ups or whatever goal or obstacle you want to meet or overcome (climax). She might even show you a visualization that projects how well you will do if you stick with the plan and exercise a few times a week. At this point, you not only hear her words, but you also feel like you just did something and can see yourself coming back weekly to do this until you meet your big goal (falling action). The trainer gives you your 12-week plan, and you’re on your way (end).
Improvising and re-creating stories like these are how we engineered everything from on-boarding to customer service scripts to payment flows. Conversations, role-playing, and improv sessions aren’t just about two people talking and saying words aloud; they embody stories that resonate with people and get them that much closer to meeting a goal. If you try this kind of activity with your team, just remember to consider the story. Nothing is more boring for your customers than a conversation that doesn’t go anywhere.
An elevator pitch is a short statement, sentence, or a few sentences you use to briefly describe a concept, product, or business. It’s called an elevator pitch because it should be short enough that you can give the pitch in the time it takes to ride in an elevator with someone. Elevator pitches are not just marketing or sales tools—they are a strategic tool you can use to make sure you are clear on a product or project’s objectives, market, and value to an intended audience. If you break the format of an elevator pitch down and consider it within the framework of a narrative, it is essentially a very short story.
You can use an elevator pitch to communicate your story to investors, stakeholders, customers, or team members in a fast, portable way that storymaps can’t help you do. If you’re at a cocktail party, meeting with investors, or simply want to get an idea across quickly and effectively, you won’t always be able to draw or show story arcs. But you can speak a few words and see how people respond. Just remember, your story architecture should flow through your elevator pitches so that they are that much stronger. Just like a short and sweet story, your elevator pitch must grab people’s interest, take them on a little journey, and make them see the value in what you’re talking about.
Elevator pitches for products and services come in different formats and generally function like this:
For [target customer] who has [customer need], [product name] is a [market category] that [one key benefit]. Unlike [competition], the product [unique differentiator]. 
If you reverse engineer the format, you can see how this maps out onto and functions much like a concept story:
Target customer = main character
Customer need = inciting incident or problem
Product name, category, one key benefit = rising action
Competition = crisis and conflict
Unique differentiator = climax, resolution, or what’s awesome
And the falling action and end = this is how it all comes together: a customer should be able to use a product not only to get something done, but also to see the benefit and the value. Conflict overcome, crisis averted.
Putting It All Together
Once you’ve got a good idea of what your storylines can be, you’ll want to continue to weave them into everything from the actual physical or digital prototypes that you build, to the way you present your work, to how you test your products with your target market. Stories aren’t just something that should stay in your workplace or with your team—they eventually need to make it to the outside world. Weave them through everything you do related to creating a product, including pitching, presenting, and demonstrating your ideas.
Build and Communicate
Consider how story ultimately wove through the first iPhone. When Steve Jobs gave his keynote presentation in announcing the iPhone 2007, he had a vision for the product, and knew how to weave that vision into everything from the design, the presentation, and even the prototype of the first iPhone. It turns out that the product he demonstrated that day to illustrate his point that Apple was reimagining the way we communicate wasn’t an actual functioning iPhone—it was a semi-functional prototype.  As such, the device was essentially a prop that supported the overall vision and story as he walked the world through a series of smaller storylines that introduced features and functionality like the ability to pinch and zoom into a high-resolution photo or search for Starbucks on a map, call the store, and order 1,000 lattes.
“And here we are…boom!”
Those are the words that Steve Jobs used during his presentation to narrate how you search for and locate something in the Google Maps app on the first iPhone as he demonstrated the device onstage. As behind-the-scenes accounts now tell us, the prototype was only marginally functional; it could barely catch a Wi-Fi signal, make a phone call, or operate without crashing. And as owners of the first iPhones remember, the phone was not at all fully featured compared to other smartphones on the market. The Palm Treo, which was the best-selling smartphone the year before, not only had features like cut-and-paste, but it also let you install apps and games. The iPhone did neither. But what the iPhone and in particular the cobbled-together prototype that Jobs demonstrated did do was go “boom.” Just like a good story.
The perfectly timed “boom” during this demo and overall presentation was not a coincidence. In fact, it is just like that one plot point from the fourth season of Breaking Bad (see Chapter 1): BOOM. Only instead of actual explosions, the “boom” Jobs was narrating was a tiny animation that transpired when a pin dropped on a map (see Figure 7.9). This animation was so fast and tiny that if you weren’t looking for it, you missed it. But if you spent years working at Pixar or being forced to watch and analyze scenes and sequences over and over, you noticed it. And if you spend some time after reading this book looking for and analyzing sequences and flows like the one for adding a calendar event in Fantastical, you’ll start to notice them, too. Nothing is too small, fast, or insignificant to inject into a design or prototype as long as it supports the story. If the story is strong and compelling enough—like the ability to search anywhere on the globe using your phone, which was a revolutionary concept in 2007—you not only save that demo for last, but you also emphasize the story with narration. Just like Jobs did.
Prototyping, demonstrating, and presenting your work, whether you are a designer, developer, product manager, executive, or founder is essential for conveying why your product is great and for explaining how it works and why it matters. Plus, it’s essential for getting buy-in, whether it is from an internal sponsor team, clients, or the world audience.
At FitCounter, we wove our storylines into everything from research to design, to strategy and presentations, demonstrations, and even board and investor pitch decks. And it worked. Without a story, our customers and potential investors were confused. With a story, they were excited. The great thing was that both investors and customers put their money where their mouths were. So much so that the actual start-up that the story is based on is doing great—they have a story and the revenue generation to show for it.
Again, this is not just film magic or some kind of smoke-and-mirrors illusion or sleight of hand. It’s good old story craft that is built for how humans interact with and understand the world around them. It works for the idea of a product, the actual product, and how you present that product to the world. It not only helps you sell your products, but it also makes them better, overall. More importantly, a story-first approach helps your customers have a better experience with that product. There are not enough smokes and mirrors in the world that can make humans unwittingly fake that on their end. Designing with story is designing for humans.
If you ever want to learn from the master of product stories, I recommend sitting down for an hour one day and watching that first iPhone keynote address from start to finish. In that presentation, you will see how someone uses story and story structure to build excitement about concepts and use cases. In the presentation, the iPhone isn’t the star—rather, you are the star as you envision all of the things that you could do with this device in your hand. As an origin story, this story ends with you eventually buying the device as many people did and continue to do around the world. More importantly, however, it ends with you having a new and better way to do what you didn’t realize you needed to do: communicate.
Was this presentation crafted with a clear overarching storyline and subplots? Absolutely. The best presentation experts in the world advocate using story architecture to bolster presentations. Was Steve Jobs aware of how powerful story structure could be when he demonstrated the smallest subplot or usage story for searching for and finding a location on a map? Undoubtedly. He spent years before going back to Apple working with Pixar—a bastion of visual storytelling and animation. As any filmmaker will tell you, everything you put in the scene must support the story.
While storytelling comes naturally to many of us, it is worthwhile to meticulously and carefully map out everything from how a prototype functions to how you ultimately present that prototype or a broader product idea to an audience. The better the story, the more engaging both your prototype and presentation will be.
Test and Validate
Stories are not just for building and communicating. They must resonate with your audience. Every step of the way, you must test your stories to make sure that you’re on track. Diagrams, storyboards, written words, pitches, improv, prototypes, demos, presentations—these are all artifacts and activities you can use to test your stories with your target audience to make sure that you’re on the right track.
How do you know you’re on the right track? First, once you start to use story more in your work, you’ll start to see when something is or isn’t a solid story. Then, when you start putting your ideas in front of people, you’ll start to get feedback. Maybe a story will or won’t resonate with someone. Maybe people will tell you when something doesn’t make sense to them. Maybe they’ll smile at just the right time during a usability or concept test, validating your hunch that the climax was what you thought it would be. And if all goes well, maybe even journalists will hear about your product, use your product, and unwittingly echo your story.
When a story is structurally sound, it flows through everything. It’s not only up to you to make sure that you engineer around the story, but also that the story resonates with and is echoed by the outside world.
Discount for UXmatters Readers—Buy The User’s Journey: Storymapping Products That People Love from Rosenfeld Media, using the discount code uxmatterstuj, and save 20% off the retail price.
 For more on creating storyboards and comics, see Cheng, Kevin. See What I Mean: How to Use Comics to Communicate Ideas. Brooklyn, NY: Rosenfeld Media, 2012.
Donna is a product management and UX strategy consultant, advisor, speaker, and educator. She specializes in mobile, tablet, responsive Web, and mobile-first product strategy—getting the best results by helping teams to think big by starting small. Donna has worked with a variety of businesses around the world, from startups to nonprofits to established Fortune-500 companies such as Seamless, Citi, Bloomberg, Apartment Therapy, WNYC, Atlantic Records, The New School, and Nerve.com. She has previously taught at Parsons The New School for Design and Northwestern University and currently teaches at NYU and General Assembly in New York City. Read More