Lost in UX Requirements? User Story Maps can help.

I first heard about User Story Maps when I stumbled across Jeff Patton’s article on the subject. I subsequently attended a webinar he hosted, bought his excellent book, and immediately fell in love with the idea of applying this tool in my workflow.

Why User Story Maps?

I’d used Customer Journey Maps, Stakeholder Maps, Empathy Maps, Site Maps and various other kinds of maps to show user, customer, system and experience flows, but these particular artefacts were new and exciting for me because they enabled design teams to create a shared understanding of the system requirements early on and also helped with planning and execution phases — especially when used by agile teams working with story cards in a backlog.

Mapping the Agile Backlog

When I first discovered Jeff’s work, I was a Senior Interaction Designer at a digital agency that was the design and build partner for a major online retailer. As far as agencies go, this was the closest thing to a cross-functional agile team you can probably get — product owners were onsite with us and we had daily standups, an agile backlog which was groomed, prioritized and planned into sprint cycles with all kinds of testing, validation and iteration along the way.

Now I’m a big fan of agile methodologies, and I love backlogs and User Stories (when they’re written properly) but despite all the details, comments, labeling, assigning of tickets, file uploads, prioritization and story points, the backlog view doesn’t show the big picture of how all these items relate to one another. Nor does it represent the user experience or interaction touchpoints. That’s where the story map comes in.

Mapping the Experience

Imagine if the first explorers and cartographers hadn’t drawn maps, but instead collected only written information along with sketches and photographs as they sailed the oceans and discovered new shorelines. Imagine that information presented, perhaps using tables or other visual devices to cross-reference information about the relative location, size, distance, geography and so on of the various continents and islands of the world. Imagine trying to create a picture in your mind of how this information translates to the physical world, relative to where you are at a given time. Imagine trying to travel the world with this information, but no map.

Maps are a fundamental tool for understanding the relationships between elements, such as objects, regions or themes. As such, the User Story Map can be seen as an essential part of an agile workflow. Even if your team doesn’t employ true agile methodologies, like scrum or kanban, the User Story Map can help you understand your users’ journeys as they relate specifically to the interactions and functions of the system. Moreover, this tool can also help prioritize features and help group stories into epics, plan sprints/release cycles, and generally create a shared understanding of the big picture.

How User Story Mapping helped our team align on objectives

Our team at Klick recently utilized a User Story Map to help define and lay the groundwork for a new initiative for one of our clients, which involved changes to process, workflow and tools. With a number of stakeholders from different departments and a wide range of potential users, we had spent several weeks of back and forth with emails, spreadsheets, powerpoint decks, sketches and mockups but were still having trouble aligning everyone on the vision.

We scheduled a Story Mapping workshop with the client and key stakeholders, and set about internally creating an initial draft of the story map based on what we already knew. Because our team is distributed between Canada and US, the story map we created in Toronto was captured and sent to our team member in the US who was able to recreate the story map (with much better handwriting!) and stick it on the wall in advance of the workshop. In the 3 hours we had scheduled with the client, we were able to capture the remaining details and everyone left with the most complete and clear shared understanding that had eluded us in previous weeks of conversations.

User stories are great because they help designers understand system requirements through the lens of what the end-user needs. Seeing user stories in a backlog, groomed according to priority and complexity, labeled with project/task IDs, linked with related items, and connected to conversation threads with team members is also a great way to see where things are from an execution standpoint.

If you’re struggling like I was to see the bigger picture and understand how all your backlog items or requirement relate to one another in a real and meaningful way for your users, then you should try this simple and effective tool.

For more information on User Story Mapping, check out Jeff Patton’s site where you can find a number of further articles and resources. You can also contact me or respond in the comments.

Thanks for reading!

Have you used Story Mapping in your own workflow? Join the conversation to share your insights and experience!