Telling the user’s story
Telling stories that matters about the “whys” and “wheres” of our products.
While I can fall in love with a product, what I will remember most is the satisfaction of solving a problem.
I absolutely loved my first iPhone. The look, the feel, how it behaved. It was a huge step up from my previous phones or the Palm Pilots of old. I wasn’t anything near being an early adopter, so Apple had gotten the worst kinks out of it by the time I started using it back in 2008. Fast forward to the present. No matter how revolutionising my first iPhone felt back then, what I remember the most now is not the actual device, but what I was able to do with it. My iPhone helped me solve problems I didn’t even know I had, it made my life easier in ways I couldn’t have perceived possible before.
Today I use an entirely different brand of smartphone, a Samsung Galaxy of the non-exploding kind, that solves much of the same problems as my first iPhone did. I have tried different makes of phones, both iPhones and Androids, not attaching any particluar significance to the brand or model. What matters to me is what my phone can do for me, what problems it can help me solve. My phones have changed, but my context and the problems I need to solve have remained the same.
I’m not unique in my relation to this product, most people consume products to fulfill a need, to solve a problem. Sure, superior branding can influence people to use a product to build their identity but most products in the mainstay won’t come even close to this.
So why is it we so often tell the story of our products instead of our users?
Behold our mighty product that will solve all your problems, save the day, get you a promotion, and make you live a happier life. Sounds familiar?
Most stories told during product development is about the product, how the product saves a user from whatever problem haunts her. This is a direct disconnect from how the user perceives the story, no one is ever a sidekick in the tale of their own lives. For our users the story is about them, not about the products they use. It is about how they use products and how products can be helpful to them. To summarise, their stories are about them.
Agile user stories, jobs to be done stories, user story maps, and customer journey maps all have one thing in common. They tell the story about what a product can do for me, what functions it might have, or what problem it might solve for me. Seldom do we tell the story about the context the users are in, where the users are. Neither do we tell why a user wants to use the product in the first place. Most stories never touch these leaps of faith of “whys” and “wheres”, and as a consequence we might know everything about what our product can do but next to nothing about whether it solves an actual problem of if anyone will use it at all.
Not telling the story of “why” and “where” leaves us at risk of developing a product that doesn’t solve a real problem, a product no one will use. These stories are just as important as the stories about the “whats”, and they need to be validated and improved upon for us to build a product that’s useful to our users.
Understanding the “whats” of a product is easier than understanding the “whys” and “wheres”. A “What” is easily quantified, either a product has a function or it doesn’t. We can measure how efficiently a user can use a function, and we can measure how much we improve efficiency by tweaking that function.
Understanding the “why” and “where” takes a bit more afterthought, but they are important parts of both our value hypothesis (are we providing value to the user) and our growth hypothesis (how will the user find our product).
Not minding those is courting disaster.
The anatomy of a story
The most basic of stories told boils down to someone doing something to accomplish some outcome.
[Actor] does [action] to accomplish [outcome].
To retell the tale of Star Wars IV - A New Hope:
Luke Skywalker (actor) destroys the death star (action) to accomplish a victory for the rebel alliance (outcome).
This tale summarises what happens in the movie quite well, but it isn’t all that exiting as a story. And from this description we know almost nothing about the plot. Why would Luke want to blow something up? Where did he come from? Who are the rebels? What is even a death star?
Most storytelling tools are built on this framework, and therefore we are left knowing next to nothing about the plot behind the story.
If we look at expanding our notion about a story’s structure, we can use story arcs. A story arc has a three main parts, a beginning, a middle, and an end. Spread evenly over the story arc are plot points that defines the basic building blocks of the story.
The exposition is where we get to know the main actors, who they are and where they come from. An inciting incident happens that makes our actors go on an adventure, casting them into the story. After the inciting incident we build the tension with rising action all up to a crisis where our heroes are put to the mettle. Our heroes resolve the crisis during a climax, where the entire story balances on a knife’s edge. With the resolution of the climax we go into the denouement where the story resolves, ending in a state where our heroes are somewhat better off than they were before the story.
The basic building blocks of a story arc are: Exposition, Inciting incident, Rising action, Climax, Denouement and an Ending.
If we retell Star Wars IV — A New Hope using this framework we get something like this:
Luke Skywalker, a local farm boy accidentally purchases two droids with valuable information (exposition). The evil Empire tracks down the droids killing Luke’s aunt and uncle in the process, forcing Luke to flee for his life (inciting incident). Fleeing the Empire’s grasp with the help of friends Luke finally gets captured at the Death star, forcing him to find a way to temporarily disable the mighty battle station. During a daring escape Luke saves Princess Leia, departing for a hidden Rebel base (rising action). The Empire, tracking Luke and Leia, shows up at the Rebel base threatening to blow it up using the Death star’s planetary laser cannon (crisis). In a daring frontal assault Luke manages to use the information hidden in his droids to destroy the Death star, striking a crippling blow to the evil Empire saving the Rebel alliance (denouement). Luke and friends are celebrated as heroes of the rebel alliance (the end).
A bit more longish than the previous example, but now we get to know Luke. Where he comes from and why he leaves his home. The rising action makes us want to know what happens next, at least if you watch the movie, and we are left in suspense all up to the resolution of the climax. And it sounds surprisingly close to the original story, it’s almost as if George Lucas used a similar framework when he wrote the script for the movie (pro tip, he probably did).
Noticed something missing from the story? Depending on what our product in this story was, the information in the droids or what Luke used to blow up the Death star with, almost nothing in the story is about that product. The story is about the person(s) using the product, and how they use the product to overcome their problems, leaving them in a better state than before.
Telling stories that matters
What a product can do matters, and we need to keep tell those stories. They define our product, but they don’t define our users.
To help us define who our users are, where they are, our value hypothesis, and our growth hypothesis we need to explore the users’ needs and the contexts they are acting in. Telling the story from the perspective of the user will help you explain who the user is, what her needs are, how she comes into contact with your product, and how it helps her. Make her the hero of the story, make the story to be about her overcoming her problem.
Use the story arc framework to structure your story. Begin with introducing the user, who she is and where she comes from. Tell your audience about what needs that drove her to look for a product to begin with, humanise her problem and make it understandable for those who will build the product. Build tension by telling about the obstacles she meets, and how she searches for a solution to her problems. The crisis is when her need really comes to attention, it’s about making it or braking it. Then, and only then, do your product enter the story, and it does so by providing a mean to solve her problem. Mind that the story is still about the user overcoming her challenges, not your product doing it for her. She is the hero of the story, not your product. End the story by telling how she uses your product, and how she ends up in a better state than before.
What can we learn from stories of this kind? We can create a few hypothesises from every story point. The exposition tells us who our users are, create personas and validate them. The inciting incident tells us about what we believe the users’ needs are, put these beliefs to the test. The rising action and climax tells the story of your growth hypothesis. You guessed right, validate it. The climax and the denouement is your value hypothesis, again validate it. The end is why your user should have chosen your product in the first place, make sure you tell her when she begins her journey.
There’s a pattern to this story, there are a lot of leaps of faith that we can both identify and put to the test by validating them. By validating we make sure we’re not only building a product that can do something, but a product that actually does something of value for our intended users.
Christian Rick is a UX-evangelist and Project Manager on a mission to design for great user experiences while delivering real business value. When not writing he works at a digital agency in Uppsala, Sweden.
You can find him talking about storytelling, creativity, ideation, and collaboration on Medium and Twitter at @christianrick.
If you like this article, please click the ♡ symbol to recommend it.
