Starting with a story map was new for us, but it had some big benefits
Late this summer, a tiny team of three designers here at Fjord began an amazing project. Our client was a major freight company that ships across the US and Canada. The company has been around for over a hundred years, and they know the business inside and out. However, their technology hasn’t kept pace with the market. They’re now in the midst of a technological revolution.
The men and women at this company work hard. The work is outdoors, in extreme weather and dangerous industrial conditions. They plan, track and report their work on printed paper marked up with Sharpie. The process works, but it’s prone to errors. Each time a worker forgot to record what they did during the day, the company left more money on the table.
Our task was to design new software to help manage that day-to-day work. The software would help workers locate, assemble and deliver thousands of tons of goods every day. It was an intense, exciting challenge.
We had a strong plan of attack, but as we spoke with the client we realized that things weren’t perfectly aligned. While we were preparing to help define the vision & strategy of their product, they were already concerned with building the software.
A big part of building the new software was documenting user stories for our client’s development team. This was the last step in our plan. It was meant to come after we had done a month or two of research and designed a north-star vision for their application. However, the reality was that our client needed those user stories immediately.
Recalibrating our approach
We debated what to do. Should we reset expectations, stick to the plan as-is or take a blind stab at stories right away? Nothing seemed right.
The client already had user stories. Not one set of stories, but competing versions. The business managers were writing stories about the features they needed. These were about efficiency and cost savings. The technical folks were writing stories based on their knowledge of internal systems. As human-centered designers, we were writing stories based on which features would best serve the end-users.
We didn’t need to introduce yet another way of writing technical requirements. We needed to find a way to ensure that the client’s finished product matched their desired business outcomes, had impact with their users and was technically feasible.
Our client had many ideas, but there still was no clear way to bring the necessary points of view together. Luckily, my friend & former colleague Nate Archer had given me an introduction to the practice of User Story Mapping. It seemed to fit our needs.
User story mapping had the ability to tie our detailed knowledge from research into a familiar development framework. We could still map a user’s journey through the experience, but we would do it from a software point of view, using the language of agile methodology.
Below, I’m sharing a short summary of what I learned. If you want the full context behind story mapping I recommend checking out Jeff Patton’s book called User Story Mapping.
So what is a user story map?
- A living, collaborative document (the size of an office wall)
- Mapping a user(s) experience
- Across an entire software initiative
- To define & prioritize an app or service’s features & functionality
Getting your stories straight
Before you make a map, it’s important to understand what size story you’re working with. Here’s a real-world example to illustrate what I mean:
If your goal is to make a pizza, that’s a pretty big story. You can break that down. Below that you might have: purchasing ingredients, gathering equipment, preparing the dough, and several more tasks (home-made sauce?). Those tasks can be broken down further — if preparing dough, you might have stories for proofing yeast, measuring flour, etc.
UPDATE: Since I originally wrote this article my story mapping practice has changed. When story mapping, I now follow a general mapping hierarchy of: User goals → Tasks → Stories to break things down consistently. This keeps it nice and clear about who is doing what and why. See the illustration below—not too hard!
If you live day-in, day-out in the agile world you’re already using user stories. They are written a very specific way, and follow a predictable format. The thing about user story mapping is that writing JIRA-ready detailed stories with the correct acceptance criteria needs to happen later. First you must define the product in broad strokes. Then you pick your priorities and dive into the details.
Creating a user story map
Once you have a rough idea of which stories to include, the next step is to build a map. You need to map those stories so they form a narrative from left to right.
It’s helpful to think of a story map as the overall plot of an application. Novels and films almost always have multiple characters and protagonists interwoven throughout. Your story map will inevitably need to represent the perspective of multiple users.
Features that involve each user can come at the beginning, middle or end of the narrative. I’ve added some slides below to illustrate how it all comes together:
If you clicked through the slides above, you noticed that user story maps have a few key elements:
- They have reference material to actual users posted up on the wall to refer to when mapping. It’s not enough to make a persona based on yourself. You need data from research done with real people.
- They have the Goals (major milestones from the user point-of-view) listed in narrative sequence at the very top. We used pink Post-Its here, but you can use whatever color you like.
- They have a backbone of tasks that make up the core of the map. These are the orange Post-Its listed from left to right below each Goals.
- Stacked from top to bottom below each story are more granular stories for each task. These are the teal Post-Its.
That’s the quick tour of user story mapping. Let’s take a look at how we used it on our project.
How we mapped our stories
We only had a single day with our client. There simply wasn’t enough time for us to create a user story map from scratch. So what we did was gather all the user stories in one place. From those, we created a draft version of the map. We made informed guesses about what was needed based on our research and expertise. This went up on the wall prior to our workshop. When our clients came in for the day we invited them to tear it apart and rebuild it the way it SHOULD be.
Story mapping required us to give up some of our privileged space as expert design consultants. Rather, we needed take on the role of facilitators and listeners. We needed to leverage our clients’ subject matter expertise and closeness to the problem to create the best map possible.
It felt a little weird, and just a bit risky. We were stepping back and providing the space for our clients helps us find the shape of the software.
Defining an MVP
At the end of the workshop, We asked our clients to spend time looking at the entire map. They were then asked to decide which stories would be most useful to prioritize in our design and validation phase. These were the toughest stories. These were the stories that required the most experimentation and creative thinking to get right.
We quickly wireframed and tested those stories in the field to validate our assumptions. Throughout this process we were solving not just for our stories, but encompassing many peripheral stories. It was a great way to dive in and define the interaction model and architecture while keeping everything grounded in the needs of real users.
At the end, we had designed much more than just an MVP. And when we went to test, the feedback from our users was incredible. By focusing on user stories, we had focused on the people who mattered most—the people who would end up using the software every day.
What we learned
Starting with a story map was new for us, but it had some big benefits. It was an approach that allowed us to stay human-centered but be more inclusive in talking about our initial approach to designing software.
We could better facilitate a discussion about business requirements, technical requirements and the needs of the user. The user stories provided a metric for success to refer back to. We could always ask — is this design addressing the story? This is a powerful tool, and one we look forward to continuing to refine and adapt to our practice.