Bridging Journey Maps with Software Development
User Story Maps - The Structure
User Story Maps, popularized by Jeff Patton, are another method of building on the basic concept of Journey Maps. A User Story Map is mainly used to keep the big picture in sight while delivering in small increments.
The concept of thinking in stories originates in the simple idea of telling stories about what a user would do with our tool. Step by step. It closely aligns with how we think about Journey Maps.
The starting point is the journey, told in simple, small steps with keywords. The journey is from the perspective of a user. The user can change over the arch of the story. For example, you will alternate between sellers and buyers if you have a two-sided marketplace.
This journey is called the backbone in User Story Mapping. It follows a narrative of how your users would describe their actions. It helps you to sort your thinking as with other mapping activities.
Above the backbone, you add the big overall goals which structure the experience. Different steps in your funnel, different parts of an application, and all these big groups you already have or anticipate to help structure your map.
Below the backbone, you add all the small tasks, details, ideas, and alternatives needed to enable you to do this step. It is okay to describe tasks, features, system capabilities, etc. This whole collection of information is called the body.
The body is where you connect the user experiences and the functionality you must provide to enable this. You don’t have to describe features here. Defining tasks and sub-tasks is often a great way to get clearer at this level.
These maps can get quite big. You can do this for a complete application or just for a small section of an application. Take your current focus area.
It helps you agree and align the general user journey with your team and stakeholders. And it makes everything visible to everybody. This map collects all solution ideas and approaches in one picture.
This map is a conversation tool and should be used as such. When mapping a User Journey Map, it is natural that discussion occurs about the correct order of steps, solution ideas, needed sub-tasks, and what systems might be involved. This is a good thing. These discussions will happen anyway during the development process. It is better to discuss while still writing and throwing away stickies instead of discarding hi-fi prototypes or code later.
User Story Maps are best used if you approach a more extensive project for a new tool or rethink significant portions of an existing one.
Creating a first version of a User Story Map is just the first step. There is more you can do with this artifact. More on this in the following posts.