The stories you have collected are not blueprints for design, but they can serve as unparalleled inspiration for the design process. They hint at the goals, attitudes, and needs of the people you are designing for. They can also lead to the story the design must tell.
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.
Purple Buildings
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.
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.
It’s not the routine things that are a problem. It’s special stuff like bonuses and advances.
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.
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.
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.
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.
Table 8-1. 
http://www.flickr.com/photos/rosenfeldmedia/4459211933/
PEOPLE, PLACES, ACTIVITIES, MOTIVATIONS | |||
|---|---|---|---|
People | |||
clergy | reporter/journalist | truck driver | farmer |
fisherman | parent | national leader | professional athlete |
real estate agent | nun | grandmother | supermodel |
student | small business owner | sports coach | wheelchair user |
teacher/professor | doctor/nurse | flight attendant | consultant |
waiter/waitress | spy | researcher/scientist | lawyer |
police officer | pre-literate child | pilot | building contractor |
Places | |||
home office | a classroom | an elevator | an airplane |
office building | the kitchen | a hotel room | a foreign country |
driving in a car | a park | a restaurant | a shopping mall |
the street corner | baseball stadium | a cab | an electronics store |
a courtroom | the beach | a public transit bus | an airport |
Activities | |||
planning a meeting | preparing a presentation | finding a lost phone | planning a vacation/trip |
socializing | shopping | thinking | placing a conference call |
taking notes | composing email | saving the world | job hunting |
commuting | moving | studying | day trading |
preventing a crime | coordinating multiple schedules | paying household bills | chauffeuring kids between activities |
Motivations | |||
save money | spend money | stay healthy | influence people |
never lose touch with friends | selectively miss meetings | generate more free time | improve social life |
make mo’ money | keep track of personally relevant news | become witty in conversation | get a lot of work done while sitting on the porch |
spend as little time in the supermarket as possible | feel secure about children when not at home | develop/support a strong fashion sense | research personal illness |
don’t get lost—again | stay sane | ||
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
Remember Sister Sarah from the example of a points-of-pain story in Chapter 1? She couldn’t find her car at a baseball game? Here’s another story with a solution to a similar problem.
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:
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.
If you’ve been following a good user experience process, you will already have stories to work with.
If you haven’t done so already, start by creating stories from any collections of observations or story fragments you have selected. (Take a look at Finding the stories in Chapter 7 for an example.)
As you begin to work on new features, you may remember stories that will help you explore how or when people might use these features, and want to develop them further.
Remember that generative stories do not need to describe a complete design solution. The goal at this stage is to use the story to trigger new ideas as you brainstorm. Start with any of the stories and try to imagine a better solution. Your idea might remove barriers, be faster, easier, or more convenient, or suggest a completely different way of doing something.
Like any brainstorming, the goal is to use the stories to get the creative juices flowing. IDEO, the design consultancy famous for breakthrough products, talks about their “Seven Rules of Brainstorming.” Three of them are particularly appropriate for brainstorming around your stories:
Defer judgment. Don’t dismiss any ideas. Any idea is a good idea, no matter how crazy. Nothing can kill the spirit of a brainstorm quicker than judging ideas before they have a chance to gain legs.
Encourage wild ideas. Embrace the most out-of-the-box notions because they can be the key to solutions. The whole point of brainstorming is coming up with new and creative ideas.
Build on the ideas of others. Sometimes, people say crazy and bizarre things, like “make it on Mars,” but there is some element of truth in it. When you build on the ideas of others, you might bring those crazy ideas back down to earth and make them real innovations.
Like Brave New Workshop, IDEO also suggests that you go for quantity and crank out new ideas quickly. “Aim for as many new ideas as possible. In a good session, up to 100 ideas can be generated in 60 minutes.”
The brainstorming game can also be used to generate ideas from your user research. The process is the same, except that the lists or starter sentences come from what you’ve collected. You can do this in two ways:
Create a list of people, places, activities, and motivations that come from stories you have heard or observed, or from what you know about the context, and use them to generate story sentences.
Table 8-2 is an example of a list with a healthcare context.
Table 8-2.
http://www.flickr.com/photos/rosenfeldmedia/4459351987/PEOPLE, PLACES, ACTIVITIES, AND MOTIVATIONS FOR HEALTHCARE STORIES
People
nurse
medical technician
teacher
registration clerk
medical oncologist
family practice doctor
physical therapist
professional athlete
research nurse
specialist
grandmother
care coordinator
Places
community clinic
hospital
waiting room
home
emergency room
exam room
mountain lake
foreign country
Activities
seeing a patient
waiting for the doctor
identifying treatment options
billing a patient
preparing for a consultation
running tests
reading the current research
planning for home care
Motivations
worried about a symptom
stay at home
stay healthy
choose the best treatment
improve quality of life
get better
make the right diagnosis
save money
Create sentences based on situations you observed or points of pain that you learned about.
Here are a few examples from a healthcare project:
While a nurse is in the patient’s room, she needs to find and meet up with a physical therapist because the patient is having trouble sitting up.
A care coordinator who is just trying to identify treatment options for a difficult case by looking at Web sites with results of clinical trials must prepare for a meeting with the care team to present options, which she will have to do in one hour.
A home-care nurse at a rural hospital just realized that she lost her keys and wallet while visiting patients and needs to rearrange everything!
These examples are less fanciful, but they explore the real problems of real people. Remember, the idea is to get your creative juices flowing.
So far, we’ve discussed using stories as a way to help generate new ideas. But stories also have a role in developing a design, by explaining the rationale behind early sketches.
One thing that happens at this stage is that you switch from describing problems to coming up with ideas that provide a better solution.
Flow Interactive Scenarios Invent a Design
Here’s how Phil Barrett of Flow Interactive describes the process in his blog entry (illustrated in Figure 8-1), “Telling Stories” ( www.thinkflowinteractive.com/2008/12/19/telling-stories/).
Because we’re not fundamentally good at imagining futures or situations different to the one we are in, we have to consciously and explicitly create stories to make sure we do things right. Interaction designers create personas (the characters in the stories), describe the context of use (situation and back story), and identify the personas’ goals.
Then we create scenarios. We try to tell a compelling and realistic story of how our personas will reach a happy ending by using the product. Because we’re all good at listening to stories, the team can spot the good ones, the implausible ones, and the radical amazing-breakthrough ones quite quickly.
There is no single “best way” to construct a good story. Some have methodologies that distinguish between types of stories and define the difference in terms of length, structure, or format.
Ginny Redish suggests that stories that help you develop a concept should be “a very short story of a real user in a real situation.”
Sarah Smith, a 25-year-old travel agent in a small, three-person agency in a storefront in a suburb of Chicago, takes a call from her friend, Jenny.
Jenny wants to go to Phoenix to see her special friend sometime in the next month. She can go any weekend, and she can take Friday and Monday off. But she can only go if she can afford it. Jenny asks Sarah to find her the least expensive flights for any Friday to Monday during the next month.
Her example blends information about users, information about users’ goals and tasks, and information about users’ contexts—their physical, social, and technological environments. The scenario suggests a need for finding the best fares easily. These sorts of features are now part of most travel Web sites, even though they were first discovered in research with travel agents. Ginny created this story from a real observation during user research (but changed the names for confidentiality).
In his approach, research scientist Dan Gruen of IBM describes the difference between stories and scenarios as largely having to do with specificity and motivation. In his model, scenarios are less specific and include little or no character motivation, while stories are more specific and offer more character motivation. When generating new ideas, including character motivation is useful because it grounds the events of the story in human nature and culture. When developing a design, scenarios are useful to focus attention on the tasks to be completed or the technology to be used.
Although flow charts and use cases are used in some of the same ways as stories, these models and structured formats are more focused on developing technical constructs than in explaining human motivations and context of use. If you look at it this way, you can see that stories can be useful alongside other formats that describe interaction, maintaining a focus on user experience throughout the design and development process.
We don’t have a strong opinion about whether you should create specialized definitions for stories, scenarios, or some other story format. But we do have some opinions about what a story useful for design must include. It must include the following information:
Focus on activity, describing actions and behavior, set in a specific context.
Include a description of the motivations that trigger action.
Describe the main characters well enough (or use one of your personas) to set them in context.
What these stories leave out is just as important: extraneous detail, technical details, anything that constrains the design too much. This is not the design. The design is the design. This is a story that describes the users and product in action. We’ll talk more about choosing details for your stories later, but here’s a simple example: If you make it a rainy day in your story, there should be some relevance to the fact that it’s raining. Perhaps it’s hard to use a mobile device with one hand while holding an umbrella in the other. Perhaps the rain changes the main character’s behavior in some way. The rain would add a nice piece of environmental richness to the story, but the story should include actions that make the rain relevant.
As the design is developed, there is still a role for stories. These stories can accompany design specifications, illustrating them and filling in details from earlier scenarios. They can describe alternative user experiences for different types of users and explain complex interactions, such as those that mix several different modes or channels.
One good reason to use stories along with design specification is to keep the real-world context available for reference. As the conversation moves into technical details, it’s easy to forget why a feature was added or how it might be used. Stories help keep the user experience in the picture as the team makes detailed design and technical decisions.
A Standard Built from Stories
In an article in UPA’s UX Magazine, Isobel Frean describes one of the more unusual use of stories in a standard for communication between different healthcare programs, HL7. These programs are primarily used by clinical healthcare professionals, such as doctors and nurses. These users felt that the people working on the technical requirements didn’t understand what their work life was really like. In turn, they found it difficult to relate their daily work to the technical details of a communications standard. Their solution was to use narrative stories and use case diagrams to capture user requirements. This created a common language for the clinicians and IT professionals.
Storyboard: Request Waiting List Status Report
Purpose
This storyboard demonstrates the flow of communications associated with querying the status of a consumer’s positioning on a waiting list maintained by an individual or a regionally managed waiting list.
Precondition
Peter Process, Hospital Discharge Social Worker and Good Health Hospital, has previously sent requests to several nursing homes for a bed for in-patient Mr. Adam Everyman. He has been advised by each of these places that Mr. Everyman has been placed on their waiting lists. As Mr. Everyman is keen to go to one of the nursing homes close to his family, he has his name on the waiting list for Living Legends Aged Services (LLAS) and Senior Living Retirement Villages (SLRS). Peter Process is keen to place Mr. Everyman in the next 24-48 hours and wants to establish the status of the application to determine whether he needs to approach other nursing homes.
Storyboard narrative
As he is authorized to access both the LLAS and SLRS waiting lists, Peter Process requests a status report on where in each waiting list Mr. Everyman is positioned, in order to give him some idea on the likely length of wait. He receives a response from the LLAS Waiting List system advising there are four other persons ahead of Mr. Everyman on the Waiting list.
Peter Process discusses the outcome of the response with Mr. Everyman, and they elect to wait for a vacancy to become available.
—Format for the storyboards written for the HL7 Care Provision ballot (May 2005). © UPA, Reprinted from Frean, Isobel. Capturing User Requirements in Health and Social Care, UPA UX Magazine, Volume 6, Issue 4, 2007
One structure for stories that prescribe is a technical specification story, which is used when preparing to turn over a user experience design for a detailed specification. A tech-spec story is not a complete technical specification, but it lays the groundwork for a design, collecting information from many sources, just as personas collect information about people into a usable format. The structure for a tech-spec story includes several elements.
Presumptions: Statements that illustrate the suppositions on which the story experiences are based.
Experiences: Very short stories that set an image in the reader’s mind in one or two sentences.
References: Links, books, and articles from sources that the audience would respect, as well as references to user research studies. All of these lend credence to the stories. Because many people secretly respect their own work above that of others, this is an opportunity to reference the work of audience members, when possible.
Takeaways: Descriptive images that summarize the key points in a format that the audience can quickly absorb and use, perhaps even in their own presentations.
Connectivity and Intelligence: Mobile Shopping Carts
This tech-spec story is drawn from a project to create a mobile grocery shopping application:
Presumptions
Many people need an easier way to keep track of food purchases and consumption in order to save money and manage family health concerns.
The user is part of the intelligent system. People generally know what they need and how to attend to their family’s needs.
Shoppers like to save money. If a portable device clearly helps them save money, they will buy it, use it, and even pay to use value-added services on it.
Experiences
“I have a free application on my mobile called HandyShopper that lets me create a food shopping list simply by checking off what I need. Every time I shop and get something not on the list, I can add it to the list for next time.”
“My HandyShopper application now accepts bar codes scanned from my mobile’s camera. So I can categorize items as “similar to” or as “substitutions of” other items and do comparative shopping between my two closest grocery stores and Walmart. This saves me money.”
“I downloaded HandyShopper data from the South Beach Diet site and now know when I’m shopping within Phase 2 of the diet or not.”
“I just got a Bluetooth wireless earphone for my mobile.”
“My mobile’s Bluetooth lets me connect my mobile to printers and speakers. A special service sends digital coupons to my phone that I can use at the supermarket.”
“My mobile’s Bluetooth lets my HandyShopper application connect to the supermarket’s smart carts. Now I’m saving time and money because I get all my coupon offers.”
Goal stories
“Other families eat fast food, but the various wheat gluten, dairy, and seafood allergies, not to mention the finicky eaters in our family, mean we have to think about all the food we buy and prepare. Now, whenever I figure out a successful holiday meal or get a new list of bad and good foods from the doctor, I enter the items in my handheld. Shopping is easier because my handheld reminds me what I should buy, lists reasonable substitutions, and remembers my purchases.”
“I’m accustomed to shopping around my family’s dietary restrictions and tracking everything on my cell phone. But now when I shop, I connect my phone to one of the new shopping carts that track each item I put in and take out. So checkout is fast, because the scanning has already been done. All I have to do is bag it.”
References
Internal report on research with shoppers:
Supermarket “smart” cart: www.msnbc.msn.com/id/5462556/
Metro Extra Future Store: www.spychips.com/metro/overview.html
RFID & Shopping: www.jefflindsay.com/rfid4.shtml
Takeaways
Shoppers like to save money and effort. If a device helps shoppers save effort, some will buy it. If a device helps them save money, more will buy it. If a device helps them save money and effort, everyone will buy it.
Another way that stories can be part of design is in the brand story. Like all stories, the brand story lives in the minds of your audience, blended from raw materials into a set of expectations about your product or company. If your design ideas have sprung from the stories you collect in user research, your story should connect naturally to the brand story.
“A brand is a person’s gut feeling about a product, service, or company. It’s a gut feeling because we’re all emotional, intuitive beings, despite our best efforts to be rational.
It’s a person’s gut feeling because in the end, the brand is defined by individuals, not by companies, markets, or the so-called general public. Each person creates his or her own version of it. While companies can’t control this process, they can influence it by communicating the qualities that make this product different than that product. When enough individuals arrive at the same gut feeling, a company can be said to have a brand. In other words, a brand is not what YOU say it is. It’s what THEY say it is.”
—Marty Neumeier, The Brand Gap
If a brand is what others say about your product or company, then a company can supply the raw materials for what people say about them by telling stories—even design stories. This is a marketing strategy that seems more and more popular:
The long-running “Get a Mac” television ads from Apple contrast a cool dude (played by Justin Long) as a Mac against a dowdy, flustered, geeky guy in a suit (John Hodgman) as a PC. Each ad creates a humorous situation in which the Mac outshines the PC.
Scott McCloud (author of Understanding Comics) created a comic book that Google used to introduce its new Chrome browser. The story included sections on features, usability, and even the underlying technology.
In 2001, BMW developed The Hire—a series of short promotional narrative films for the Internet. They hired a different famous movie director for each film and told them they could do anything they wanted, as long as the end product was no longer than about five minutes (though none of them ended up quite that short) and included the same driver character, played by Clive Owen.
Stories like these are a way of communicating the values and features you have put into the design. Of course, stories that are part of the external marketing may be more polished than stories you create during the design process, but they spring from the same source. Both the brand story and the design story are the logical and emotional connection between you and your audience.
“Design as Storytelling,” Tom Erikson www.pliant.org/personal/Tom_Erickson/Storytelling.html
“Notes on Design Practice: Stories and Prototypes as Catalysts for Communication” In Scenario-Based Design: Envisioning Work and Technology in System Development (ed. J. Carroll): www.pliant.org/personal/Tom_Erickson/Stories.html
“Telling Stories,” Phil Barrett, The Think Blog (Flow Interactive) www.thinkflowinteractive.com/2008/12/19/telling-stories/ (December 19, 2008)
“Storytelling: The Power of Scenarios. Goldsmith Award Presentations,” Ginny Redish, IEEE PCS, October 2001 www.redish.net/content/handouts/redish_Goldsmith_Oct2001.pdf
Beyond Scenarios: the Role of Storytelling in SCSW Design, Dan Gruen
Storytelling Games, Doug Lipman
Innovation at the Speed of Laughter: 8 Secrets to World Class Idea Generation, John Sweeney
The Brand Gap—How to Bridge the Distance Between Business Strategy and Design, Marty Neumeier
Stories have many roles in the design and ideation process, as you switch from collecting stories to using them.
Design stories can build from the stories you have collected from users and found in the data, or they can be created as part of a brainstorming exercise.
Even if you don’t have user stories to work from, you can start from what you do know about the user experience to create a context for the stories.
When you have good stories, based on good user data, they can trigger design ideas.
You can make up stories as a way of brainstorming new ideas.
Stories can explain your design ideas, especially if you are suggesting an innovative idea.
Stories can describe requirements, setting a context for technical requirements.