User Story Mapping for UX
0 likes4,285 views
This document provides guidance on creating a user story map to plan a software product. It discusses capturing user tasks, activities, assumptions and details on cards and arranging them on a board. The cards are organized chronologically from left to right and by priority on the y-axis. Cards are grouped into slices that represent discrete features. The process involves brainstorming tasks, capturing user and system activities, arranging the cards into a narrative flow and refining the map. Designing and refining the mapping process allows aligning user-centered design with agile development.
User Story Mapping for UX
- 1. What is it? Why Build it? What Will Happen when you do? Name the business problems you are adressing. Determine specific business metrics effected. Decide on metrics that will allow us to measure how people use and like this new product and/or feature. What will we check to confirm that this software is done? Get Everything Out of Your Head Imagine the future, then tell a day in the life story - brain dump each task on to its on card (make sure to talk out loud often and discuss as needed with the group). Do this one step at a time. At this point, don’t worry about organizing the cards in any particicular arragment or order. Just place them on the wall as fast as you can come up with ideas. You’ll re-arrange them later. Not all cards need be tasks. Each card could possibly represtent: - user tasks - system tasks - user subtasks / details - user activities - open questions (helps inform a validated learning strategy) - assumptions (uncertainty and risk) - target outcomes for the user - ideas - opportunities - etc. Each kind of card could be color coded, or somhow visulally differentiated. On the Card - Info to Capture - Each card should have only enough information on it to jog your memory / facilitate discussion - Title (on front) - Description (on back) - Optional Metadata: tracking system / tracking number, indicators of importance, status, rough size, budget, author, date created, value, metrics, dependancies (on front and back - see connextra's template) - Optional Metadata: Theme - a group of cards (stories) that are related in some way conceptually (not functionally) across discontinuous sections of the user journey and release slices (a story can belong to more than one theme) Beyond the Card - Info to Capture - Because many different people will be having input on the cards / map, you'll want to capture more info than fit onto a card. - This additional info can be captured in any way that is useful / advantageous for the team and its members. You can link each card to additional documentation / systems to accomplish this. - things not directly associated with cards might come up such as discussions decisions. Capture these using drawings, photos, videos, and text to retain and remember conversations How to tell the difference between: task, subtask, and activity - Task: something we'd expect to complete before intentionally stopping to do something else. (i.e. take a shower) A sub-task is detail oriented. (i.e. using soap) An activity is more goal level (i.e. getting ready for the day) - SubTask: micro tasks support the parent task (i.e. adjust the water temperature or wash hair) (these are also known as 'fish-level') - Activity: helps organize related tasks that accomplish a goal (i.e. getting washed up, which could include tasks such as: take a shower, brush teeth, etc.) Capture details / sub-tasks on their own stickies as they come up. Arrange details / subtasks below associated main tasks when they are related conceptually or occur concurrently. At first, dont’ worry about if something is a task, or a sub-task. Write everything down that you can come up with. You can always rearrange and recategorize them later. Drawing a horizontal line that segments some subtasks from others represents a slice. This is the first card in the second slice (row). Everything above the slice line is in the first slice. Each slice can be described by defining Buisness Goals / Metrics User Goals / Metrics Main User Pain Points Addressed Focused Value For the User Targeted User Roles Testing / Learning Goals. Things to capture What are the specific things they'd do here? What are alternative things they could possibly do? What would make it really cool or could go wrong? Some cards my contain stories that are not the right size (comprehensiveness and detailed enough) for various members of your team at various stages in the project. When a story is the wrong size, you have to break it appart into smaller stories that are each the right size. A right sized story from a user's perspective is one that fulfills a need A right sized story from a development experiment is on that takes just a few days to build and test A right sized story from a business perspective is on that helps a business achieve an outcome arrange tasks in a rough / approximate chronological sequence Continue repeating tasks above until a full story is told (with a clear beginning and end) or you run out of ideas. Focus on breadth of the story before diving into the depth. That means you shoudl prioritize primary tasks first by creating a narrative accross the chronological x-axis, before delving into subtasks which are placed on the y-axis. If you’ve done this correctly, after a frist pass, your user story map shoudl be wider than it is tall. Add Activities - above tasks to organizes groups of related tasks directed at a common goal Example Get up in the morning Example Turn off the alarm clock Example Notice the buzzer is going off Example Locate the alarm clock Example Hit the snooze button Example Hit the off button Example Get out of bed Example Take a shower Example Dry off with a towel Example Brush teeth Example Grooming Example … Capture big risks and Assumptions Define secondary role(s) / persona(s) User Subtasks and Details List possible users / customers (A name / title plus a sentence or two about each.) Define one primary role / persona (focus on thrilling them above all else) What benefits will they get? Why would they want it? What's in it for them? What can they do with it? Risks and/or assumptions 1 B R A I N D U M P 1 2 1 U S E R TA S K S A C T I V I T I E S S U B TA S K S B R E A K S O M E S TO R I E S D O W N I N TO S M A L L E R S TO R I E S 2 3 4 F R A M E T H E I D E A 1 . C R E AT E C O N T E X T 2 . E N V I S I O N S O L U T I O N S 3 . M A P A S O L U T I O N 4 . S L I C E K E Y Feel free to develop your own color coding, but this is a good place to start. Not all colors in the key are depticted in this poster, but are reccomended categories to consiider. I N T R O User Story Mapping is a powerful technique (pattern / model) that helps teams collaborate and communicate to decide what, when and how to build - it facilitates product definition and planning. strategically decide how maximize outcome and impact for users and the company while minimizing the amount of output (software design and development). create a shared space to discuss and to think through solutions / alternatives to create great outcomes for users (and the business) within constraints. (people, time and money) Merges Agile / Lean methodologies with user-centered design thinking. Story mapping starts with a user's story, and then breaks the narrative / journey into functional chunks. The narrative structure is always maintained (good for designers) while still allowing for deconstruction too (good for developers). The problem with written documentation written documentation (requirements, a pile of user stories) alone, is not enough to communicate clearly to create shared understanding. When people read what's written, they intemperate it differently (as is shown by the blog and book "Cake Wrecks") Use the right tool for the right job (in the right way) it's really hard to express a design problem in programming terms and it is equally hard to do the inverse. The junction or rosetta stone of the design and development worlds is a story map. Agile development methodology (such as linear backlogs) and other construction techniques are great at a delivery tool, but not as good for design. It's advised to build one feature at a time, but not design in the same way. When to use story mapping product definition and planning (start) while designing - convert the story map into scenarios - convert scenarios into storyboards - convert storyboards into wireframes - convert wireframes into prototypes while developing - convert story map into backlogs - convert backlogs into sprints U S E R S TO RY M A P P I N G U S E R S TO RY M A P P I N G U S E R S TO RY M A P P I N G D e s i g n e d a n d Wr i t t e n B y M o G o l t z ( S h l o m o ) I n s p i re d B y J e ff P a t t o n U s e r S t o r y m a p p i n g g i v e s t e a m s a p l a c e t o t h i n k t h ro u g h s o l u t i o n s i n a c o m p re h e n s i v e a n d u s e r c e n t e re d w a y w h i l e d e v e l o p i n g s h a re d u n d e r s t a n d i n g a b o u t t h e p ro b l e m s p a c e . D E S C R I B E U S E R S User Activiites System Activities Research Needed Pain Point Idea User Tasks Sequence The X axis proceeds chronologically from left to right. The further right a card is, the later it occurs in a sequence of actions. Priority The higher on the Y axis, the higher a card is ranked on defined set of one or more criterion. Slices are horizontal groups of cards that represent related fucntionality that collectively, provide the smallest viable solution which produces value for users. A slice is created with successful for a specific business strategy, specific target customers / users. each slice should help you learn collection of slices could be a release externally or a milestone internally each slice has different themes of features you cn think of slices as version 1, version 2, etc. each release can be turned into a backlog R E F I N E T H E P R O C E S S How do you handle tasks that are repeated at multiple stages in the user's journey when is redundancy good or bad there are global actions that can usually take place at most parts of the journey, so how do we capture that repetition may be good for design but not for engineering (how do you rectify these different and sometimes conflicting needs) how do you capture / format scenarios that cross multiple features or products show link to another entire story map add card to describe outside systems inside the same map when is a story map too big don’t want to create a novel, we want to create a chapter should a map display an entire flow even if Activities (blue cards) can be as huge and detailed as the product themselves. perhaps instead of one big mega story map there are smaller related story maps. Almost like vertically slicing a story map and each slice how do you decide when to make a card with a very detailed description on the back with various parts, or determine thats too much…. when you break apart the details into their own cards could a slice be used as a scenario in addition to or instead of a release / mvp distinction how do you capture / visualise scenarios that skip taks entirely, and backtrack in an non- linear way (saved sets of yellow cards???) - story maps are always linear, but scenarios are linear only some of the time muitiple scanarios could show different journeys (this gets uber complex fast and confusing) Questions about storymapping. Answers still pending. Design When whiteboards and sticky notes cannot be used, there are many dedicated user story mapping tools. Engineering Project management and task board software is often used by product teams to keep track of features and user stories. User-Centered Design + Agile: A Link and Sync Design and Engineer software can sync with eachother bi-directionally so everyone on the team can work in a way that suits their discepline and way of thinking.