User story maps solve the user’s problems in form of a discussion. Your job as a product manager or user experience consultant should be to make the world better through user-centric products. Essentially solving the user’s problems.
Contrary to popular belief, user story maps are not just cash cows for agile experts. They will help a product to succeed, by increasing their understanding of the system. Not just what’s inside it, but what will happen to the world as a result. By focusing on the opportunity and outcomes the team can prioritize development. In reality, this often means stopping the proliferation of features, and underdoing your competition.
Wait a minute, did you just read underdoing? As in, fewer features, not making bold promises and significantly less customizability and options? Yes indeed. The founders of Basecamp (formerly 37signals) are the champions of building less. In their book ReWork: Change the Way You Work Forever they tell Basecamp’s success story while giving vital advice to anyone trying to run a build a product or a startup:
“When things aren’t working, the natural inclination is to throw more at the problem. More people, time, and money. All that ends up doing is making the problem bigger. The right way to go is the opposite direction: Cut back. So do less. Your project won’t suffer nearly as much as you fear. In fact, there’s a good chance it’ll end up even better.” (Jason Fried)
User Story Maps will help you to throw less at the problem, chopping down extras, until you reach an awesome product, which is actually done. One of the problems with long product backlogs or nightmarish requirement documents is that it never gets done. Literally never.
Once I had to work on improving the user experience of a bank’s backend. It was a gargantuan task, as this backend was a large collection of distributed microservices, which meant hundreds of different forms with hard to understand functions and a badly designed multi-level menu which connected them together. I knew almost nothing about banking, and they knew almost nothing about UX, so this was a match made in heaven. They gave me a twelve-page document. That was just the non-disclosure agreement. The project had many 100+ page documents, detailing various things and how they are done, complete with business processes and banking jargon. They wanted us to compile an expert review on what needs to be redesigned and create a detailed strategy for that.
I found a better use of their money than wasting time on expert reviews and redesign strategies at that stage. Recording or even watching bank employees, while they used the system during their work was out of the question. So we went for the quick win and did user story mapping in the first week of the project. Among the attendees of the user story mapping sessions, there were a few non-manager level bank employees, who used the backend extensively. One of them was quite new to her job, but fortunately, quite talkative about it. It was immediately evident that most employees almost never used at least 95% of the functionality. Those were reserved for specially trained people, usually managers. After creating the user story map with the most essential and frequently used features, I suggested a backend interface, which only contained about 1% of the functionality of the old system at first, with the mention of other features to be added later. (As a UX consultant you should avoid saying no, instead try saying later. It has the same effect for the project but keeps everyone happy.) No one in the room believed that such a crazy idea would go through senior management, although they supported the proposal. Quite the contrary, it did go extremely well with senior management. The senior managers understood, that by creating a simple and fast backend user interface, they will be able to reduce the queues without hiring new employees. Moreover, if they need to hire people, training will be easier and faster. The new UI could also reduce the number of human errors.
Almost all of the old backend was still online two years later, although used only by a few employees. This made both the product and the information security team happy, not to mention HR. The functionality of the new application extended only slightly in 24 months. Nobody complained and the bank’s customers were happy with smaller queues. All this was achieved with a pack of colored sticky notes, some markers and much more importantly a discussion and shared understanding.
This is just one example, how a simple technique, like user story mapping, could save millions of dollars for a company.
Just tell the story
Drawing a map, any map will lead to solving the problem. User story maps aim to replace document hand-overs with discussions and collaboration.
Enterprises tend to have some sort of formal approval process, usually with a sign-off. That’s perfectly fine, and most of the time unavoidable. Just make sure, that the sign-off happens after the mapping and story discussions. Ideally, right after the discussion, not days or weeks later.
There is a reason why product manager, UX experts, and all stakeholders love stories: they are humans. As such, we all have a natural tendency to love an emotionally satisfying tale. Most of our entertainment revolves around stories, and we want to hear good stories. A great story revolves around conflicts in a memorable and exciting way.
How to tell a story?
Telling a story is an easy task. We all did that as kids, yet we tend to forget about that skill we possess when we get into a serious product management discussion. How to tell a great story? There are a few rules to consider, the most important one is that you should talk about something that captivates the audience.
You should focus on the audience. What are their problems? What would make them listen actively, instead of texting or catching Pokémon, while at a user story discussion? Even if the project is about scratching your own itch, you should spin the story so it’s their itch that is scratched. Engaging the audience can be indeed a challenge.
Once upon a time I have written a sci-fi novel. Actually, it was published in 2000, with the title Tűzsugár, in Hungarian. The English title would be Ray of Fire, but fortunately for my future writing career, it was never translated into English. The book had everything my 15-16 years old self considered fun: For instance a great space war or passionate love between members of different sapient spacefaring races. The characters were miscellaneous human and non-human life-forms stuck in a spaceship for most of the story. Some of my characters had a keen resemblance to miscellaneous video-game characters, from games like Mortal Kombat 2 or Might & Magic VI. They certainly lacked emotional struggles over insignificant things like mass-murder or the end of the universe. As I certainly hope you will never read that book, I will spoiler you the end. A whole planet died, hinting that the entire galaxy might share the same fate, with a faint hope for salvation. This could have led to a sequel, but fortunately for all sci-fi lovers, I stopped writing the sequel after nine chapters.
The book seemed to be a success. A national TV channel made an interview with me if that’s any measure of success. More importantly, I had lots of fun writing it. But the book itself was hard to understand and probably impossible to appreciate. My biggest mistake was writing only what I considered fun. To be honest, I still write for fun, but now I have an audience in mind. I tell the story of my passion for user experience mapping to a great audience: you. I try to find things that are fun to write and still interesting to my target audience. As a true UX geek, I create the main persona of my audience before writing anything and tell a story to her. This article’s main persona is called Maya, and she shares many traits with my daughter. Could I say, I’m writing this book to my daughter? Of course, I do, but I keep in mind all other personas. Hopefully one of them is a bit like you.
Before a talk at a conference, I always ask the organizers about the audience. Even if the topic stays the same, the audience completely changes the story and the way I present it. I might tell the same user story differently to one of my team members, to the leader of another team, or to a chief executive. Differently internally, to a client or a third party.
When telling a story, contrary to a written story, you will see an immediate feedback or the lack of it from your audience. You should go even further and shape the story based on this feedback.
Telling a story is an interactive experience. Engage with the audience. Ask them questions, and let them ask you questions as a start, then turn this into a shared storytelling experience, where the story is being told by all participants together (not at the same time, though, unless you turn the workshop into a UX carol).
When you tell a fairy-tale to your daughter, she might ask you why can’t the princess escape using her sharp wits and cunning, instead of relying on a prince challenging the dragon to a bloody duel. (Then you might start appreciating the story of the My Little Pony where the girl ponies solve challenges mostly non-violently while working together as a team of friends, instead of acting as a prize to be won.) So why not spin a tale of heroic princesses with fluffy pink cats?
Start with action
Beginning in medias res, as in starting the narrative in the midst of action is a technique used by masters, such as Shakespeare or Homer, and it is also a powerful tool in your user story arsenal.
While telling a story, always try to add as little background as possible, and start with drama or something to catch the attention of the audience, whenever possible.
At the beginning of The Odyssey quite a few unruly men want to marry Telemachus’ mother, while his father has still not returned home from the Trojan War. There is no lengthy introduction explaining how those men ended up in Ithaca, or why the goddess, flashing-eyed Athena cares about Odysseus.
The poem was composed in an oral tradition and was more likely to be heard than read at the time of composition. While literacy skyrocketed since Homer’s time, you want to tell and discuss your user stories. Therefore you should consider a similar start. (Maybe not mentioning the user’s mother or her rascally suitors.)
In literary fiction, a complex story can be entertaining. A Game of Thrones and its sequels in A Song of Ice and Fire series is a good example for that. The thing is, George R. R. Martin writes those novels, and he certainly has no intention to discuss them during sprint planning meetings with stakeholders. User Story Maps are more similar to sagas, folktales and other stories formed in an oral tradition. They develop in a discussion, and their understandability is granted by their simplicity. We need to create a map as simple and small as possible, with as few story cards as possible.
So how big should the story map be? Jim Shore defines story card hell as something that happens when you have 300 story cards and you have to keep track of them. Madness, huh? This is not Sparta! Sorry Jim for the bad pun, but you are absolutely right, in the 300 range, you will not understand the map, and the whole discussion part will completely fail. The user stories will be lost, and the audience will not even try to understand what’s happening.
There is no ideal number of cards in a story map but aim low. Then eliminate most of the cards. Clutter will destroy the conversation.
In most card games you will have from two to seven cards in hand, with some rare exceptions. The most popular card game both online and offline is Texas Hold ’em Poker. In that game, each player is dealt only two cards. This is because human thought processes and discussions work best with a small number of objects. Sometimes the number of objects in the real world is high. Our mind is good at simplifying, classifying and grouping things into manageable units. With that said, most books and conference presentations about user story mapping show us a photo of a wall covered with sticky notes. The viewer will have absolutely no idea what’s on them, but one thing is certain, it looks like a complex project. I have a bad news for you: projects with a complex user story map never get finished, and if they do get finished to a degree they will fail. The abundance of sticky notes means that the communication and simplification process needs one or more iterations. Throw away most of the sticky notes! To do that, you need to understand the problem better.
Tell the story of your passion
Seriously. Find someone, and tell her the user story of the next big thing. The app or hardware which will change the world. Try it now. Be bold and let your imagination flow.
I believe that in this century we will be able to digitalise human beings. This will be the key to both humankind’s survival as a species and our exploration of the space. The digital society would have no famine, no plagues, and no poverty. This would solve all major problems we face today. Digital humans would even defeat death. Sounds like a wild sci-fi idea? It is, but then again, smartphones were also a wild sci-fi idea a few decades ago.
Now I will tell you the story of something we can build today.
The grocery surplus webshop
We will create the user story map for a grocery surplus eCommerce site in the second chapter of my new book, User Experience Mapping. Using this online store, we will sell clearance food and drink at a discount price. This means food, that would be thrown away at a regular store. For example food past its expiry date or with damaged packaging. This idea is popular in developed countries, like Denmark or the UK, and it might help cutting down on the amounts of food wasted every year, totaling 1.3 billion metric tons worldwide. We are trying to create the online-only version of WeFood ( https://donate.danchurchaid.org/wefood ).
Our users can be environmentally conscious shoppers or low-income families with limited budgets just to give two examples. In this article, I will not introduce personas, and treat them separately, so for now, we will only think about them as shoppers.
The opportunity to scratch your own itch
Mapping will help you to achieve the most, with as little as possible. In other words: maximize the opportunity, while minimizing the outputs.
To use the mapping lingo: The outputs are products of the map’s usage, while the outcomes are the results. The opportunity is the desired outcome we plan to achieve with the aid of the map. This is how we want to change the world. We should start the map with the opportunity.
The opportunity should not be defined as selling surplus food and drink to our visitors. If you approach a project or a business without solving the users’ problem the project might become a failure. The best way to find out what our user want is through valid user research, remote and lab-based user experience testing. Sometimes we need to settle with the second best solution, which happens to be free. That’s solving your own problem, in other words, scratch your own itch. Probably the best summary of this mantra comes from Jason Fried, the founder and CEO of Basecamp:
“When you solve your own problem, you create a tool that you’re passionate about. And passion is key. Passion means you’ll truly use it and care about it. And that’s the best way to get others to feel passionate about it too.” (Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application)
We will create the web store we would love to use. Although, as the cliché goes, there is no I in team, but there is certainly an I in writer. My ideal eCommerce site could be different to yours.
When following the examples of my book, please try to think of your itch, your ideal web store, and use my words only as guidance. You can create the user story map for any other project, ideally something you are passionate about. I would encourage you to pick something that’s not a webshop, or maybe not even a digital product if you feel adventurous.
You need the tell the story of your passion. (No, not that passion. This is not an adults-only website.) My passion is reducing food waste (that’s also the poor excuse I’m using when looking at the bathroom scale). Here is my attempt to phrase the opportunity.
The opportunity: Our shoppers want to save money while reducing global food waste. They understand and accept what surplus food and drink means, and they are happy to shop with us.
Actually, the first sentence would be enough. Remember, you want to have a simple one or two sentence opportunity definition.
I ended up working for two tapestry web shops as a consultant. Not at the same time, though, and the second company approached me mostly as the result of how successful the first one was. It’s a relatively small industry in Europe, and business owners and decision-makers know each other by name.
I still recall the pleasant experience I had meeting the owners of the first web shop. They invited me to dinner at a homely restaurant in Budapest. We had a great discussion and they shared their passion. They were an elderly couple, so they must have spent most of their life in the communist era. In the early 90’s they decided to start a business, selling tapestry in a brick and mortar store. Obviously, they had no background in management or running a capitalist business, but that didn’t matter, they only wanted to help people to make their homes beautiful. They loved tapestry, so they started importing and selling it. When I visited their physical store I have seen them talking to a customer. They spent more than an hour discussing interior decoration with someone, who just popped by to ask the square meter prices of tapestry. Tapestry is not sold per square meter, but they did the math for the customer among many other things. They showed her many different patterns, types and discussed application methods. After leaving the shop the customer knew more about tapestry than most other people ever will.
Fast forward to the second contract. I only talked to the client on Skype, and that’s perfectly fine because most of my clients don’t invite me to dinner. I saw many differences in this client’s approach to the previous one. At some point, I asked him “Why do you sell tapestry? Is tapestry your passion?” He was a bit startled by the question, but he promptly replied: “To make money, why else? You need to be pretty crazy to have tapestry as a passion.” Seven years later the second business no longer exists, yet the first one is still successful. Treating your work as your passion works wonders.
Passion is an important contributor to the success of an idea. Whenever possible, pour your passion into a product and summarize it as the opportunity.
If you buy my new book, User Experience Mapping, you will find more about user story maps in the second chapter. In that chapter, we will explore user story maps, and how they help you to create requirements through collaboration (and a few sticky notes):
- We will create user stories and arrange them as a user story map.
- We will discuss the reasons behind creating them.
- We will learn how to tell a story.
- The grocery surplus webshop’s user story map will be the example I will create in this chapter.
- To do this, we will explore user story templates, characteristics of a good user story (INVEST) and epics.
- With the 3 Cs (Card, Conversation, and Confirmation) process we will turn the stories into reality.
- We will create a user story map on a wall with sticky notes
- Then digitally using StoriesOnBoard.
And that’s just the second chapter, each of the eleven chapters contains different user experience maps. The book reveals two advanced mapping techniques for the first time in print, the behavioral change map and the 4D UX map. You will also explore user story maps, task models, and journey maps. You will create wireflows, mental model maps, ecosystem maps and solution maps. In this book, we will show you how to use insights from real users to create and improve your maps and your product.
Start mapping your products now to change your users’ lives!