Story and Prototype in design

 Stories and prototypes both act as a glue to bind processes 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.

Design thinking Product development framework

The purpose of the work in the first phase

i) To create an understanding of user needs and

ii) To test the first hypotheses of the development team.

Example: 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.”
The testable elements in the above story is :

I. How many men have this need?

II. What is the context that leads up to this problem?
III. What are the emotional and practical aspects of making this decision?
IV. What kinds of practical problems do men who have this problem face?

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

What is story?

Story is narration of events, cultures, situations.

Importance of story in design thinking

I. To visualize and experience the concept before they have been designed and developed
II. 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.
III. Stories allow quick communication within the complete product development team, its intended
customers, and its extended stakeholder chain.
IV. informs its audience about the functional activities and interactions among people, products, and
systems.
V. It also reveals the emotional and rational needs of the people in it.
Basis of story narrative
The user's or customer's point of view is the basis of the story narrative.
Basic principles of construction of a story
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:
a. Scenarios built around a use case.
b. A “day in the life” of a user.
c. Product journeys.
5. They should be supported with sensorial information: sketches, photos, renderings (actions),
prototypes, and example products. These should show:
a. Where the story takes place.
b. What the people in the story look like.
c. What potential problem solutions could look like or work like, or how the problem is presently
being resolved.

Common formats of story-telling

a. Spoken storytelling.
b. Acting them out (in person and with video).
c. Diagramming and storyboarding.
d. Written text.

Example:

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?!?”
What Is a Prototype?

Prototypes make a concept tangible and allow it to be shared and developed with people who are not
engineers or designers.

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 unsigned 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.

Purpose of creating prototype

Prototypes are created to

I. Answer a set of questions,

II. Test assumptions, and
III. Demonstrate how something works, or could work.

Types of Prototypes: Physical or simulations

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.

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.
Prototypes could be simple or complex
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).