# User Story Mapping Walkthrough — Learn by Doing ## Before We Begin **Diagnostic:** Whose story is it? When you plan a feature, do you start from the user's journey or from the features you want to build? What's the difference—and why does it matter for prioritization? **Checkpoint:** You can articulate why "user does X, then Y" leads to different decisions than "we need screens A, B, C." --- ## Step 1: Identify the User and Outcome You're planning a feature: "Users can manage their saved payment methods." Before building a map, you need a clear user and outcome. **Task:** Write down (a) who this map is for (be specific: new shopper, returning customer, B2B admin?), and (b) one sentence describing the outcome they accomplish. **Question:** Why does defining the user matter? What if you had two different users—how might their maps differ? **Checkpoint:** You have a named user and a clear outcome. You understand that different users have different journeys. --- ## Step 2: Build the Backbone (Activities) For your chosen user and outcome, list the high-level activities they perform. Use verbs: browse, compare, add, checkout, track. **Task:** Write 4–6 activities in left-to-right order (the natural sequence of the user's journey). Don't add tasks yet—just the backbone. **Question:** How do you know when an activity is "right-sized"? What makes an activity too big or too small? **Checkpoint:** You have a backbone row: activities in sequence. Each activity is a user action, not a technical component or screen name. --- ## Step 3: Add the Body (Tasks) Under each activity, add 2–4 specific tasks. "Check out" might have: Enter shipping address, Choose payment method, Review order, Confirm. **Task:** Add tasks under each backbone activity. Keep them user-centric (what the user does, not how the system does it). **Question:** Where do you draw the line between "task" and "too granular"? When would you stop breaking down? **Checkpoint:** You have a 2D map: backbone on top, body stacked below. Tasks are concrete but not atomically tiny. --- ## Step 4: Walk the Map Read the map left-to-right as a story. "The user first does X, then Y, then Z..." **Task:** Walk your map aloud (or in your head). Note: gaps, wrong order, missing steps, tasks that don't fit. **Question:** What would you do if you found a task that belongs under a different activity? Or an activity that seems out of order? **Checkpoint:** You've validated the flow. You've identified at least one gap or ordering issue and know how to fix it. --- ## Step 5: Slice Release 1 (Walking Skeleton) The walking skeleton is the thinnest path that delivers value. Draw a horizontal line: above = Release 1. **Task:** For your map, identify the minimum tasks needed to complete the outcome. Draw your Release 1 line. What's in? What's "later"? **Question:** How do you decide what stays above the line vs below? What's the risk of putting too much in Release 1? **Checkpoint:** Release 1 is a coherent, minimal slice. You can articulate what the user gets and what's deferred. --- ## Step 6: Run a Mini-Workshop Imagine you're facilitating a 30-minute story-mapping workshop with two developers and one designer. **Task:** Write a brief agenda: (a) how you'd introduce the user and outcome, (b) how you'd get the backbone and body on the board (who speaks, what order), and (c) how you'd handle the "slice" discussion. **Question:** What could go wrong in the workshop? How would you keep it from becoming a feature list or technical architecture discussion? **Checkpoint:** You have a facilitation plan. You know how to keep the map user-centered and the conversation productive.