Storytelling (Part 2): Different Stories open up different Design Options

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 patterns of succesful storytelling from projects that I accompanied in recent years. The observations are not part of my innovation research and rather anecdotal. My interest for writing about storytelling is in exchange ideas with likeminded coaches, researchers, and product managers. Part 1 explains the nature of storytelling in innovation projects and can be found here. 


This is part 2 in which I describe the continuum of stories we find in innovation projects. As it turns out different stories along the continuum allow for different design actions.


Storytelling in the Arts_HPI Academy

The continuum of user stories

In my last post, I picked the woman’s bike riding story as an example to describe a story a team has found in their user research. A young woman told our team that whenever she rides her bike at night through a nearby forest, she always calls her boyfriend, until she arrives at home safely. It is a small incident with no dramatic turn, yet it seems to me as a very common type of story we hear in user interviews. It is common in a sense that it describes a person in a situation in which she faces a challenge that neither leaves her completely helpless nor completely in control. The story indicates that she has found some way of dealing with her situation. Calling her boyfriend might not be a perfect solution with regard to her goal, but it is a good-enough-solution to not feel completely helpless.

Think of stories as dots on a spectrum in which people find themselves more or less capable of dealing with a situation (see image below). From my experience, it is very rare to find stories at the very extreme ends of that spectrum. Most stories would somehow cluster in the middle with few outliers.

Continuum_Storytelling_HPI Academy
Continuum of Stories in Innovation Projects © Rhinow 2018

Stories about being helpless: We rarely hear stories from people that are completley helpless in challenging situations. It may happen more frequently in extreme and unique situations, e.g. in disasters, emergencies. In general, these stories come up rarely. Going back to our example: If that woman had told us her story differently, e.g. that she does not ride her bike alone at all at night, because she does not know how to feel safe enough, the story would probably classify as a story about someone being completely helpless. However, if she only avoids riding alone or at night or through that forest, we could still interpret her behaviour as a way of dealing with her situation. In fact, avoidance turns out be a quite common way of dealing with challenging situations in general, even though we would also not classify this behaviour as a very satisfying solution.


Stories about people that are or at least that feel helpless are obviously very promising from a designer’s standpoint. These kind of rare stories immediately invite us to think about exploring a problem in depth and look for ways to (re-)design that situation for the better. A design team may ask themselves by looking at such a story:

“Can we help {person} become more empowered in {situation}, when all she wants is to {goal}?”

Again, a team can only define a framed question like this when they captured the main ingredients of the story: Who is the actor? What is the actor’s goal? What is the situation? Optionally: How does the actor deals with that situation now? In our hypothetical story in which a young woman is more or less helpless, the consequential question would be:

“Can we help {the young woman} become more empowered in the situation she rides alone through a forest at night, when all she wants is to {ride without feeling unsafe or exposed to a potential threat}?”

The story explores a designated problem space without being inspired by any solutions yet. However, let’s keep in mind that in the actual story the young woman is in fact not completely helpless but has found a way of dealing with her situation. She feels empowered at least to some extent.


Stories about being empowered: Also, we rarely hear stories about people facing challenges and being completely empowered to act ideally. It rather happens in situations that describe routines or that are very common and therefore commercial offerings are already designed to empower an appopriate behaviour. Think of a challenge that is perfectly adressed by a design that would otherwise be severely difficult to deal with: You may travel to Budapest for the first time in your life and look for a good place to eat. Now, 20 years ago, this may have been a difficult challenge. Nowadays, you open an app on your cellphone that directly links you with some of the local’s recommendations. You are still foreign to the city, but you now feel empowered in that very situation.

Stories about people being empowered do not necessarily invite designers to re-design a situation. These stories very well may indicate that the existing design is simply good enough to empower a person in taking action appropriately. The good-enough-design is often a commercial solution, a machine, an app or a service, but it may also be a workaround that a single person came up with and further elaborated. Nevertheless stories about empowerment can become important, too. It is worth considering how a single workaround or solution already empowers a person. In consequence, this solution can either be exploited and turned into a product or it can be transfered and scaled to new markets. The question may look like this:

“Who would benefit from {existing design} similar to {person} in {situation}, when all they want is to {goal}?”

As I said before, stories about people being empowered indicate a chance to exploit existing knowledge or insights, even existing solutions. Teams may not have to reinvent a wheel that proves to perfectly move a car if that is the actual challenge. These stories can best be adressed with the skills and tools of operational excellence. We may not need to explore a problem that is already well understood, but we may be able to refine or scale an existing solution, e.g. making it more convenient, cheaper or simply more accesible. 


Stories in the middle of the continuum: In many cases existing designs leave room for improvement and it is up to the team to carefully consider whether improvements are worth the effort, e.g. users may not switch to a better version, if the existing solution is simply good enough.

In our example a team may very well define that woman’s situation as a story about a person that is neither completely helpless nor completely empowered. It is a story in the middle of the continuum, worth elaborating. The question her can be phrased like this:

“How to improve {existing design} to empower {person} in {situation}, when all she wants is to {goal}?”

The existing design placeholder refers to the woman’s actual behaviour that clearly empowers her to some extent but may not be sufficient for her to feel completely empowered. The sentence could be:

“How to improve {the idea of an ensuring connection} to empower {a young woman} at a {commute, where she is alone}, when all she wants is to {feel guarded or at least monitored by someone she trusts}”? 

There are of course many ways to tell the story. A team would have elaborate a story in a way that it accurately describes their understanding of he situation. The story I wrote down paraphrases her workaround as a design she came up with. She calls her boyfriend, because she trusts him. Maybe other people could be called as well. Having a call open means to have a connection in general, not to discuss something in particular. Through carefully defining what the existing design provides, the design team can clarify how to elaborate the design into something better, more useful, more convenient, more secure, more accessible. As they figured out, people like that young woman would also appreciate the chance of having connection to other people they can trust. She may not want to necessarily call someone, but makes sure, that a trusted person knows at any time during her ride, where she is and whether or not she unexpectedly stops her ride. That incident would potentially indicate a problem. By simply clicking on a button, she could then affirm whether or not a problem or threat occurs to her which would then send an alarm to that trusted person who can call for help with her GPS location immediately. The team designed an app called Wayguard that was inspired by that woman’s workaround. The app is based on a story about someone neither completely helpless nor completely empowered yet. Therefore, the app can be regarded as an elaborated version of an existing design, neither a new design, nor merely a productized version of an existing design.

To sum it up, The continuum of stories allow to position stories we hear and consider different options: should we design new solutions, should we elaborate some existing solutions or should we simply acknowledge an existing solution as good enough, maybe just introduce them into new markets (see image of the complete continuum below).

Continuum complete_Storytelling an der HPI Academy
Continuum of User Stories and consequential Design Opportunities © Rhinow 2018

When the continuum matters

The continuum allows for position user stories based on their design potential. It does matter whether a user story already indicates that existing designs exist or whether a challenge leaves a person rather helpless. One of the worst things that can happen in innovation projects is when rather inexperienced teams start work in explorative settings (e.g. design thinking) on challenges that demand for exploitative behavior (e.g. lean production, Six Sigma), because existing solutions are known and sufficient. These teams will eventually struggle to deliver a solid performance, as they work on the wrong challenges for their working mode. In another series of articles I talked about the importance of knowing your challenge in order to choose the approriate team work setting. The continuum is supposed to open a discussion within the team about the nature of stories that they elaborated. It quickly allows to figure out what a team can do with what kind of stories based on their teamwork setting and their project brief.

It seems obvious to have these reflections, and experienced teams and product managers will intuitively do so without applying the continuum. However, especially inexperienced teams can easily get lost in decision making process about how to proceed with a huge number of insights and data from their user research. In my view it is valuable to provide them with frameworks to first elaborate their “Minimum Viable Stories” and later define the nature of their stories along the continuum.