by Donna Lichaw
Case Study: SmallLoans—a Cliffhanger
Innovate: What If?
Borrow: Stories as Proofs of Concept
“Ideas come from everything”
—Alfred Hitchcock
Where do stories come from? Stories are not something that you make up (although there is a place for that, as you’ll see later in this chapter). Stories for products come from data—data that your business already has or data that you seek through qualitative and quantitative research. Mapping stories isn’t a creative endeavor—it’s a strategic business tool and activity tied not just to real data but also to real results, metrics, and KPIs. Mapping stories helps you figure out what is and what can be for your product, your customers, and your business.
But how do you see stories in your data? The short answer is that the stories are already there. They are just waiting for you to uncover and do something with them. In order to learn how to craft a story, you must first learn to see stories. Once you start looking for them, you will begin to see them everywhere. The question you will begin to posit isn’t what’s the story? But, rather: Is this story any good?
For example, think about your competitor’s product that is doing really well. You’ll find on closer examination that concept, origin, and usage stories probably run through it. The relationship you have with your favorite product or brand? Also a story—the story of why you like it, why you continue to use it, and why you recommend it to others. Stories can be found in how your customers use your products (or competitor’s products), how they talk about your product and the problems it helps them solve, and how they experience using your product or engaging with your brand. Looking for stories is the first step you take toward not just finding but building stories into the things (products or whatever) you put out into the world.
Listen
Listening for stories usually takes the form of getting out of the building and talking to your customers or those people you hope will eventually be your customers. Who are they? What is good in their world? What problems do they have? What might call them to action or solve their problems? How do they do things? What makes them tick? After you start talking and listening to your customers, you will start to hear patterns and themes emerge that you can parse together with structure. These are their stories—on the conceptual level and the behavioral level. And they become the storyline of your product.
Your brain already uses story structure to make sense of other people’s words and actions. Now is your chance to get deliberate about it. Map your customers’ stories as you hear them, plot point by plot point. Make sense of their stories. Find the patterns. Find the gaps. See where you can improve their stories. More specifically, see how your product can support their stories.
When doing research, you can parse, make sense of, and map out the stories that you hear on a wall (see Figure 6.1) or on a computer, if your team is remote (see Figure 6.2). Or you can map out your stories on the fly as little squiggles as they emerge during and after you talk to customers (see Figure 6.3). At their most powerful, storylines are strategic tools for uncovering patterns, as well as opportunities.
FIGURE 6.1
If you map out findings from user research on a wall with Post-it notes, you can use plot points to organize your thoughts and insights.
FIGURE 6.2
If your team isn’t co-located, you can use a spreadsheet or online collaboration tool like BoardThing to map out insights from research.
FIGURE 6.3
These storylines visualize insights gathered while doing remote research.
Use the Smile Test
When I map out storylines with teams, I often see one key smiley face scribbled on it, usually in the same place: the climax (see Figure 6.4). It’s what you hope will be the high point of an experience with a feature, flow, or overall product. If you uncover your storylines from existing customers or by mapping out real behavior that real people do, this smile might be something that you observed doing field research, usability testing, or customer interviews. Once you’ve got a working prototype at any level of fidelity, you can test out your story to ensure that your climax is something that really makes your customers smile.
FIGURE 6.4
A storymapping exercise that helped the team imagine and test why people would use the product in the first place. This became the business’s origin story for its core customers.
Smiling at FitCounter
At FitCounter, we designed the on-boarding flow to teach customers how the system worked and give them a taste of the value—something they could use to train in bite-sized chunks, on their own time or with others. Our hope was that if they felt what it was like to use the service, they would interact with it some more during their first session. Our data told us that if customers took five actions in their first session (either watching videos or logging data or a combination of both), they were more likely to convert to a long-term and paying customer. But we didn’t want new users to just do five things; we wanted them also to experience the value of doing those things. We placed little smileys at the climaxes of our story diagrams to remind us during the ideation and development process that we needed to make the customers feel like they had just spent the last five minutes of their lives wisely and gotten something out of it.
We prototyped these stories as quickly as possible in the lowest fidelity we could think of—conversations—and then worked our way up to paper, clickable lo-fi prototypes, and eventually code. Each time we would graduate to a new level of fidelity, we tested our prototype in person with existing customers and people who could be future customers. What we found during each round of testing was that we would see customers grin at the right point, validating our hunch that we were not just solving a problem but also providing value. Sometimes, the smile was accompanied by a statement like, “Oh, that was neat” or “Ah, I get it.”
Before we had redesigned our product, we got comments like “I don’t get it,” or worse yet, long pauses, grimaces, and polite yet insincere “hmm…interesting…” as people played around with the product. Afterward, smiles trumped words—we not only heard we were onto something, but we could see it.
Measure
Stories can be found in qualitative data you gather from your customers as well as the quantitative data that you collect from your business intelligence and analytics tools. Consider funnel analytics that you find in typical software like Google Analytics. When do people drop off? Those are your cliffhangers.
When you see a cliffhanger in your analytics, you see the what: data. Stories tell you the why. Imagine that you are analyzing a checkout flow, and you see that there is a significant drop-off at step 3. Let’s say, step 3 is when your business asks users to enter their payment information. There might be many reasons why users drop off at this point. Maybe they are new users who don’t trust your business enough to enter their credit card details. Maybe they have questions and would rather chat on the phone with a sales representative. Maybe they live in a foreign country or are underage and don’t have access to a credit card. Maybe the checkout flow is confusing, and they thought they submitted their order, when they never actually did. I’ve worked on products that have had all of these scenarios as the why behind why checkout conversion wasn’t as high as the business wanted it to be. Each of the scenarios has a simple fix because each of the scenarios is a simple story. For every cliffhanger and crisis moment, there’s a climax that can resolve that problem.
Someone wants to do something. Something gets in their way. Something can help them overcome this obstacle. They get what they want. The end.
Next time you uncover the what while looking at data and analytics, ask yourself why? Sometimes, you’ll find that you can whip up a quick story map as a hypothesis to answer the why (which you then have to test). Plot point by plot point. What might seem obvious or mysterious is usually not what you think or is completely solvable once you map it out as a story. Often, you won’t be able to answer
the why on your own, and you’ll have to leave the building and talk to a few customers or watch them using your product. What you will uncover will be their story, plot points, cliffhanger, and all. And what you’ll craft as your solution or fix will be a better story—one that has a beginning, middle, and an end.
Case Study: SmallLoans—a Cliffhanger
While you can find stories in your funnel analytics, you can also find them in complex data sets and business intelligence data. Take, for example, a mobile micro-lending start-up that a colleague of mine used to work with. I’ll call it SmallLoans to protect the innocent. SmallLoans provides micro-loans to people in developing countries via a simple mobile Web interface. Because bandwidth is low and technology is old in developing countries, the service needs to function seamlessly, with as few errors and blips as possible. Phone calls to customer service and jumping on a desktop computer to troubleshoot are not options for these customers when something goes wrong. If anything goes wrong during the SMS-based loan application process, it taxes the customer service team, or worse yet, compels potential customers to go elsewhere for their loans.
Early in the life of this start-up, things were going very wrong: it was getting inundated with customer service requests and needed to figure out how to minimize the volume. Potential customers were also slamming customer service with SMS texts, which was taxing the system and the team. It’s difficult enough to have complex text-based conversations with your friends and family—imagine trying to conduct customer service triage in 160 characters or less.
People were signing up for the service because they knew that they could use it to secure a small loan quickly. But after a day, they simply wanted to know the status of their loan. Not knowing is hard—especially if your livelihood depends on it. SmallLoans tried to figure out ways to ping new applicants after they had signed up to pre-empt issues, or ways to train their customer team to handle these requests better with canned responses.
On the more complex side, they started to look at their data to see if they were taking too long to approve loans and how they might fix that. The solution they arrived at was much simpler than all of these solutions, and it tapped into the concept story of the service at its core.
SmallLoans prided itself on a fast turnaround time for loan approval—maybe a few days, maximum. But when the customer service requests multiplied, they looked at their data and saw that their turnaround time for loans was 36 hours.
That was fast. Much faster than the team had thought.
They knew their technology and process were good, but not that good. Think about it—imagine if you knew that you could be approved for a loan within 36 hours. No back-and-forth with application forms. No phone calls to loan officers. No waiting weeks or months.
36 hours.
That’s the high point of a pretty good experience—it’s not just fast, but 36 hours fast—it was their climax.
That climax is part of the story that SmallLoans eventually communicated, not during the process or after an application was submitted, but before someone applied for a loan.
SmallLoans took what was a crisis in their customer’s origin stories—a cliffhanger if they decided to go with a competitor instead—and used that potential conflict to make the exposition of the customer journey that much more compelling. They started to let potential customers know up-front, right before step 1, that the loan process was not just fast but guaranteed to take no more than 36 hours.
With this little change in how they crafted their origin story for new customers, they ended up decreasing customer service complaints and increasing conversion and funnel completion significantly. SmallLoans not only crafted a more structurally sound story for the sake of making things better, but it also saw measurable results.
Sometimes, all you need to do is find the story in your data and communicate and amplify it for your customers.
Innovate: What If?
“The most interesting situations can usually be expressed as a What-if question: What if vampires invaded a small New England village? What if a policeman in a remote Nevada town went berserk and started killing everyone in sight?”
—Stephen King,
On Writing: A Memoir of the Craft
Storylines should be data-driven, but they can also be magical, fantastical, or simply delightful.
When interviewing users, I often ask this question: “What if this product worked like magic?” At first, people are startled. Then they’re confused. “Magic,” they ask? “What do you mean?” Once they get over the mental hurdle of essentially being asked to design the product for me, they eventually have fun with their answers. “It would just know what I want!” they might say. “It would order dinner for me without me having to choose what to eat.” “It would tell me what’s good so I don’t have to seek it out.” “It would tell me what I need to learn and when I need to learn it.”
Imagining What If with FitCounter
With FitCounter, the answer to the “what if” question was something like this: “It would give me a training plan based on my level of fitness, my short- and long-term goals, the time I have to devote to training, and the times of the day and week I prefer to work out.” Most importantly, however, the answer came down to “It will make me work out and stick with it over time.”
When we redesigned FitCounter, apps like RunKeeper allowed you to track your workouts and set goals. Apps like Couch to 5K gave you more detailed plans, but started you at ground zero, even if you could already run a mile without stopping, and forced you to continue onto 5K, even if your goal was just to run two miles. In-person trainers could personalize a plan for you, but they were expensive and required travel. What if we could build a product that asked you a few questions, built a personalized plan for you, and checked in to make sure that you were staying on track. And if training with others helped you stay on track, you could use FitCounter with your friends.
While this seemed like a tall order, this was something that our engineering team could figure out and build by crafting an on-boarding flow that collected key data from people and then built them a training plan based on that data we collected. In fact, this is something that fitness trainers—the human kind—do every day with new clients. They talk to clients, find out what their goals are, how much time they have to devote to training, what types of exercises they do and don’t enjoy, and build a plan accordingly. Then, over time, the trainer works with people to make sure that they stick with the plan.
What if was our question. Mapping the story out gave us our answer. We heard the story from our customers. We saw stories while looking at the competitive landscape. We vetted them internally as we collected team members’ what-if scenarios they had been imagining for years. Then, once we had a story—many stories, we used them. In the next chapter, you’ll see how.
Borrow: Stories as Proofs of Concept
Sometimes, you or your business will invent a new product or feature based on a bout of inspiration. What if, you ask, I could order a taxi at the tap of a phone screen? That’s a story, yup. Often, however, you see that filmmakers and science fiction writers have done all of the creative work for you. In that case, you can see storylines that flow through fictional products that excite you. Then you can map them out to assess their strengths, weaknesses, and product-market fit. Doing so will not only help you build the right product but also build it for the right market.
1989…and 2001: An iPad Odyssey
For example, recently I stayed in London in a different time zone than my family. At the end of a long day working, I returned back to my apartment, bored and lonely. I took my iPad with me so that I could catch up on Star Trek the Next Generation, while my partner, Erica, did the same, five hours after me back in Brooklyn, where we lived. I was watching Star Trek partly for fun, but more so for research. I wanted to see how the characters used wearable technology, like eyewear, in this fictionalized future. I was working on a project about the future of devices like Googl
e Glass, and hoped I would find some answers by doing one of my favorite things: watching TV.
The episode I watched, which originally aired in 1989, centered on a little boy who lost his parents and was alone on the Starfleet Enterprise. In one scene, he missed his mom and pulled out this tablet device that looked an awful lot like an iPad so that he could watch old home movies. This was the only way he had to connect with her—so wherever he was, his mom was with him. At this moment in the scene, I took a photo (see Figure 6.5).
What you see in this photo is me using my iPad to watch a moving picture of a boy using an iPad-like device to watch a moving picture. The use cases were similar, and the stories that flowed through those use cases were solid: someone wants to connect or communicate with someone or something far away. With the iPad (the product), the person can connect (the story).
FIGURE 6.5
A photograph of me using my iPad to watch a character on Star Trek watch a home movie on a touchscreen device that looks uncannily like an iPad.
Tablets like the iPad solve problems and move action forward in storylines both in science fiction and real life. And people who build technology are no strangers to these props and images from science fiction. Steve Jobs even “borrowed” the name of the iPad from the NewsPad featured in 2001: A Space Odyssey (see Figure 6.6). In that story, the characters used this device to communicate with home using newsfeeds and video. It was a pretty powerful device. But more so, the storyline behind using the device as a prop within the film was sound. As any filmmaker will tell you, everything that happens in a film must move the story forward or it gets cut.
FIGURE 6.6
A still from 2001: A Space Odyssey showing someone using a device in much the same way someone would use an iPad today.