When we say that the design must “tell a story,” we are not just talking about games or interactive fiction, or even about turning a work application into an adventure (“Conquer the benefits allocation maze…”). Instead, we mean the kind of stories that help you create new designs. These stories are used to make you think of new possibilities, give you the tools to encourage a self-reflective kind of thinking—design thinking—or so you can imagine designs that will improve the lives of other people. Stories explore ideas from user research.
In Tom Erickson’s view, design is as much about communication as it is about the end result. This includes communication with the eventual users, as well as communication among a collaborative team. The stories are a tool to help designers “grapple with the messy, ill-defined issues” that are part of the design process. They do this by not only creating small scenarios, but also by communicating the emotional overtones, the social and organizational dynamics that are just as much a part of the story as the factual narrative. Used in this way, stories activate the mind by providing rough sketches with openings for discussion.
Imagine that you have been researching attitudes toward new “green technologies” as you work on a product to help people use resources more wisely. You might have heard people talking about how difficult it was to tell how much electricity or water they were really using. And you probably heard attitudes ranging from the altruistic (“We should use fewer resources for the good of the earth.”) to the selfish (“Why should I be the one to scrimp?”). You probably have a few story fragments. But you still need to turn this information into a design. That process might involve sketching ideas for screens as Jeremie Jean and Aaron Marcus did in “The Green Machine: Going Green at Home” (in UPA’s UX Magazine 8.4) when they imagined a smart phone application that would help people visualize their energy use by showing a graph that compared their goal to average use by others. Or you might create a story showing how your design idea would work.
Tom Erickson’s story describes a design solution to the problem of how one might use monitoring of resources to encourage people to moderate their usage habits while at the same time not having a Big Brother scenario where every toilet flush is metered and reported to the utility.
Xiang-Wei left the transit station and turned onto her street with foreboding in her heart. She looked down the street, and her fears were confirmed: Her building’s skin, normally a healthy green, was discolored with purple streaks. How embarrassing–their building was overdrawn on its water allotment.
It wasn’t her fault. That morning, alerted by feedback in their apartment, she and her husband had skipped their showers and made certain that their children used no more than their 10-liter allotments.
But it was difficult to believe that their building-mates were to blame. She’d gotten to know the 24 other families that lived in the co-op over the last two years, and they were all generally responsible. Her husband thought that there was a leak somewhere in the building. That seemed unlikely to her because most appliances monitored their resource usage and sent out requests for assistance when out-of-band consumption events occurred. But her husband said not everything was instrumented–pipes for example–and that there could well be a leak, especially since they’d had a mild earth tremor last week. Old Dr. Lee, who lived just down the hall, spoke darkly of hackers, implying that vague enemies had broken into the resource monitoring system with the aim of embarrassing them. But Dr. Lee was well known to be a bit…odd and, besides, the penalties for hacking into resource control systems were severe.
Xiang-Wei reached her building, and hurried up the walk through the front garden, feeling her cheeks color. Fortunately, she had come home early, and there weren’t many people on the street, but still…
There was just one thing to do: organize a vote of the co-op to ask the resource authorities to turn on fine-grained monitoring. That would enable them to identify any leaks, or to put the finger on the miscreant who was wasting resources.
Not all new design stories have to be as big as a building. Stories can illustrate designs that solve smaller problems as well. No matter how big or small the idea, one type of design story takes a point of pain and transforms it into a successful, happy ending. As an example, here are some short story fragments from users of a payroll program:
- “My co-worker usually does the payroll. When she’s on vacation, we always have to scramble to get everything done right and get the staff paid on time.”
- “It’s not the routine things that are a problem. It’s special stuff like bonuses and advances.”
- “The instructions in our software are fine, but they don’t include little details like which set of checks we should use for payroll. We all dug through our wallets looking for a stub so we could see which number series to use.”
Maybe you used these fragments in a short story to illustrate the problems and frustrations:
- “Mary was filling in on payroll while the office manager, Kathy, was away. On Thursday, just as she was about to run the payroll checks, she remembered Kathy telling her about some special bonus checks due that week. She groaned. Special checks…special anything always seemed to go wrong for her. If she could just remember what Kathy said. She stared at the confusing mass of notes pinned up on the wall behind the accounting computer. None of them said anything about bonuses. She groaned again. Last time she got something wrong, it took weeks to clean up the problems.”
Now you can think about how this story could end differently and write a new story that changes the pain into delight with a new feature for the payroll software.
- “Mary was filling in on payroll while the office manager, Kathy, was away. She didn’t like this part of the job—ever since she’d made a mistake that took weeks to clean up. But Kathy told her not to worry this time and when Mary clicked on “Weekly Payroll” she saw why. All the information she needed was right there on the screen. Instead of the confusing grid of numbers that had caused all the problems last time, she saw step-by-step instructions built into the forms. Best of all, Kathy had obviously written some of the instructions, because they described the procedures in their own office, like the note that told her which way to put the checks in the printer. But the best was the reminder of the special bonuses due this week. Everything was set up, and all she had to do was click.”
A short story like this not only suggests new features, but connects them to the user research and the people who will benefit from them.
Stories evolve through the design process
During the design process, your use of stories will evolve as the design goes through brainstorming (generative), concept (expressive), and specification (prescriptive) stages. As the design progresses, your stories will too, changing format and adding detail.
The number of people working with the stories expands as you move from analysis to design. In the early stages of user research, the user experience team was working most directly with the stories. Now, as you move into the design phase, more people are involved. People who were not involved in the user research (or were only involved in some parts of it) will begin to work with what you have learned and with the stories you have collected and selected.
How your company or project is organized will also make a difference. If you have a strong user experience team, your experience with using stories will be different than if you are the lone voice of user experience on a more traditional technical development team.
Brainstorming for new stories: Generative stories
In a good user experience design process, you will move into the design phase with a collection of stories to work with. But this may not always be the case. You may find yourself in the midst of the design process without having done user research and without the stories you find during that work.
This does not mean that you don’t have any story ideas to draw on. But those stories will come from your own past experiences and assumptions about the product and its users. Your own history and even the language you use to think about the design challenge can be a trap, preventing you from seeing the large quantities of creative fodder around you.
While brainstorming is a technique that’s been around for a long time and is practiced widely, it is not always as productive as you would like. While it is good to collect all the wild and crazy ideas a team might have, what might be more useful is to have a sort of “brainstorming helper,” something that can trigger creative ideas—or at least ideas that are different and new for the team.
If you are starting to work with stories for the first time at the design stage, you can use brainstorming games to generate some new stories.
Even engineering PhDs can play games
Early in my career, I had to travel to a meeting of researchers and research managers for an idea generation session on a particular area of technology. These “ideation sessions∫ were popular because they appeared to generate a lot of ideas off the top of all the participants’ heads on the chosen topic of the day. They were sessions with a lot of talking (though not a lot of listening), and the primary goal as far as I could tell was to generate patentable ideas, with a secondary goal of generating ideas that could become products.
A day or two before I was to leave for the meeting, my manager let me know that I would be leading a part of this meeting, and that our director would be in attendance. I calmly responded to him, ™Sure–ok,∫ as my panic ensued. What was I going to do with a room full of engineering PhDs? I was sure that my boss wanted to test this whole storytelling thing I often talked about. But at that time, I primarily had writing and performance experience, and little experience teaching and leading workshops.
What I did was use a game that I saw a friend use, which she got from Doug Lipman’s bok Storytelling Games. I adapted a game designed for sixth graders to work for research PhDs, and prayed I wouldn’t lose my job. I had them pair up and play a game similar to Mad Libs. The objective was to choose from a list of sentence structures with blanks and fill in those blanks by choosing words from a set of word categories, all related to design and to the technology topic of the day. Once they had filled in a sentence with the appropriate words, the story supporting that sentence should leap out at them. All they had to do was write down that supporting story.
Each researcher pair was given 15 minutes to go off and write their little story and then come back to share their stories with the group.
“You mean you want us to pick words and write stories?” There was a certain level of skepticism in the room. During those 15 minutes while they were writing, I was weighing job options. Surely, I would be busted for making a room full of doctors play a childish game.
When the time was up, I checked with the pairs, and they all requested another five minutes. After that I checked again, and again they asked for more timeºand again once more. At that point, I could feel the warmth of job security flowing back into my life.
When the group finally reassembled, we only had 45 minutes of scheduled meeting time left to share stories. When we were still sitting there two hours later sharing stories and identifying all the interface and technology ideas they had triggered, I knew we had something.
Stories can be tough to just come up with, but they can be triggered easily. Remember, we are storytelling beings. It doesn’t take much to trigger a story. A simple story fragment will do.
Brainstorming helper: The storytelling game
This is a version of Doug Lipman’s game, adapted for user experience brainstorming.
- Choose one of the story sentences;
- Choose a set of items from the People, Places, Activities, and Motivations columns to fill in the blanks in the story sentence. Modify the phrases so that they make grammatical sense for the sentence;
- Once the sentence is completed, write a short story to provide context for that sentence.
A good story sentence will have at least one person, place, motivation, and activity. The simplest story sentence is:
- A (person) in (place) needs help doing (activity) because (motivation).
You can use details that are appropriate for your company to make more complex story sentences. For example, these sentences are for constructing stories about mobile communication and computing.
- While a (person) is in (place), they need to find and meet up with a (person) because (motivation).
- A (person) who is trying to (motivation) at (place) must prepare for (activity), which they will have to do in one hour.
- A (person) at (place) just realized that they lost their keys and wallet while (activity) and needs to rearrange… everything.
The options for these categories should reflect the full range of possibilities—and even some that might seem a bit over the top. When you make your own list for a project, be sure to include some wild examples. If you are working with ideas suggested by your user research, be sure to include some of the less frequent types of users. If you stick to your current categories, you end up with the same old thing. But keep the descriptions short and easy to understand. You want broad categories, not finely drawn differences. The idea here is to free you up to think in new ways.
Table 8.1 has a list of options in each of the categories.
Here are a few of the story sentences filled with words from this list:
- A small business owner in a foreign country is trying to pay household bills to stay sane.
- A spy in an airport needs help feeling secure about her children when she is not at home.
- While a student is at the beach, he needs to find and meet up with a supermodel because he wants to improve his social life.
- A nun at a baseball stadium just realized that she lost her keys and wallet while spending her Saturday chauffeuring kids between activities, and she needs to rearrange… everything.
Your combinations can be fanciful, or you can choose ones that seem to make more sense. Don’t be afraid to get more outlandish because you can explain anything in a story. But don’t pick sentences that just tell the same story you already know. Remember, the point of this exercise is to get creative in how you think about the design challenge.
The story begins with the completed sentence and creates a narrative about how the person completed the activity. To suit the needs of different types of groups and personalities, here are two methods of doing this exercise.
Raw brainstorming. Generate lots of stories for different sentences very quickly. Don’t worry about the details. Just do them rapidly and without judgment. The idea is to generate many stories that might be the germ of a new idea. The method should work particularly well with groups able to loosen up and let their brains throw out ideas without the need to fix each one first.
Pick one sentence and stick with it. Develop the best story for one sentence. This method works well with groups that like to dive deep into ideas. While they may not benefit from a wide variety of ideas, as in the first method, they will take comfort in an idea that is rich by design.
You can even use both methods. Start with the first one to generate a lot of ideas. Then select a few for the more detailed presentation in the second.
Different work styles need different story styles
I was once paired with a young engineer in a technology brainstorming workshop. We were supposed to pick from two lists of unrelated words and use the combination of these words as sparks for generating new ideas. We were given about 30 minutes to run down the long word list and generate as many ideas as possible. Fun for me! “What better way to spend a half hour,” I said.
But my partner needed to work more deliberately, grounding each piece of any idea in a technology already familiar to him. Nothing could go unanswered. Mystery was not allowed. We were not even close to fast or innovative. I kept trying to push us on–he kept wanting to ruminate. At the end of 30 minutes, we had only a few ideas completed while the other groups had 10, 15, even 20. I was frustrated.
When I thought about the experience, I realized that our different approaches gave us the worst of both worlds. If he were more like me, we would have had a lot of ideas, some of them really good. But if I were more like him, we would have had a few, well-developed ideas with deep roots in computer science, mechanical engineering, manufacturing, perhaps even product marketing. We would have fully solved some stuff. Instead, because we each had different approaches, we had a small collection of mish-mash ideas.
No one approach is better. While it’s really good to have a lot of ideas to work with, some people just can’t let go of how they naturally think. You’ll have to judge whom you are working with and adjust appropriately, because much as we might wish to, we can’t always make other people change.
Don’t worry about wasting time. The whole idea of brainstorming is to create a lot of ideas so you have a rich mix of stories to work from. Brave New Workshop, an improvisational comedy group, comes up with 600 ideas to create a show with 25 sketches. In fact, they don’t start refining any of their ideas until they have created all 600 of their one-sentence ideas. Story sentences generated quickly work in the same way, loosening you up by generating a lot of quick sketches. You’ll throw most of them away, but some will spark ideas that can grow.
Here’s an example of how one of the brainstorming story sentences might grow into a larger story and begin to explore the context to expose possible design concepts.
A generative story
Story sentence: A nun at a baseball stadium just realized that she has lost her keys and wallet while spending her Saturday chauffeuring kids between activities, so she needs to rearrange everything.
The story: It had been a hectic morning for Sister Sarah. She had picked up three kids at each of their homes, taken them to the teen empowerment meeting downtown, and then ushered them off to the afternoon Phillies game. When she discovered her wallet and keys were missing, she didn’t know where she could have lost them. In the parking lot? In the stadium? In the car? On the ground? Who knows?
Fortunately, she had kept her 4G mobile in an inside pocket of her habit–the pocket without the hole in it. She was able to use the bank application to lock her savings account against any future activity, knowing she would eventually have to go into the bank personally to have it unlocked.
She was worried about her car keys. If someone found them on the ground and figured out which car they belonged to, she would lose all the children’s art she kept in her trunk.
From previous bad experiences, she had learned to use her mobile phone to save the GPS location of her parking space in the massive stadium parking lot. So when she went to the stadium security office, she was able to tell them exactly where the car was. Very quickly the call came back from the parking lot that her keys had been found a couple of rows away from her car.
This story suggests several possible concepts for new products, ready for further consideration:
- A mobile application for parking lots that records the location of a car on the parking lot grid;
- A mobile banking application that allows users to do an emergency account lock;
- A device attached to a key ring that can reply to a mobile signal with its location.
Hearing this story, an engineer or business development person may respond with these ideas:
- We could trigger the car alarm from the mobile to help find a parked car easier;
- If the mobile could unlock and start her car, she wouldn’t need to carry car keys;
- An RFID tag on the phone could be made to work with ATMs so she could always get money if she lost her wallet.