by Donna Lichaw
2014: A Google Glass Odyssey
Contrast the stories of something like the iPad with a proof of concept like Google Glass, which is essentially a computer that you wear on your face. I have spent probably 100 hours over the past couple of years trying to figure out if, why, or how a device like Glass and apps built on that platform could be viable. At first, I was convinced that the device was a dud and that consumers would never need it or pay money for it. Actually, this has turned out to be true. Google discontinued the program and is no longer producing or marketing Glass as a consumer device. However, when you look at sci-fi, you see a different story. Wearable technology, like Glass, has a product-market fit. It’s just not a mass-market-fit.
There are three storylines to be exact (see Figure 6.7):
• Someone needs her hands free so that she can do her job (like fight aliens, paramilitary, surgery, or police work—e.g., They Live, Terminator, Iron Man, Star Trek: The Next Generation, RoboCop).
FIGURE 6.7
Clockwise from top, left, characters use wearable technology to: perform a medical procedure (Star Trek: The Next Generation), see concealed alien communication (They Live), navigate (RoboCop), and see (Star Trek: The Next Generation).
• Someone is moving very fast and needs his hands free so that he can use his hands for other things…and do his job (Iron Man, RoboCop).
• Someone has a physical impairment and this technology gives him an ability to see and hear (Star Trek: The Next Generation, RoboCop).
What looking at these storylines uncovers is that a device like Glass is not a mass-market consumer device. It is best suited for work or being human when you have some kind of impairment. Furthermore, this type of technology already exists in these contexts to help people get stuff done and be human. For example, while I sit here writing, I am wearing glasses—the oldest form of wearable face technology out there. And the military, police, soldiers, firefighters, and doctors have been wearing technology on their bodies for years. This takes the form of helmet-mounted displays and lighting mechanisms, body-mounted video cameras, and surgical loupes (see Figure 6.8). When you’ve got a job to do and need your hands free to do it, technology can help. And that’s a structurally sound story.
FIGURE 6.8
Clockwise from top, left, people in real life use wearable technology to perform a medical procedure (surgical loupes), see at night (infrared goggles), navigate (helmet-mounted heads-up display or HUD), and hear (hearing aid).
If you’re working on an entirely new product or feature, you don’t have to get stuck imagining storylines from scratch. Learn from what came before you. Hollywood produces some of the most expensive proofs of concepts and prototypes in the world. They’re called props. And each prop is a key player in a structurally sound storyline. See how filmmakers use these products to support the story. Glean meaning from how characters use them to be heroic and save the day.
When you’re finding stories in the real world, whether they are in movies or your customers’ lives, remember to first see and hear your stories; then build them. Think like a storyteller and learn from and borrow from what other creative people—filmmakers and even your customers—out there are doing before you chart your course anew. Or if you must, chart your course anew. You might call this paving the cow path, building empathy, or being creative. I call this storymapping.
CHAPTER 7
Using Your Story
Illustrate Your Story with Strategic Tools
Write Your Story
Act It Out
Elevator Pitch
Putting It All Together
“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.
Diagram
Flow charts and diagrams are visual stories. You can start off a flowcharting 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.
Storyboard
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.1 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 inciting incident and climax should happen on the second and seventh 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 tellin
g 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.
FIGURE 7.1
Panels from a sample storyboard. (Courtesy of See What I Mean by Kevin Cheng)
FIGURE 7.2
Storyboarding in nine panels helps you see the key inciting incident and climax plot points, as well as keep your scope manageable.
Strategic Storymapping
“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 II2
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 agile user 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 afterward with Post-it notes or cards (see Figure 7.3).
FIGURE 7.3
Mapping exercises start with a storyline (left) and can then build into something more complex (right).
Here are some ways that you can use story maps to solve different problems:
• Gap analysis (see Figure 7.4): 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.
FIGURE 7.4
Gap analysis: Using story to visualize the gap between a cliffhanger (left) and a flat story (right) and complete stories that meet user and business goals.
• 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).
FIGURE 7.5
A behavior analysis for multiple user types.
FIGURE 7.6
A behavior analysis for multiple user types organized as a table.
• 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).
FIGURE 7.7
A needs assessment broken down by different categories.
• SWOT (Strengths, Weaknesses, Opportunities, and Threats) 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).
FIGURE 7.8
A visual analysis of strengths, weaknesses, opportunities, and threats analysis. This can be used to assess a concept or a journey. Visually mapping the story in this way helps you see when you are missing things like a high point or a value and perhaps have many threats to consider.
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.
Six-Word 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 Agile 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 reverse engineered stories from real-life conversations with physical trainers so that we understood how the product could work.