The User’s Journey: Storymapping Products That People Love

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.

Micro-Stories

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.”

Hemingway won.

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.

Scenarios

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. [3] 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.

Elevator Pitch

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]. [4]

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. [5] 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.

Endnotes

[1] 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.

[2] Trendacosta, Katharine. “Brand New Concept Art of Back to the Future Part II’s 2015 Technology.” io9.

[3] For more on live-action improve, see Gray, David, and Sunni Brown. Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers. Sebastopol, CA: O’Reilly, 2010.

[4] While there are many different types of elevator pitch formats, I like to use … [the format from Gamestorming].

[5] Vogelstein, Fred. “And Then Steve Said, ‘Let There Be an iPhone’.” The New York Times, October 5, 2013. Web: May 28, 2015.