Introduction

Stories and prototypes play essential roles within a design thinking process. They are the “glue” that binds the process together. Together, they contain both the problem to be solved and a hypothesis about how to solve it.

Stories and prototypes serve as a means of communication between customers and product developers, enabling the mapping of rational and emotional customer needs to concepts and ideas. This chapter contains a description of the roles of stories and prototypes within a design thinking product development process and discussion on how to create and use them. These are illustrated with an example from industry.

7.1 A Design Thinking Product Development Framework

Since the product development processes in every organization differ by things such as number of phases, important milestones, and so on, they must integrate design thinking into their processes in differing ways (Brown, 2008, 2009; Martin, 2009). In this section, a general product development process will be used to describe how stories and prototypes are created and evolve throughout the development cycle.

The product development process diagrammed in Figure 7.1 has been divided up into three general phases of work: Identify User Needs and Find the Value Proposition; Build, Test, Iterate, and Refine; and Validate and Communicate Broadly.

The purpose of the work in the first phase is to create an understanding of user needs and test the first hypotheses of the development team. These early story fragments are usually focused on describing the need. They start out as statements, like: “… every man knows how hard it is to pick out what he's going to wear to a special event with his partner, like a dinner party or concert. It would be great if we could find a way to help with this decision.”

This story fragment already contains testable elements: How many men have this need? What is the context that leads up to this problem? What are the emotional and practical aspects of making this decision? What kinds of practical problems do men who have this problem face? After these questions are answered through user testing, a more complete story, supported with prototypes, should be built to allow potential users to interact with the story.

The second phase, Build, Test, Iterate, and Refine, is used for development of the stories and supporting prototypes. This is done through cycles of testing with users, evaluating feedback from users, and cycles of iteration. The result of this phase of work should be a set of stories and prototypes that can be used to describe the user needs and problems, along with concepts that resolve them.

The final phase, Validate and Communicate Broadly, is used to validate the concepts developed in the first two phases. At this point, the stories and prototypes are refined into use cases, product architectures, and product descriptions. These are validated through focus groups and quantitative user testing. Additionally, they are communicated broadly through the product development organization, by employing personas, scenarios of use, and preliminary product specifications. All of these terms will be defined in the coming sections as they are employed.

7.2 What Is a Story?

Stories are the basis of human communication for abstract concepts. The foundational element of storytelling is the creation of a narrative, upon which a story can be built: establishment of a plot, a point of view from which the story is related, players in the story, settings in which things take place, and so on.

Stories are used to reinforce cultural values and to help us visualize a situation or scenario that is a departure from our personal or cultural experiences. They are also used to teach, reinforce memories, or serve as a means of validating cultural values. They help us visualize future states, inspire creativity, or see things from the perspectives of other people. A good story transforms a collection of facts and experiences into shared concepts and meaning.

In a design thinking product development process, stories allow concepts to be visualized and experienced before they have been designed and developed. Initially, the development team builds the stories and then shares them with the other stakeholders in the product development process. Stakeholders may include end users and potential partners.

The function of stories within the product development process is to create shared definitions of the types of problems to be solved, the contexts in which the problems occur, and the types of solutions that could resolve the problems. Stories allow quick communication within the complete product development team, its intended customers, and its extended stakeholder chain.

The user's or customer's point of view is the basis of the story narrative. Stories told from the viewpoint of the end user of the product are the foundation of business-to-consumer concepts. Business-to-business stories require creation of many variations of a particular story, each from the narrative points of view of the various customers within a value chain.

A good product development story informs its audience about the functional activities and interactions among people, products, and systems. It also reveals the emotional and rational needs of the people in it. Understanding these things allows the audience of the story to feel empathy for the people within it and develop a “feel” for how credible interactions within the described context could work.

Since the purpose of stories used within product development is to quickly communicate an idea and build shared meaning, they should be constructed using some basic principles:

1. They should be short. It should be possible to understand them within a few minutes. Presentation format must be thought through.
2. They should start by introducing a context. Where does the problem occur? Who has the problem? Who is involved in the experience or solution?
3. They should describe the problem, as experienced by a representative person, or sets of people. Composite personas should be built up, using the characteristics of customer types of interest.
4. They should be limited to a time period in which an end-to-end experience of the user problem occurs. How does it start and how is it resolved? Some of the basic story forms are:
   1. Scenarios built around a use case.
   2. A “day in the life” of a user.
   3. Product journeys.
5. They should be supported with sensorial information: sketches, photos, renderings, prototypes, and example products. These should show:
   1. Where the story takes place.
   2. What the people in the story look like.
   3. What potential problem solutions could look like or work like, or how the problem is presently being resolved.

Learning efficiency increases dramatically with the use of photographs, cartoons, sketches, and video, rather than words. The human brain processes semantically complex information more quickly than it does words (Hockley, 2008). Hence, visually rich communication tells a story faster and with more subtlety than does a long text.

Some common formats for telling stories are:

1. Spoken storytelling.
2. Acting them out (in person and with video).
3. Diagramming and storyboarding.
4. Written text.

Story fragments are best worked out through use of spoken storytelling, acting out, and diagramming. Story fragments arise as the team tries to understand the problems that need to be solved. They originate from a wide variety of sources, including user research and marketing knowledge. Fragments are almost always oral in nature, allowing them to be rapidly exchanged and iterated. Often, they are declared in forms like: “… the people we saw use text for almost all communications now, but can't do this well while walking. None of them felt comfortable using speech commands in public either…” This fragment can be instantly acted out, tested in real situations, and rapidly expanded into a full scenario of “texting while walking.” After this scenario has been developed, the story may be used to generate solution hypotheses. These may be included in the story and similarly acted out, tested in real situations, and expanded further through iteration.

As an example of how to rapidly develop a story to help the product development team advance their understanding of a user problem, let's use the previously introduced example of the man trying to select clothing to wear on a concert date. Print format restricts this to using methods c and d from above:

Ed is a 50-year-old engineer living in Berlin. He has been standing in front of his closet for a while, trying to figure out what to wear tonight. In an hour he's going to pick up his girlfriend Elise, the owner of a chain of luxury hotels, to go see La Traviata at the city opera.

Afterward, they'll go for a drink at a popular new bar, then go to dinner at a cool new restaurant, where they'll meet some friends. Ed asks himself nervously: “What to wear so that I'm not over- or underdressed, Elise is pleased, and I'm comfortable?!?”

This story describes one of the scenarios where an example target customer is experiencing a problem that he doesn't feel confident to resolve alone. The story is five sentences long and is supported by photographs, as shown in Figure 7.2, illustrating the key elements in the story. One of these photos was created by a team member acting out the situation, others were assembled from stocks of images. The characters are described in very thin detail, but enough so that the reader can visualize them.

This story can already be tested for resonance with customers and used as the basis of a brainstorming session for potential solutions. It takes only moments to understand the situation, the characters, the contexts, and the problems, but it is not written at such a high resolution that it appears definite. It serves the functions of communicating the problem, starting discussions, and brainstorming solutions.

“Ed” and “Elise” are personas—composite characters created to represent important types of customers. They have functional, emotional, and personal characteristics shared by people of selected typologies. Personas bring focus to a story, forcing you to tell it through the actions and views of people relevant to your business (Mulder & Yaar, 2007). Besides the functionally focused criteria of the “job” (Christensen, Anthony, Berstell, & Nitterhouse, 2007) that the customer types are trying to accomplish, personas should be used to convey nonfunctional attributes of customer needs: What makes something desirable for this customer type? What are they trying to achieve on emotional and functional levels that presently can't be done?

Creating personas at the beginning of the product development process enables the team to pick the right types of users for the testing and refinement steps, and allows the team to frame the questions to be answered through prototyping, user testing, technical explorations, and business evaluations.

7.3 What Is a Prototype?

In a design thinking process, prototypes are created to answer a set of questions, test assumptions, and demonstrate how something works, or could work. A prototype could be as complicated as the first fully operational build of a new submarine design, or as simple as a first model for an idea for a hair dryer grip, made from a soda can and modeling clay.

The level of resolution and complexity of prototypes developed at the start of a product development process should be much lower in resolution, finish, and function, than those in prototypes used for testing and validation before production start (Benyon, Turner, & Turner, 2005). Whatever types of prototypes are used, their purpose is to communicate and allow interaction with an experience, without the major investment of creating a real, fully functioning version. Simulation has the added benefit that iterations can be made very quickly and easily.

The term prototype connotes something of substance to most people, but prototypes do not need to be physical objects—simulation is a powerful prototyping tool. This can include video showing how an as-of-yet undesigned product and service could work, or a digital animation demonstrating how a software interface could look and function. Prototypes can also be created using one of the many new, easy-to program microcomputers, such as a Raspberry Pi or an Arduino.

A key principle in design thinking is to learn as much as you can as early as you can in a design and development process. The maxim “Fail early to succeed sooner,” often attributed to David Kelly of Stanford University and IDEO, summarizes this thinking. This maxim paraphrases a much-older, similar saying by Helmut von Moltke, the famous military strategist, who observed “No battle plan survives contact with the enemy.” In other words, it doesn't matter how well the team plans, or how much experience they have, or how smart they are, all concepts contain some inherent, unknown flaws in their assumptions and execution, so it's best to find out what they are as quickly as possible and correct them. In addition to imparting the benefit of creating more desirable products, this leads to lower development costs and faster product development cycles.

Figures 7.3 and 7.4 show examples of quick prototypes built to test early ideas about a system for use by the driver of large construction equipment. Figure 7.3 shows a simple, quick-to-build, electronics breadboard prototype. This prototype features a bounceless switch, using a momentary-on pushbutton. The switch toggles between on and off states, when the button is pushed. Rather than hooking the switch up to the entire system for which it is intended to be used, an LED shows whether the switch is on or off.

Figure 7.4 shows a prototype that can be used to test placement and modulation of the switch with a potential user in the actual control area. With this type of prototype, it is possible to quickly gain a wide variety of initial user feedback, including whether the entire physical control architecture is valid, or whether another type of control modality, such as a switch on a panel, would present better solution architectures.

It would be possible to connect the prototype in Figure 7.4 up to the breadboard circuit shown in Figure 7.3, but doing so would hinder the purpose of the prototypes as a tool for co-development with users. The Figure 7.4 prototype is deliberately constructed to allow other stakeholders, including selected potential customers, to interact with it and modify its form. They can cut into it, tape things onto it, position it in various places within the control cockpit, and so on, without risking damage to any of its other functions. After stakeholders have modified the prototype, a next set of prototypes might combine the breadboard electronics into some of the forms and volumes developed using this prototype.

Table 7.1 summarizes the purposes, testing locations, audience for the tests, and level of effort required to build each prototype.

Prototypes serve two important purposes in product development: They are tools to learn and to communicate. Prototypes make a concept tangible and allow it to be shared and developed with people who are not engineers or designers.

However, anyone who has ever visited a product development organization and seen old prototypes lying around knows that unless they are produced at a very finished level, prototypes only make sense within a product story, where their purpose is to demonstrate how key parts of that story could happen. Separated from their stories, they become orphans: useless objects, the purposes of which usually can be recognized only by the people who created them.

7.4 Putting It Together—Combining Stories and Prototypes

As already described, the first phase of the process shown in Figure 7.1 begins with the construction of story fragments and scenarios, created to describe the user within a specific context. These first scenarios have the primary purposes of the describing the user, the context, and the problem. They may also include first hypotheses about how the user could solve the problems outlined in the story.

In the middle of the first phase, ideation usually begins. The team forms hypotheses about how users' needs and problems could be resolved by asking “What if” questions. Using the previously introduced example of Ed and his difficulties in finding something to wear, it is reasonable to ask “How can we recommend something for him if we don't know what he has in his closet?”

An ideation session could then begin, with the purpose of finding ways to determine and maintain an inventory of Ed's closet. Using the properties of his persona (he's a software engineer), it seems reasonable to assume that he is open to a solution based on technology.

Proposed solution spaces should include all problem areas, but might include a scanner app on his smartphone (But would he remember to use it when he's bought something new? Or when he's decided to remove something from his closet? What about the things he already owns?), or a scanner in his closet (Where would it be located? How would it be powered?), or maybe it's a service (Someone takes an initial inventory and is notified of every new clothing purchase?).

All of these solutions can be incorporated into the first scenario and tested for resonance with customers. Evaluation of customer feedback should narrow the range of potential solutions and also pose more questions. Are any of the proposed solution spaces perceived to be better than the status quo by customers? What combination of solutions will create value for them?

This initial testing ends when the team has identified a needs set and problem that customers believe would be valuable to solve. When this happens, it is time to enter the second phase of work.

During the Build, Test, Iterate, and Refine phase, user needs, story fragments, hypotheses, and early prototypes from the first phase are transformed into a complete product story (Davidow, 1986). A complete product story describes an end-to-end customer experience: how the customer is attracted to the product, what the first moment of “meeting” the product is like, the transactional experiences with the product, the experiences of setting it up and interacting with it, and the experience of what happens when the product becomes obsolete.

This phase begins with the team completing the product stories for each selected customer type, based on the outcomes of the first phase of work. This exercise enables the development team to frame the questions required as inputs for further ideation activities.

At this point in the process, first concept prototypes usually are created. A principle of design thinking is that you should “build to learn” (Kelley, 2001) That is, you should start without knowing most of the answers, designing the things you build in a way that allows you to test hypotheses or discover how things could work. This is accomplished through the process of building things that frame out a first hypothesis, then through getting feedback on the prototypes as quickly as possible. This allows the solution to emerge from the process of building, as well as from user testing and feedback.

Continuing with the example story of Ed and his closet: Three hypotheses for a solution to the question of how Ed could maintain an inventory of his closet were proposed. In this phase, rapid prototypes of the various types of solutions could be built and tested with potential users in their closets, in order to get feedback on the concept and answers to the questions raised.

The app idea could be tested by using one of the many app prototyping tools to build a quick simulation, showing interactions and screen flows. The scanner idea could be tested by placing a simple foam prototype inside users' closets and asking them to act out the scenario. The service idea could be acted out by users with an app prototype.

In all cases, the prototypes should be simple “architecture”: placeholder representations of an undefined product. All of the prototypes should be deliberately “undesigned.” Colors would be neutral, elements basic, and any service or digital elements should be focused on fundamental interactions. The role of the prototypes should be to allow the team and users to interact with the functions of the elements when acting out the scenario of use. The goals should be to gain feedback on whether the interactions would be credible within the scenario, how they could be improved, and what other types of problems the solutions might create.

Prototype building and evaluation rapidly expose false assumptions and flaws in the story. They also allow better feedback, involving cognition from the haptic and visual portions of the brain (Latour, 1986).

After the first set of stories and prototypes has gone through a cycle of testing and feedback from stakeholders and users, their feedback is evaluated: What did we learn? What additional problems did we discover? What can be combined to build a more complete product story or prototypes that are more refined? What types of prototypes need to be created to better illustrate how certain parts of the experience could work? How does the story fit with the company strategy and business model? Basically, what worked, what didn't work, and what needs to be changed or improved?

Following the evaluation step, there is generally another ideation cycle. These iterative ideation cycles must be carefully planned since they usually overlap with one another. In the first rounds of this phase, it is normal to learn things that invalidate early assumptions. This means that the learnings from the previous ideation, build, and test steps need to be prioritized: it is a waste of resources to iterate details of a part of a story or prototype, if something about the value of the overall concept has been called into question.

Returning to the example about Ed, the team may have included the scanner idea into the story, then used a packing tape dispenser as a rapid prototype. This would enable test subjects to act out the scenario in some detail. They would need to place the “scanner” somewhere in the home, where the user could locate it when it was needed. They would also need to determine how users would actually use the scanner. Would they take items out of the closet, scan them, and then hang them back up, if they weren't determined to be suitable? They would also have to determine how the scanner would be powered and connected to data. This could be prototyped with cardboard boxes and extension cords.

The team may find that the scanner is easy to hold and that the connection problems are minor, but they may also discover that the scanning process and getting feedback is considered onerous to the user. In this case, there wouldn't be any point in developing the details of the scanner until questions about the overall interactions were answered. In the end, the team may go with one of the other ideas, in order to provide better interaction and feedback.

The team goes through many cycles of the Ideate, Build, Test, Evaluate, and Refine stage (Figure 7.1), until a complete product story emerges. This story should describe a complete experience for the target users, meeting their functional and emotional needs. The complete story is communicated through a variety of types of assets, including storyboards, videos, simulations, or a written text. Communication is supported with sets of refined prototypes. These should demonstrate how the product works, how customers interact with it, how it might look and feel, and how it could be built.

At this stage, the resolution of the prototypes that support the stories will vary by organization and product development process. In many organizations, there are separate “looks-like” and “works-like” prototypes at the end of this stage. The work of the next stage is to integrate these aspects.

After building a complete product story, it must be validated and communicated before it can be transformed into an implementable product definition. During this final phase of work, the product story and prototypes are communicated to a wider variety of stakeholders than in the previous phases. In this phase, quantitative user testing, partner presentations, presentations to government and regulatory agencies, and so on take place. These are used to validate the utility, desirability, and viability of the concept.

Different types of communication materials are prepared for each type of audience. The point of view of the product story needs to change, depending on the interests and needs of each type of stakeholder in the value chain. For example, a distributor will want to hear about the user story so that they can understand the business appeal, but they will also be very interested in the operational aspects of a new product. Government officials and agencies will be less interested in the customer appeal of a product, but they will want to understand how the product is used and where it sits within a broader social and legal framework.

Generally, the design of the product is frozen during this last phase of work. This means that its appearance and the technology that enables it are fixed, so that it can be designed for production and deployment. At this point, the main points of the business model making it viable have been framed out and approved by internal and external stakeholders.

7.5 Employing Stories and Prototypes in Your Process

There are a few key points to remember when creating and developing stories during product development work:

1. Communicate as efficiently as possible. Involve as many senses as possible. Don't use words when you can use a picture or sketch. Act things out and make quick videos. Support pictures and videos with prototypes.
2. Keep in mind where you are in the product development process. Develop a basic understanding of the problem first, follow up with hypotheses of solutions, then actual solutions. Keep developing your stories to reflect current states of knowledge and hypotheses.
3. Don't build a prototype until you know what you want to learn from it. How will it be used? What do you plan to learn from building it?
4. Don't try to learn everything with one prototype. Build many rapid prototypes to test subcomponents of concepts. Wait to combine functions until after they have been tested and iterated separately. Appearance and function should not be combined until late in a product development process.
5. Build scenarios to explore use cases, rather than trying to boil all the use cases down into one big story. People and organizations rarely use one product or service to solve all of their problems.

Some common pitfalls into which companies fall, when trying to apply storytelling and prototyping methods:

1. Being too much in love with themselves. Remove yourself, your company, and your products from your stories. Describe products and services in generic terms. Be confident enough to call all of your present value propositions, business models, and understandings of customer behavior into question.
2. Relying too much on present successes and understandings of past customer behavior. Don't worry about “cannibalizing” your existing business. If you don't reinvent it, someone else will. Customer behavior is not static. Brand loyalty must continually be re-earned.
3. Trying to do too much in one story. Focus on a use case and succinctly depict how it works.
4. Hanging on to unsupported concepts and use cases. If some part of the story or a function of a prototype did not resonate with customers, it requires change, even if it was one of your most clever ideas, or was politically popular.
5. Trying to polish things too early. In phase one and in the early cycles of iteration of phase two, it should be possible to iterate stories and prototypes many times a day. Avoid data- or production-heavy methods of storytelling and prototyping. If the stories and prototypes must be sent out to a contractor for iteration, either the wrong tools are in use or the working level of resolution is too fine.

Build a plan to learn:

1. Don't overthink the first story fragments and prototypes. Plan to develop them through rounds of customer and stakeholder feedback.
2. Use parallel paths. Test several possible scenarios for the same problem. Combine the parts that work; drop the parts that don't.
3. List out the complete value chain and test your stories and prototypes with all stakeholders in it. Learn what is important to them.
4. As stories and prototypes gain polish, shape the stories to reflect the point of view of the stakeholders being interviewed. Make the stories relevant to them and elicit their feedback.

7.6 Conclusion

Prototyping and stories are inextricably intertwined with one another—a prototype can communicate an experience in a way that words never could. Also, a good story is needed to make the relevance of any prototype evident to anyone. This is especially the case for new-to-the-world products or services that meet needs in new ways. Stories and prototypes enable communication of a future vision in ways that allow customers to also visualize and interact with it.

Using stories and prototypes to communicate with stakeholders and users helps product development teams build a narrative about ideas and their usefulness. These tools give expression to customer needs, how people behave, and how they could interact with a new product. Stories facilitate the formation of hypotheses about viable solutions and help frame problem questions. These are all necessary to get any kind of useful output from a creative activity.

Any organization looking to incorporate design thinking into their product development processes must pay careful attention to how they integrate stories and prototypes into their processes. Overly complex and expensive prototypes cannot fill in the shortcomings of a poorly articulated or inadequate story. Better products can be built more quickly, by focusing on better stories, supported by prototypes of the appropriate resolution.

References

1. Benyon, D., Turner, P., & Turner, S. (2005). Designing interactive systems: People, activities, contexts, technologies (pp. 253–260). Essex, England: Pearson Education Limited
2. Brown, T. (2008). Design thinking. Harvard Business Review, 86(6), 84–92.
3. Brown, T. (2009). Change by design. New York, NY: HarperCollins.
4. Christensen, C. M., Anthony, S. D., Berstell, G., & Nitterhouse, D. (2007). Finding the right job for your product. MIT Sloan Management Review, 48(3), 38–47.
5. Davidow, W. H. (1986). Marketing high technology. New York, NY: Free Press.
6. Hockley, W. W. (2008). The picture superiority effect in associative recognition. Memory and Cognition, 36(7), 1351–1359.
7. Kelley, T. (2001). Prototyping is the shorthand of design. Design Management Journal, 12(3), 36–37.
8. Latour, B. (1986). Visualization and Cognition: Thinking with eyes and hands, Knowledge and Society Studies in the sociology of culture past and present, Jai Press, Greenwich, CT (Vol. 6, pp. 1–40).
9. Martin, R. (2009). The design of business: Why design thinking is the next competitive advantage. Boston, MA: Harvard Business School Publishing.
10. Mulder, S., & Yaar, Z. (2007). The user is always right: A practical guide to creating and using personas for the web (p. 22). Berkeley, CA: New Riders.