Hasso-Plattner-Institut
Hasso-Plattner-Institut
  
 

18.07.2018

Stories as Entry Points into the World of Design

Holger Rhinow, Program Manager HPI Academy

Holger Rhinow Programm-Manager bei der HPI Academy

In this two-part series I want to share a few methodological observations on successful storytelling from projects that I have been part of in recent years. The observations are not part of my innovation research but rather anecdotal. My interest in writing about this is to exchange ideas with likeminded coaches, researchers, and product managers. Part 1 is about the nature of storytelling in innovation projects. I mention examples on how teams elaborate data into stories and what it matters to do so.

 

Storytelling in the Arts_HPI Academy

Why do we care about storytelling?

Storytelling is considered to be an integral part in user-centered innovation processes. However -as I see it- especially inexperienced teams have a hard time going through their user research data in elaborating meaning from it. As it oftentimes happens, teams tediously unpack a vast amount of data points from observations and interviews but do not link data into stories. Storytelling understood as a methdological approach is supposed to elaborate data into stories that inspire us. So why do so many teams collect such a huge amount of and fail to elaborate on it further once it has been unpacked?

 

From my experience, many of the teams we support are triggered to be on the look out for data that are somehow representative of bigger trends in society or in markets (e.g. product managers may focus their efforts on features that are demanded by the largest overlaps of user groups). However, to elaborate an innovative idea into a new offering, it would be difficult to find statistical evidence for future success, before we actually build and test an offering. What we first need is not representation but inspiration in order to navigate through the so-called fuzzy front end of innovation. We strongly believe that we can become inspired by only one or a few people to design something unexpected and novel. That design may then be adopted by many other people we do not even get to know before. Based on our belief, we would not never solely rely on statistical market research in innovation projects. Rather we look for complementary qualitative user data to inspire us. This kind of data may not be representative but they often turn out to be deep: meaning they do not only tell us something about people and their preferences but also about their rationales or their personal needs in a given situation. In its best moments, qualitative user research opens up a window into a person’s life. That is why we always aim to help teams be part of the user research. They should have the experience of being closer to other peoples’ lives instead of just digesting paraphrased observations from other user researchers. 

Inspiration is everything when it comes to user research for innovation.

Now, back to teams that first encounter people they want to design for: As soon as those teams go into the field, they are usually blown away by other peoples’ daily challenges and their ways of dealing with these challenges. They get to know people that vary in their needs and behaviors, yet they can build up empathy for their individual situation to some extent. Being in the shoes of someone else for a certain time makes a lasting impact on individual team members. However, once these team members leave the field and return to their offices, they seem to have a hard time externalizing their excitement about observations they have made. Rather, they tend to fall back into the working mode they are used to. For some reason I do not fully comprehend yet, these team members tend to paraphrase their findings into rather uninspiring facts and stats that appear more objective. For instance, especially rookie teams love to unpack statistical findings that they picked up in passing, e.g. age and income of an interviewee, stated expenses for certain goods and the willingness to buy some product for a certain price in the future. Now, these kind of data may become relevant at some point in the process of designing a new design. The problem is that they hardly inspire a team that is still trying to explore their own opportunities in an early stage.

What we actually look for is data that is not representative for others but is representing a person’s situation, his or her ambitions in life in general and in interesting situations in particular. We look for stories in this data, and we cannot expect teams to naturally think in terms of stories because it seems too far off from everything else they would do in their daily jobs.

 

Ingredients of storytelling

In some ways, it is remarkable that stories do not seem to be an integral part of the what most teams would do in organizations. From a historic perspective, stories seem to be a fundamental aspect of all humans’ civilization. For more context, I recommend the podcast episode about storytelling with Christian Riedel and agile expert Markus Andrezak, in German.

 

Stories are a broad cultural phenomenon that has changed over time and regions. Its complexities and purposes are wide-ranging, however we can always find similar ingredients in different stories. 

Almost all stories offer us a glimpse into the life of a hero that is confronted with a new situation, from ancient Greek larger-than-life-epics to modern tv shows such as Breaking Bad. The situation appears to be a challenge that will change the life of that person, if not an entire society. The story unfolds as the hero -the main actor- decides to take action and overcome the challenge, usually by surpassing herself. The hero would never completely act self-sufficient, but would take advantage of someone or something else’s help, e.g. an object that offers a great value in that given situation. All stories come along with people or objects that would empower the hero to take action; no hero would be completely helpless but would find some way of dealing with the situation, no matter how desperate the attempt would appear to be in the beginning. As the story reaches its dramaturgical peak, the person will experience the consequence of her actions in the end. She may succeed and overcome the challenge or she may fail and the story turns out to be what Aristoteles defined as a tragedy. 

In a nutshell some of the recurring ingredients in stories are

  • a person at the center, a hero or main character,
  • a situation that calls for action,
  • a goal or a need that the main character embodies in that situation,
  • an action or a series of actions by the hero,
  • and people and objects that empower the hero to take action.

 

From complex narratives to user stories

Stories such as the odyssey or Walter White’s struggle for becoming a drug dealer to support his family are complex narratives with many interwoven plot twists. These kind of stories for entertainment and moral messages may span over years, if not lifetimes. However, if we look at the small stories from people we meet in our user research we can see that they contain the very same ingredients I mentioned above.

 

So-called user stories are stories of people we observed, we interviewed or we became as part of our user research. They link related data into a meaningful, chronological order and offer a glimpse into a person’s life that becomes -through storytelling- the main character in this story. Storytelling is the art of selecting and elaborating data from a stream of interrelated events into a subjective and personal story. Stories thereby never represent objective complexity -how could they?- but cut off complexity and offer a straightforward narrative. These stories can inspire us, but they do not necessarily represent other people’s lifes and systems. 

A very common framework to elaborate data into a user story can be found in agile software development projects these days. Product teams would write down small stories as formal sentences that could be arranged chronologically to each other and would assemble into larger user stories -so called epics. A formal sentence structure looks like this:

As a {role} I want to {action/goal} so that {reason/benefit}.

The framework enforces a designer or user research to write about someone’s challenge from a subjective perspective. A designer would specify that person’s role (e.g. a programmer, a student, an elderly passenger) that person’s goal (e.g. buying a ticket for a bus), and that person’s benefit (getting around by bus). You can see that the challenge, the situation, and objects are not implicitly stated in this user story, however teams consider these aspects when arranging those user stories in chronological order. In total, these smaller user stories are later positioned across a user story map that would indicate in which situation a person’s story takes place.

Not everyone is happy with the formal structure of these user stories. Alan Klement argues for the idea of replacing user stories with so-called job stories, in which we focus on person’s situation rather than its role. Also, job stories are describing actual behaviours instead of intrinsic goals that people may have but that we also can only assume sometimes. Klement’s version of a story looks like this:

When {situation} I want to {motivation} so that {expected outcome}.

I worked with both ways of elaborating stories successfully, however job stories seem to have a few advantages for inexperienced teams. As mentioned above, rookie teams have a hard time to be precise about when stories take place. Enforcing them to describe a situation in each job story reminds them constantly to think in these terms. Also, the idea of asking for some person’s motivation is a clever move. A person may describe how they do things here. However, by asking for a motivation, a designer or a researcher would receive answers about what a person actually would like to do but haven’t figured out how to do yet. Thereby, job stories can indicate whether a person has already applied certain solutions that work for her or whether a challenge leaves her helpless to some extent. By knowing how empowered a person really is, our teams could figure out whether a situation actually needs a new design or a re-design.

 

An example of a user story in our projects

Two years ago we supported a project team that conducted a series of interviews about the perceived safety of different kind of people. In one of the interviews, a young woman told our team that whenever she rides her bike at night through a nearby forest, she calls her boyfriend and keeps the connection, until she arrives at home safely.

 

Think of the image that this small story created in the minds of our team: A young woman riding a bike through a forest at night on her way home. While she is on that ride, she calls her boyfriend. He gets the call, they say hello and from that point on she occasionally mumbles a few words into her cell phone as she continues her ride. The two don’t discuss anything important but keep the connection until she arrives home.

It is a small story about a very specific situation in which a person felt challenged personally and decided to bring a special person into her situation to make herself feel better. Even though, her boyfriend is not physically at her side, her situation seems to change. It was a simple statement in a long interview, yet it made an impact on the team. Since the quote is so short it might not be obvious that it already contains a complete story, but in fact it does. The quote refers to:

  • an person in the center of the story (the young woman),
  • a situation (being on the ride at night through a forest, by herself),
  • an action (calling her boyfriend while riding),
  • and a design that allows her to act this way and deal with her situation (a cellphone, a boyfriend who is available stay on the phone with her).

Most stories we capture in our projects are built around these ingredients. In fact, stories actually need all of these ingredients (except the notion of an existing design) to fully capture a situation in a designer’s mind. I began to call these stories Minimum Viable Stories (of course following the notion of Minimun Viable Products). Once teams comprehend that stories need to create images in their minds in order to inspire, they usually improve their user research efforts in following iterations. Sometimes we are even able to dig deeper and explore why the person acts the way she does. At this point we are exploring a person in terms of her rationales and emotions. Inexperienced teams oftentimes do not uncover these aspects of a story and therefore have to later assume what a person’s rationale or need may have been, to complete the story into an MVS. This is precisely why we work with frameworks. Frameworks enforce team-based discussions about aspects that have been important in previous projects. Not more, not less.

Let’s figure out how we could elaborate that woman’s situation into a user story and a job story. 

A user story could look like this:

As {a young woman} I want to {call my boyfriend} so that {I feel comfortable and safe during my ride home}.

A job story on the other hand could look like this:

When I {am alone, riding my bike home}, I want {stay in contact with my boyfriend} so that {he know where and how I am, so that I feel comfortable and safe during my ride home}

Both stories indicate the same interpretation. There is a person and her goal is to feel more comfortable on her ride. She wanted to avoid the feeling of being potentially exposed to an unknown threat. Job stories focus more explicit on her situation and neglect the importance of her being a young woman. A job story indicates that the challenge is mainly determined by her sitatution. Other people in that very same situation would likely feel similar. 

The cyclist’s story stood out in that interview as it created a shared image of her situation. Team members could vividly picture her situation afterwards and maybe even had empathy for her to some extent. That is why in our projects, we aim for concrete and personal stories.

As human beings we are fascinated by stories that spark our imagination and we have a hard time creating that same imagination out of merely statistical data like ‘3 out of 5 women are afraid to go home at night by themselves.’ As useful as statistics can be, they are hardly personal, hardly concrete enough to inspire us in the design process. Especially inexperienced teams are well-advised applying multiple frameworks to elaborate stories as it helps them to not only find inspiration but also find gaps in their current user research.

 

Stories are our entry points into the world of design

My observation is that teams often do not appreciate stories for their inspirational value. They rather keep data separated to find something quantitatively larger than personal stories. They aim for larger patterns that are not necessarily inspirational but representative. Problem is that most user reserach in innovation research is not equipped to develop grounded theories. As a result, teams end up with pseudo-scientific hypotheses and even theories that are neither inspirational nor representative (e.g. “women need safer ways to commute in a world where technology is ubquiutious”). It is a common problem in many innovation projects with inexperienced teams. As Rittel and Webber argue, it is unlikely that we can deal with social problems of any kind, by defining a theory or a master plan. In fact, our most promising option in managing complex systems is to find concrete entry points that would allow for design interventions. As soon as we design an intervention we can then observe how that system would react to our input. Only after that should we then adjust our actions and see that system continue to adapt and emerge.

 

User stories first aim to change the life of a specific person in a specific situation. Since many people share similar needs and challenges and all people are somewhat connected with one another, these design interventions can ripple into larger groups and segments, potentially changing the way they deal with certain challenges in situations. User stories are our entry points into the lives of people we think we can empower in specific situations, knowing that our actions as designers can be transferred and scaled as soon as we see they have a positive impact. For the most part, we do not need larger theories to be inspired to design new opportunities.

In part 2 of this two-part series I will share what kind what kinds of stories can emerge from storytelling and how these stories can inspire for different design opportunities.

Thank you to my HPI colleagues Sharon Nemeth and Christina Stansell for their remarks on grammar.