CHAPTER 5

Usage Stories

What Is a Usage Story?

How Usage Stories Work

Case Study: Twitter

Mapping the Usage Story

How Big Should Your Story Be?

Case Study: FitCounter

“The same core features appear in the rules of narratives and in the memories of colonoscopies, vacations, and films.”

—Daniel Kahneman,
Thinking Fast And Slow

In the 1970s, researchers conducted a series of experiments on how humans experience pain. Their subjects were patients who underwent colonoscopies. While the technology and overall procedure is now less painful than it used to be, back then it was not just unpleasant, but extremely painful. What the researchers wanted to know was if the duration of a procedure affected the overall experience. In other words, if a painful procedure was twice as long, did a patient consider it to be twice as painful? Or if it was half as long, was it half as painful? The researchers learned that while duration plays a slight role, other factors play a bigger role in shaping experience: peaks and ends.

The researchers used self-reporting mechanisms to record how patients felt both during and after the procedure. Test subjects were asked to rate their pain level on a scale from 1 to 10 on regular intervals, 1 being the least and 10 being the most painful. After the procedure, they were then asked how it was overall and how likely they were to choose to have the procedure again in the future. Researchers assumed that the more painful and longer the procedure, the less likely a subject would want to repeat it.

It turns out, however, that if two patients rated their pain level as consistently high throughout the procedure, the patient with the shorter procedure was no more or less likely to rate it differently than the other patient. Both rated it as awful and were not likely to want to repeat it. If a patient experienced extreme pain for three quarters of the way through the experience and then felt that pain gradually ease until the procedure ended without pain, the results were drastically different. That particular patient was more likely to rate the overall pain level as being lower than the other patients. And these patients were also more likely to say that they would have this procedure in the future.

What researchers extrapolated from this and other studies like it is that humans remember, not duration, but rather the peak of an experience and whatever happened closest to the end. This phenomenon is called the peak-end rule (see Figure 5.1). A peak can be painful, as in the case of a colonoscopy, or it can be enjoyable as with a vacation, a film, or—gasp—the experience you have using a website, app, product, or service. Everything—even the experience you have when you use billpay through your bank’s website or app—is a story. It’s up to you as someone who designs or builds things to determine if that story is going to be a good one or not.

FIGURE 5.1
The peak-end rule not at all coincidentally mirrors the structure of a narrative arc.

As Nobel prize-winning psychologist Daniel Kahneman, who worked on this study, points out, there is a reason why our brains have evolved to give shape to how we comprehend and communicate experiences. There is no such thing as an actual experience. All you have are moments in time. A moment ago? It’s already gone. The moment you took to read this sentence is already gone by the time you reach the end of the sentence. Time is fleeting. All you have is the memory of events that happened in time and the ability to stitch together and parse meaning from those data-points into a coherent narrative.

This real-time processing is what sets apart humans from other animals. The foundation of this cognitive function is story. And story has structure. Story is how you make sense of the world around you—before, during, and after an experience. When you consume a story, whether it involves listening to a story or parsing life as a story in real time, your brain is activated. If what you just experienced maps out to a narrative structure, with a beginning, hook, middle, peak, and end, it maps out to how your brain is pre-programmed to understand the experience. When you experience something like a story, it affects comprehension, utility, perception of usability, memory, and choice. In other words, you’re more likely to understand something, see it as useful, find it easier to comprehend or use, remember what you just experienced, and want to repeat the experience again. Even painful medical procedures. Or sign-up flows.

What Is a Usage Story?

Usage stories are exactly what they sound like: the story of someone using your product or service—step by step. It’s the actual steps that make up the story for your user, plot point by plot point. The steps in a usage story can involve screens, if you’re working on a screen-based website, app, or software. Or the steps can be things that happen outside of the screen if you’re working on something that is entirely non-screen-based, such as an experience strategy for a university welcome center.

More than likely, anything you build a usage story for will be a combination of screen and non-screen-based steps. For example, that university welcome center might have screen-based kiosks that help visitors find what they’re looking for, as well as signage and other affordances—oh, and humans who might hang out at a service desk. That app you’re building might have a user flow with steps that take place outside of the screen, such as when a customer calls customer service for help. It is essential to consider usage stories within their broader context of who, what, when, where, and why someone is doing something. And, of course, it is essential to consider, assess, and plan for the intended story of use. Plot point by plot point.

How Usage Stories Work

You can employ usage stories to figure out how to structure journeys, long and short. A usage story can take place over a period of seconds, minutes, days, weeks, or years. They help you figure not what a customer should think about your product or how they find your product, but how and why he will use, experience value in using, and continue to use your product in one sitting or over time.

Just as with concept and origin stories, your usage stories can be based on real data or sketched out as a hypothesis. For example, if you are troubleshooting a checkout flow and want to figure out why people add items to their cart but rarely check out, you can use real data. You might get that data from your web analytics, in-person user interviews, usability testing, or all of the above. If you’re inventing a product from scratch and figuring out how a key flow works for the very first time, you might base it on data gathered from market or user research or use stories as a way to think outside the box and get creative with how you envision your product working. Or both.

Here is how they operate (see Figure 5.2).

• Exposition—current state of things (same as your concept and origin stories)

• Inciting Incident/Problem—event, trigger, or call to action (CTA)

• Rising Action—a series of steps

• Crisis—potential hurdle or hurdles

• Climax/Resolution—the high point when value is experienced

• Falling Action—then what? Final step in the flow

• End—the end…for now

FIGURE 5.2
The model for a usage story.

Exposition

Exposition represents the beginning of the story. There is a main character with a broad goal (which is the same as your concept and origin stories). Where are they at the beginning of the story? Are they using an app, website, in-person service, or all of the above? If you are working on a journey for a business that employs all three as part of their customer service strategy, you might keep your story high level and consider how it works for all three at the same time. For example, the high-level story for someone who is thinking about applying to college is the same whether she is working with a guidance counselor at her high school or doing online research alone. Your character is someone, and she wants something. Does she want to find the right school so she can become a veterinarian someday? Or does she want to find a school that will let her explore career opportunities? Or does she not care about career opportunities and want to study with like-minded people? Does she want to learn more about your school or apply to school? Each exposition is the beginning of a very different story.

Inciting Incident/Problem

The inciting incident is an incentive, trigger, or call to action—something to kick-start this journey. This step should map out onto the problem you outlined in your concept story. If your character is on your home page and her goal is to find a school that will let her explore her interests, how will you kickstart her journey? First, you want to remind yourself what her problem is. Why can’t she meet her goal? Because she doesn’t know where to start and is overwhelmed by the post-secondary educational landscape, options and opportunities? This is the point where you need to get her to look, listen, and take action. How will you do that? Or if her goal is to apply for the next calendar year, how will you kickstart that journey? As you can start to see, there are many journeys that your user will go on throughout their lifetime of engaging with your product or brand. Each gets its own story as you figure out how to help people meet their goals.

Rising Action

The rising action represents a series of steps or actions the person must take to meet his goal. Each step should build the user’s interest and become more interesting or relevant than the last step. This is where the Y-axis of a structurally sound story is especially important. Things don’t get good or bad for your user. They get better and better. Just like a good movie, your user should want to continue onto the next step, screen by screen. Action rises and tension rises as your user gets more and more engaged as he tries to meet his goal.

Crisis

The crisis is the impediment that must be overcome for the user to get to the high point of this experience. Impediments can include things like the following:

• Requiring sign-up

• Requiring payment or sensitive billing information

• Mental hurdles, such as boredom, unmatched mental models, or a lack of value

• Poor usability

• Other mysteries—sometimes analytics show a drop-off in funnel completion, and it’s necessary to do some research and storymapping to figure out why people are dropping off

Climax/Resolution

The problem is solved, and the crisis averted. What matters most for a usage story is not just that the problem is solved, but how it is solved. This is where the user experiences value or just feels good about what he is doing. It’s the high point of this flow. If just solving a problem is awesome enough, the story will flow well, yet be anti-climactic. Sometimes, however, you need an extra flourish to raise the action level of this plot point to make it more memorable. This “raising of the bar” can be something as simple as an animation for a digital flow, amazing customer service, or a gift for a non-digital service flow.

Falling Action

Falling action occurs when the user finishes the flow. The flow can’t just end on a high point—it has to go somewhere and take the user with it. In the case of a sign-up flow, for example, imagine if it ended with a Thank You page. What then? Ask yourself that question every time you build a usage flow and be sure to figure out how it should end.

End

In the end, just like with a concept and origin story, the user’s goal is met. The flow is over, and the user should be in a better place than when he started. If you intend for this story to continue at this point, you can consider this stage to be where the goal is met…for now. Just because the hero saves the village doesn’t mean that he won’t have to undertake a new journey in the next episode. Additionally, in a good story, the main character never just ends up at home after a journey, he should have learned something, found something, or generally grown as a character so that when he arrives back home, he is changed forever and is closer to meeting his big goal or goals.

Case Study: Twitter

One of my favorite examples of a usage story is Twitter’s former sign-up flow. While they have since updated this flow, I like using this illustration because it is an excellent example of story structure supporting a flow of screens and interactions. Additionally, this sign-up flow was responsible for not just activating hundreds of millions of new users, but also users who were more valuable and likely to stay engaged with the service over time. While it was not explicitly engineered as such, this on-boarding flow reads (and functions) like a good story.

The Problem: Low Repeat Engagement

Several years ago, Twitter had a problem: it was starting to grow its user base at a steady clip. But unfortunately, Twitter acquired many new users who tried the service once and then never returned. Twitter’s research team talked to users who did return to find out why and what mattered to them.

The answer: people were more likely to log in and engage with the service if they followed others on Twitter who were in their social and professional circles or related to their hobbies and interests. While Twitter’s previous sign-up flow was simple, fast, and friction-less—it was only three steps—it didn’t do enough to help new users see the value in the service so that they would return.

The Solution: First-Time Use as a Story

Often, there is a rule of thumb that you want to design frictionless experiences so that people get through a flow or process more easily. The easier something is to do or use, the more quickly people will get through it and the more delightful (or less painful) the experience will be, this line of reasoning goes. Make it easy to use! is the phrase that your client or stakeholder might outline as a requirement for that flow in the app that you’re building anew or redesigning for better conversion. If you think about a usage flow as a story, however, you can see that friction is a good thing. If you think about scientific studies on painful medical procedures, you can also see that shorter isn’t necessarily better. What the sign-up flow that Twitter eventually came up with shows is that making something more difficult and longer can be better as long as it reads like a story. Here’s how the longer, more complex sign-up flow breaks down as a story:

Exposition

You’re visiting the Twitter homepage, which means that you want to know what this Twitter thing is all about (see Figure 5.3). Twitter as a business has the flipside of that goal: it wants to show you what Twitter is all about. It also has a more specific goal: to get you to follow relevant accounts so that you are more likely to return in the future.

FIGURE 5.3
The first screen in the flow sets up an exposition: it reminds you why you came here and then incites you to act with a call to action.

Inciting Incident

You see that Twitter is a way to “Start a conversation, explore your interests, and be in the know.” Cool, those are all things that you’d like to do. You sign up.

Rising Action

First, you are introduced to the concept of a “tweet,” as seen in Figure 5.4. You are on a screen that looks much like what the Twitter app will look like when you are finished. Only there are instructions on the left sidebar and a not-yet-populated area on the right. Someone named the “Twitter Teacher” explains that what you’re looking at is a “tweet.” You can also see that there are many more tweets awaiting you. You click on the “next” button.

FIGURE 5.4
The first step in the rising action of Twitter’s sign-up flow is to learn about a tweet.

Next, you are introduced to the idea of your “timeline” (see Figure 5.5), which you can “build.” If you click on a person on the left, you can see one of his tweets show up in the timeline on the right. Click on another, same thing happens. This is how Twitter works—you follow people, and their tweets show up in your timeline. But Twitter doesn’t just tell you all of this; you have to actually do it a few times before you can go on to the next step.

FIGURE 5.5
In the second step of Twitter’s sign-up flow, you learn about a timeline.

Now Twitter invites you to “see who’s here,” as shown in Figure 5.6. While it asks you to “find and follow well-known people,” what it is also illustrating is that there are different types of people to follow, depending on your interests. Even though the previous step let you follow celebrities, now you can have a little more control over who those celebrities are—basketball players, for example. The more you follow, the more your now empty timeline fills up again.

FIGURE 5.6
The third step of Twitter’s sign-up flow shows you how to find and follow people.

Crisis

At some point, after spending a few minutes on this sign-up flow (they claim it only takes 60 seconds, but I never completed it that fast), which is eons in Internet time, you might start to get bored. How many more people do you need to follow? How many more interests and hobbies can you think of? You understand what a tweet and timeline are and how the system works. Why follow more people? Not only that, but is reading tweets from Mariah Carey and Brad Pitt all that Twitter is about? You hit the next button.

Climax/Resolution

Now, Twitter invites you to find people you know (see Figure 5.7). My friends are here? Oh, OK, Twitter isn’t just about following celebrities. I can also follow my friends and see what they’re up to. That’s how Twitter helps me be in the know.

FIGURE 5.7
In what could be a crisis moment of Twitter asking you to add contacts, the climax of the story is when you see that your friends are there.

Mini-Crisis

I want to see which of my friends are on Twitter, but is this secure? I don’t want Twitter to spam my friends or steal my contact information. As I scan down past the call to action buttons on the left side of the screen, I come to a block of text that allays my fears: I can see exactly how this works. It’s safe and secure. Good. I search for and add my contacts from Gmail or wherever.

Falling Action: Add Character

I’ve learned about tweets, followed celebrities, expressed some of my interests, found my friends, and filled out a timeline. I’m part of this community now. I see everyone’s smiling faces and the things they say. I may as well add my avatar and a little bio (see Figure 5.8). I know it should be short because tweets are short. Unlike all of the previous steps in this sign-up flow, I can skip this if I don’t want to add my information.

What I don’t know is that Twitter already got me to do everything it needed me to do—filling out my personal info is nice to have, but not a must-have. Again, what matters is that I understand how “following” works, and I can see the results of following people. At this point, I can add my information or skip it. Falling action like this can be its own story, as with the end of Slack’s on-boarding flow (see Chapter 3, “Concept Stories”).

FIGURE 5.8
For the falling action, you can personalize your profile. This part is optional, however, since you’ve already experienced the value of Twitter: it’s social.

End

I’m home (see Figure 5.9). Logged in home. This home page is different than the home page where I started this journey. Before I signed up for an account, the home page told me that I could be in the know. After signing up for an account, the home page shows me what it’s like to be in the know. I see a timeline full of tweets from people and organizations that I’m interested in about topics that I care about.

FIGURE 5.9
At the end of this story, you arrive home (logged in home). But home is better than when you started (logged out home).

What becomes obvious in the story of Twitter’s on-boarding flow is that it never once prompted you as a new user to actually try sending a tweet. Instead, at the end of the journey, when you end up home, you can just sit back and consume what’s in your timeline without ever sending a tweet. This is a story of following people, consuming content, and being in the know. The story supports not only your user journey, but also a strategic business goal: to get more people to consume content. As Twitter transitioned from a service based on broadcasting to consumption, the story followed along. Traditionally, people are more likely to consume rather than generate content using social media services like Twitter. This flow and resulting story has optimized the story that users are more likely to have and that the business wants them to have.

While the old flow converted new users, the new flow converts quality users—ones who are more likely to engage. You can think of the previous, shorter, simpler flow as the flat or anti-climactic version (similar to the iPhone), or the simple solution for getting people to sign up. The updated flow, on the other hand, is the one that reads more like a story that resonates with the right type of user in the right type of way.

In the end, Twitter is a way to “start a conversation, explore your interests, and be in the know,” as millions of people who signed up for the service using this flow found out. Even though you may not have started a conversation yourself, you can see a timeline full of conversations from people whom you are interested in. By the end of this sign-up flow, you’re in the know and have had an engaging time getting there.

Mapping the Usage Story

Usage stories can be broad or compact. I recommend starting out with the broadest first and working your way down until you’ve uncovered all you need. In my experience, each usage storyline you develop should be as simple and straightforward as possible. At the point that you’re mapping out many subplot points and getting complex, you should ask yourself if you can break your storyline into smaller stories. Then you should address each separately, starting with the largest first.

Imagine if a TV writer tried to plot out a season-long storyline at the same time as a specific scene from a specific episode. As you can imagine, it’s difficult to stay high- and low-level at the same time. Focusing your scope and approaching one storyline at a time will not only improve the quality of your usage stories, but will also help you move faster as you retain focus.

To create a usage story large or small, answer these questions:

• Exposition:

• Who is your target customer?

• What are her goals as they relate to your product?

• What is the problem or impediment standing in the way of this person meeting her goal?

• Inciting Incident:

• What will kick-start the customer on this specific journey? This will probably be some kind of call to action or event.

• Rising Action:

• What is the first action that the user should take?

• What’s next?

• And next?

• Crisis:

• What might get in her way of solving her problem and meeting her goal? It could be something tangible, like a paywall, or emotional, like boredom. For each usage flow, you’re likely to have a list of possible barriers.

• Climax/Resolution:

• What is the high point of this experience or flow?

• How will her problem be resolved?

• What value do you want the user to experience during this flow?

• What will make all of her conflict, crisis, and work she puts in so far be worthwhile? Value can be functional or more abstract, like brand value.

• Falling action:

• What then? Humans like closure. You don’t want to just leave them at a high point and suddenly end the story. Now that her problem is solved, how will you wrap this episode up as quickly as possible so that the user is that much closer to meeting her goal?

• End:

• Where does the user end up—both in terms of character development and logistics? How has she grown? What has she learned? Where is she? What’s next? Is this really the end or perhaps the starting point of her next story?

How Big Should Your Story Be?

Stories can be big. And they can be small. They can happen one at a time. They can happen in serial. There is no right or wrong way to scope out the timeline for your stories. Sometimes, you’ll scope out a very large story that lasts over a period of years in your customer’s journey with your product. Sometimes, you’ll focus on a tiny story that lasts only a few seconds. Scope your story so that it answers whatever questions you need to answer.

Maybe your question is “How do we get customers to stay active after a few years so they don’t keep dropping off?” In that case, you’ll map out an epic journey that lasts a few years. Maybe your question is “How do we get people to come back next time? And the time after that?” In that case, you’ll map out something that looks like a serial or a soap opera. Maybe your question is “How do we get people to keep coming back and using our product to do this one core task when there are competitors out there that also do the same thing?” In that case, you’ll map out a micro-story. In each case, you have the same plot points and overall structure—only the timeline is different.

Epic Journeys

Epic journeys take place over a long period of time. That timeline can be a day, a week, months, or many years. These journeys are epic because they traverse single sittings or interactions with a product. Maybe you want to map out the lifelong journey from when someone starts using your product to infinity. For example, I worked on a project where we needed to assess the content for a nonprofit educational program—all of its content.¹ That was a lot of content! They wanted to go digital and didn’t know what to digitize, what to keep, and what to get rid of.

When we mapped out the user journey over a period of seven years to figure out what content needed to be digital so it could support the story, we saw that there was a lack of content supporting the story around year five, in general. This coincided with a drop-off the nonprofit saw with member engagement, which usually happened around five years after starting to work with the program.

Structuring this journey like a story enabled us to quickly assess strengths, weaknesses, and opportunities in their content and program structure. What it also helped us do was to put an “end” point to the member journey so that we could start to envision ways to help members start a new journey with the program after five to seven years. What we found was that after five years, many members dropped off, while others instead became evangelists for the program, disseminating information and training new members. Mapping the journey helped us see that we could plan for not just one epic that lasted five to seven years, but a second story that could last another five to seven years for the user.

Serials and Soap Operas

Sometimes, you will explore your stories in serial. What treating stories in this fashion helps you do is see the relationship between single interactions with a product as a series of stories (see Figure 5.10), rather than just an epic. Doing so will help you figure out how or why to hook people in, get them invested, and stay invested over time as they want to find out what comes next or see what they missed since the last time they tuned in. Just like a soap opera—or The Wire or Breaking Bad, if that’s more your thing—serials are great ways to visualize, plan for, and troubleshoot long-term engagement with a product or service.

FIGURE 5.10
In a serial narrative, there are mini-stories or episodes that string together over time. Each requires its own beginning, middle, end, and plot points to move the action and user forward.

What visualizing serial stories helps you see is that stories as episodes need to get better for your users over time. If they don’t get better, it’s much harder to keep users engaged over the long term. Treating stories in this matter also helps you visualize the relationship between different episodes or stories.

For example, I once worked for an organization that put on annual events like conferences, workshops, and online seminars. We used serial structure to assess why devoted repeat-attendees attended the first time and chose to return…or not return. The business was selling lots of tickets to its events, and the owners wanted to know if it could do even better. Mapping customer journeys as serial narratives helped us see clearly why people attended (problems and inciting incidents), as well as the value and takeaways that these customers got year-to-year. Mapping serials also enabled us to see the cliffhangers where customers dropped off, as well as gaps and opportunities where the business could add value not just as a whole, but episode by episode.

Micro-Stories: Core Tasks

No flow or task is too small to be treated like a narrative. If you’re designing a core task for a system and want to make sure it’s memorable and wows your user, thinking in a narrative fashion is a great way to add a layer of complexity and excitement to an interaction—even a simple, seemingly trivial one like adding a calendar event.

The most effective story-driven core task interactions I’ve seen don’t happen during activities like checkout flows. Instead, they are core tasks that are central to a product or service, like sending a message or “liking” something on Facebook. Core tasks are interactions that you want and expect users to perform over and over again.

Consider the iOS Calendar app that comes standard with every iPhone. The story of performing the core task of entering a calendar event works like this:

• Exposition: You’re having coffee with Jane at 2 p.m. tomorrow. You want to make sure you remember this event.

• Inciting Incident: You tap the “Add Event” button to add the event to your calendar.

• Rising Action:

• You type an event name.

• Add a location.

• Select a time.

• Crisis: Tap…tap…tap…you have to tap so many times to complete this otherwise simple task.

• Climax/Resolution: You tap to save the event, and the screen slides down out of view to let you know that the action is complete. It’s valuable to know that the system is saving your event and animation supports the story.

• Falling Action: Where did your event go? There is nothing on the screen that shows you where your event went or how to return to it if you want to edit it. You hope you saved and entered everything in correctly. This can be a crisis or a cliffhanger, depending on how it plays out in real life.

• End: If you’re like me, you probably added the event to the wrong day, oops. Or you take a leap of faith and assume that you entered it correctly and will be at coffee on time.

Here’s how the same core task works in another iOS calendaring app, Fantastical:

• Exposition: You’re having lunch with Elon in Palo Alto tomorrow. How exciting. You definitely don’t want to miss this.

• Inciting Incident: You tap the “Add Event” button to add the event to your calendar (see Figure 5.11).

FIGURE 5.11
The inciting incident or call to action of adding a calendar event to Fantastical: a button that lets you add a new event.

• Rising Action: You start typing “Lunch with Elon in Palo Alto” (see Figure 5.12), and the screen starts to fill in your location information on a timeline visualization that shows you when and where lunch is (see Figure 5.13). How smart—it assumes that lunch is at noon. When you’re done adding your event, you tap the Add button (see Figure 5.14).

• Crisis: There is none because…

FIGURE 5.12
Rising action for Fantastical: the text you type animates to indicate that something is happening.

FIGURE 5.13
Rising action for Fantastical: you see that the app automatically parsed your event type and location for noon in Palo Alto.

FIGURE 5.14
Rising action for Fantastical: saving your calendar event.

• Climax/Resolution: The event shrinks and animates onto the correct day in the calendar (see Figure 5.15), and at the end of that animation, it glows red (see Figure 5.16) before the red fades away (see Figure 5.17). It’s such a subtle, fast animation, but it’s helpful to see feedback after you complete a task. Feedback in this case communicates that your event was added and added to the correct day. The animation also supports the mental model of events being placed on a calendar. “Fast and friendly” is how Fantastical’s developers describe the app, and this climax embodies that description. They say it in their marketing materials, and you experience it in the micro-interaction.

FIGURE 5.15
Fantastical: crisis averted. Animation communicates system feedback that your event has been saved.

FIGURE 5.16
Fantastical: crisis averted. The rest of the animation communicates that your event has been saved on the correct date: tomorrow, October 18.

FIGURE 5.17
Fantastical: All done. The end…for now.

• Falling Action/End: You have no doubt that this calendar event was added, not just to your calendar, but also to the correct day. Task complete. You’re glad you downloaded this app to use instead of the Calendar app, which is so not smart.

Something as simple as a calendar app, with a core task that you want users to repeat and repeat, can benefit from this structure. Otherwise, your core task flow falls flat, just like the built-in iOS Calendar app did. Is Apple in trouble? Not at all. Unless calendaring becomes core to their business and engagement strategies.

When software is your service and your primary means for acquiring and retaining customers, you need to make sure that everything, no matter how small, reads like a story. Contrast something seemingly trivial like iOS’s Calendar app to the unboxing experience for the iPhone. The latter absolutely reads like a story, from the moment you rip off the plastic wrap to the minute you turn on your phone… and then continues into the setup UI. The iPhone is core to Apple’s strategy. The iPhone is built on story. Many stories. When it matters, you should plot even the smallest and seemingly trivial core tasks story-first.

For even the smallest interactions, good design incorporates affordances, minimizes steps to completion, and gives users feedback. Story does all of those things, as well.

A good story is good design.

Case Study: FitCounter

In the case of the start-up, FitCounter, as we ideated, tested, and gathered qualitative and quantitative feedback from existing and potential customers, we started to feel like we had a product-market fit with the concept of what the product and service could be. We also successfully envisioned and engineered origin stories that helped visitors find the product, want to use it, and start on their journey of becoming more fit. But having that concept and the first contact was not enough. We needed to create a product that people actually used. Eventually, we also had to see if people would pay to use it, but our hunch was that they needed to try it out first before they could decide whether or not to pay for the upgrade.

In order to see if we had a viable product, we needed to envision, assess, test, and build a minimum representation of a product and service that delivered on this promise of helping people get fit, stay fit, and help others get and stay fit. Our front door was inviting enough for potential customers to want to sign up, but now we needed to get them to actually sign up, do something, and experience value.

The Problem: Broken Funnel... and No Engagement

Much like Twitter, FitCounter’s previous sign-up flow was only a few steps. The team designed it that way to be as fast and frictionless as possible. The sign-up flow even had a progress bar so that new users knew what steps there were in the process and how much longer they had to go.

Despite the flow being straightforward, simple, and easy to use, the funnel completion rates were rather low overall, as well as being low from one step to the next (see Figure 5.18). Not many new users who started the flow completed the sign-up process. And of those few who did sign up, even fewer ever tried using the product afterward. Why was this happening?

FIGURE 5.18
FitCounter’s problematic on-boarding funnel shows the drop-off from step to step and overall.

The team had been iterating on this flow for quite some time, and they only seemed to improve things by a couple of percentage points each time they tried.

When you map out the previous sign-up funnel as a story, it looks more like what you see in Figure 5.19, which is a cliffhanger.

FIGURE 5.19
The cliffhanger of this funnel is clear when visualizing it as a story. A majority of visitors who started the funnel were signing up, but not continuing after the next step.

Data Tells a Story

Both analytics funnels and stories describe a series of steps that users take over the course of a set period of time. In fact, as many data scientists and product people will tell you, data tells a story, and it’s our job to look at data within a narrative structure to piece together, extrapolate, troubleshoot, and optimize that story.

In the case of FitCounter, our gut-check analysis and further in-person testing with potential users uncovered that the reason our analytics showed a broken funnel with drop-off at key points was because people experienced a story that read something like this:

• Exposition: The potential user is interested in getting fit or training others.

• Inciting Incident: She sees the “start training” button and gets started.

• Rising Action:

• She enters her username and password. (A tiny percentage of people would drop off here, but most completed this step.)

• She’s asked to “follow” some topics, like running and basketball. She’s not really sure what this means or what she gets out of doing this. She wants to train for a marathon, not follow things. (This is where the first drop-off happened.)

• Crisis: This is where the cliffhanger happens. She’s asked to “follow” friends. She has to enter sensitive Gmail or Facebook log-in credentials to do this, which she doesn’t like to do unless she completely trusts the product or service and sees value in following her friends. Why would she follow them in this case? To see how they’re training? She’s not sure she totally understands what she’s getting into, and at this point, has spent so much brain energy on this step that she’s just going to bail on this sign-up flow.

• Climax/Resolution: If she does continue on to the next step, there would be no climax.

• Falling Action: Eh. There is no takeaway or value to having gotten this far.

• End: If she does complete the sign-up flow, she ends up home. She’d be able to search for videos now or browse what’s new and popular. Searching and browsing is a lot of work for someone who can’t even remember why they’re there in the first place. Hmmm…in reality, if she got this far, maybe she would click on something and interact with the product. The data told us that this was unlikely. In the end, she didn’t meet her goal of getting fit, and the business doesn’t meet its goal of engaging a new user.

Why was it so important for FitCounter to get people to complete this flow during their first session? Couldn’t the business employ the marketing team to get new users to come back later with a fancy email or promotion? In this case, marketing tried that. For months. It barely worked.

With FitCounter, as with most products and services, the first session is your best and often only chance to engage new users. Once you grab them the first time and get them to see the value in using your product or service, it’s easier to get them to return in the future. While I anecdotally knew this to be true with consumer-facing products and services, I also saw it in our data.

Those superfans I told you about earlier rarely became superfans without using the product within their first session. In fact, we found a sweet spot: most of our superfans performed at least three actions within their first session. These actions were things like watching or sharing videos, creating playlists, and adding videos to lists. These were high-quality interactions and didn’t include other things you might do on a website or app, such as search, browse, or generally click around.

With all of our quantitative data in hand, we set out to fix our broken usage flow. It all, as you can imagine, started with some (more) data…oh, and a story. Of course.

The Plan

At this point, our goals with this project were two-fold:

• To get new users to complete the sign-up flow.

• To acquire more “high-quality” users who were more likely to return and use the product over time.

As you can see, getting people to pay to upgrade to premium wasn’t in our immediate strategic roadmap or plan. We needed to get this product operational and making sense before we could figure out how to monetize. We did, however, feel confident that our strategy was headed in the right direction because the stories we were designing and planning were ones that we extrapolated from actual paying customers who loved the product. We had also been testing our concept and origin stories and knew that we were on the right track, because when we weren’t, we maneuvered and adapted to get back on track. So what, in this case, did the data tell us that we should do to transform this story of use from a cliffhanger, with drop-off at the crisis moment, to a more complete and successful story?

Getting to “Why”

While our quantitative analytics told us a “what” (that people were dropping off during our sign-up funnel), it couldn’t tell us the “why.” To better answer that question, we used story structure to figure out why people might drop off when they dropped off. Doing so helped us better localize, diagnose, and troubleshoot the problem. Using narrative structure as our guide, we outlined a set of hypotheses that could explain why there was this cliffhanger.

For example, if people dropped off when we asked them to find their friends, did people not want to trust a new service with their login credentials? Or did they not want to add their friends? Was training not social? We thought it was. To figure this out better, once we had a better idea of what our questions were, we talked to existing and potential customers first about our sign-up flow and then about how they trained (for example, alone or with others). We were pretty sure training was social, so we just needed to figure out why this step was a hurdle.

What we found with our sign-up flow was similar to what we expected. Potential users didn’t want to follow friends because of trust, but more so because it broke their mental model of how they could use this product. “Start training” was a strong call to action that resonated with potential users. In contrast, “follow friends,” was not. Even something as seemingly minute as microcopy has to fit a user’s mental model of what the narrative structure is. Furthermore, they didn’t always think of training as social. There were a plethora of factors that played into whether or not they trained alone or with others.

What we found were two distinct behaviors: people tend to train alone half the time and with others half the time. Training alone or with others depended on a series of factors:

• Activity (team versus solitary sport, for example)

• Time (during the week versus weekend, for example)

• Location (gym versus home, for example)

• Goals (planning to run a 5k versus looking to lose pounds, for example).

This was too complex of a math equation for potential users to do when thinking about whether or not they wanted to “follow” people. Frankly, it was more math than anyone should have to do when signing up for something. That said, after our customer interviews, we were convinced of the value of keeping the product social and giving people the opportunity to train with others early on. Yes, the business wanted new users to invite their friends so that the product could acquire new users. And, yes, I could have convinced the business to remove this step in the sign-up process so that we could remove the crisis and more successfully convert new users. However, when people behave in a certain way 50% of the time, you typically want to build a product that helps them continue to behave that way, especially if it can help the business grow its user base.

So instead of removing this troublesome cliffhanger-inducing step in the sign-up flow, we did what any good filmmaker or screenwriter would do: we used that crisis to our advantage and built a story with tension and conflict. A story that we hoped would be more compelling than what we had.

The Story

In order to determine how our new sign-up flow would work, we first mapped it out onto a narrative arc. Our lead designer and engineer wanted to jump straight into screen UI sketches and flow charts and our CEO wanted to see a fully clickable prototype yesterday, but we started the way I always make teams and students start: with a story diagram. As a team, we mapped out a redesigned sign-up flow on a whiteboard as a hypothesis, brick by brick (see Figure 5.20).

FIGURE 5.20
A story map from a similar project with the storyline on top and requirements below.

This was the story, we posited, that a new user and potential customer should have during her first session with our product (see Figure 5.21). As you can see, we tried to keep it much the same as before so that we could localize and troubleshoot what parts were or weren’t working.

• Exposition: She’s interested in getting fit or training others. (Same as before.)

• Inciting Incident: She sees the “start training” button and gets started. (Same as before.)

• Rising Action:

• She enters her username and password. (This step performed surprisingly great, so we kept it.)

• Build a training plan. Instead of “following” topics, she answers a series of questions so that the system can build her a customized training plan. Many questions—ultimately extending the on-boarding flow by 15 screens. 15! There is a method to this madness. Even though there are now many more questions, they get more engaging, and more relevant, question by question, screen by screen. The questions start broad and get more focused as they progress, feeling more and more relevant and personal. Designing the questionnaire for rising action prevents what could be two crises: boredom and lack of value.

• Crisis: One of the last questions she answers is whether or not she wants to use this training plan to train with or help train anyone else. If so, she can add them to the plan right then and there. And if not, no problem—she can skip this step and always add people later.

• Climax/Resolution: She gets a personalized training plan. This is also the point at which we want her to experience the value of her new training plan. She sees a graph of what her progress will look like if she sticks with the training plan she just got.

• Falling Action: Then what? What happens after she gets her plan and sees how she might progress if she uses FitCounter? This story isn’t complete unless she actually starts training. So…

• End: She’s home. Now she can start training. This initially involves watching a video, doing a quick exercise, and logging the results. She gets a taste of what it’s like to be asked to do something, to do it, and to get feedback in the on-boarding flow and now she can do it with her body and not just a click of the mouse. Instead of saying how many sit-ups she can do by answering a questionnaire, she watches a short video that shows her how to best do sit-ups, she does the exercise, and she logs her results. While humanly impossible to fully meet her goal of getting fit in one session, completing the story with this ending gets her that much closer to feeling like she will eventually meet her goal. Our hope was that this ending would function as a teaser for her next story with the product, when she continued to train. We wanted this story to be part of a string of stories, also known as a serial story, which continued and got better over time.

FIGURE 5.21
The story of what we wanted new users to experience in their first session with FitCounter.

Once we plotted out this usage story, we ran a series of planning sessions to brainstorm and prioritize requirements, as well as plan a strategic roadmap and project plan. After we had our requirements fleshed out, we then sketched out screens, comics, storyboards, and even role-played the flow internally and in person with potential customers. We did those activities to ideate, prototype, and test everything every step of the way so that we could minimize our risk and know if and when we were on the right path.

We were quite proud of our newly crafted narrative sign-up flow. But before we could celebrate, we had to see how it performed.

The Results

On this project and every project since, we tested everything. We tested our concept story, origin story, and everything that came after and in between. While we were very confident about all of the work we did before we conceived of our new usage story for the sign-up flow, we still tested that. Constantly. We knew that we were on the right path during design and in-person testing because at the right point in the flow, we started getting reactions that sounded something like: “Oh, cool. I see how this could be useful.”

Once we heard that from the third, fourth, and then fifth person during our in-person tests, we started to feel like we had an MVP that we were not only learning from, but also learning good things from. During our concept-testing phase, it seemed like we had a product that people might want to use. Our origin story phase and subsequent testing told us that the data supported that story. And now, with a usage story, we actually had a product that people not only could use, but wanted to use. Lots.

As planned, that reaction came during our in-person tests, unprompted, near the end of the flow, right after people received their training plan. What we didn’t expect was that once people got the plan and went to their new home screen, they started to tap and click around. A lot. And they kept commenting on how they were surprised to learn something new. And they would not only watch videos, but then do things with them, like share them or add and remove them from plans.

But this was all in person. What about when we launched the new sign-up flow and accompanying product. This new thing that existed behind the front door. The redesign we all dreaded to do, but that had to be done.

I wish I could say that something went wrong. This would be a great time to insert a crisis moment into this story to keep you on the edge of your seat.

But the relaunch was a success.

The story resonated not just with our in-person testers, but also with a broader audience. So much so that the new sign-up flow now had almost double the completion rate of new users. This was amazing, and it was a number that we could and would improve on with further iterations down the line. Plus, we almost doubled our rate of new user engagement. We hoped that by creating a sign-up flow that functioned like a story, the result would be more engagement among new users, and it worked. We not only had a product that helped users meet their goals, but it also helped the business meet its goals of engaging new users. What we didn’t expect to happen so soon was the side effect of this increased, high-quality engagement: these new users were more likely to pay to use the product. Ten times more likely.

We were ecstatic with the results. For now.

A business cannot survive on first-time use and engagement alone. While we were proud of the product we built and the results it was getting, this was just one usage story: the first-time usage story. What about the rest? What might be the next inciting incident to kick off a new story? What would be the next beginning, middle, and end? Then what? What if someone did not return? Cliffhangers can happen during a flow that lasts a few minutes or over a period of days, months, or years. Over time, we developed stories big and small, one-offs and serials, improving the story for both customers and the business. Since we started building story-first, FitCounter has tripled in size and tripled its valuation. It is now a profitable business and recently closed yet another successful round of financing so that it can continue this growth.