User Story Mapping for Minimum Lovable Products
•Als PPT, PDF herunterladen•
3 gefällt mir•593 views
I gave this presentation at the UX Agile Summit, 2017. If you have ever sat there staring at your screen or a white board, wondering where to start. If you've ever wondered how you could possibly organize all these user stories into some kind of well-organized plan for iteratively releasing your product, this talk is for you! In this talk, I will share a way you can generate user stories, organize your backlog, and plan out releases in a way that will ensure that the product is not just minimally viable, but minamally lovable.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie User Story Mapping for Minimum Lovable Products
Ähnlich wie User Story Mapping for Minimum Lovable Products (20)
Mehr von Kelley Howell
Mehr von Kelley Howell (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
User Story Mapping for Minimum Lovable Products
- 1. User Story Mapping for Minimum Lovable Products Kelley Howell UX Architect June 15, 2017
- 2. Kelley Howell UI engineering, UX, research, kelleychowell kelley_walker uxkell@gmail Kelley Howell UI engineering, UX, research, kelleychowell kelley_walker uxkell@gmail
- 3. My goal Share with you a technique for creating and organizing a backlog that focuses on the needs and goals of your users.
- 5. 5 Jeff Patton’s User Story Mapping http://jpattonassociates.com/ http://jpattonassociates.com/
- 6. 6 What’s on tap today 1. What’s so great about user story mapping? 2. Understand the user story 3. Write good user stories 4. Understand the relationship between goals, activities, tasks, and tools 5. The user story mapping process
- 7. 7 Why user story mapping? 1. Part of a user-centered design process 2. Visual way to show how people use your product and what they value most about it 3. Visual representation of your product to help with - Analyzing requirements - Planning out iterative releases - Organizing the development process
- 9. 9 The Agile Samurai by Jonathan Rasmusson The Agile Samurai by Jonathan Rasmusson From Jonathan Rasumussen, The Agile Samurai
- 10. 10 Purpose of a user story planning item token for a longer conversation method for deferring a longer conversation represents user needs and identifies user goals Focuses team on solving users’ problems
- 11. 11 User stories are also boundary objects build solidarity by bridging pro- fessional and disciplinary boundaries allow collaboration and even without clear consensus
- 12. 12 1. Title - often a verb phrase 2. Description As a [type of user] I want to [perform some task] so that I can [reach some goal] 3. Criteria for user acceptance 4. Add sketches & notes, specifications, wireframes, mocks A good user story
- 13. 13 Do user stories replace requirements? Tom Hilton @ flickr.com/photos/tomhilton/
- 14. 14 Do not replace requirements User stories are tokens for longer, deeper conversations about what users need Those conversations are memorialized with artifacts Artifacts include what we think of as “traditional” requirements: spreadsheets, flow diagrams, wireframes, mocks, scenarios use cases, pseudo code, storyboards, and more
- 15. 15 This process helps us avoid this:
- 16. 16 But as well all know…. Credit: Axosoft Scrum Software Not even team alignment or well-written user stories are enough to tackle prioritization and release planning, especially on large, complicated products
- 17. 17 How do we get from this --
- 18. 18 to a relatively orderly visualization?
- 19. 19 How do we prioritize?
- 20. 20 With user story mapping 20 Sketch concept inspired by Jeff Patton
- 21. 21 A method for analyzing and prioritizing a backlog that reflects the order in which people complete activities and in terms of the value those tasks bring to the users. What is user story mapping?
- 22. 22 center users’ perspectives in our discussions prioritize in terms of user goals shows relationships between different users and their work flows confirm completeness of a product backlog work as a team Benefits of user story mapping
- 23. 2323 Exercise
- 24. 24 1. Brainstorm: as individuals write down all the steps you take to accomplish your goal, organize in a timeline 2. Reconvene: reconvene as a group and merge your timelines 3. Identify Patterns: look for similarities and affinities, grouping them together in clusters. Apply labels to the clusters of similar tasks. Remove duplicates. Instructions for workshop activity
- 25. 25 4. Order by time: The major clusters are activities. The team should order them left to right in order people will do them 5. Decompose tasks: Under each activity, list from top to bottom the tasks people perform under each activity. Order them according to how important or valuable they are to the process. Example Activity: Showering. Can that activity be done without shampooing hair? Without conditioning? Without loofah salt scrub routine? Shaving legs? Etc. Instructions for workshop activity
- 26. 26 6. Break out paths: When you notice major difference in types of users and their tasks, physically separate those tasks as different paths Question: Which paths are more important? How do we know? Instructions for workshop activity
- 27. 27 Getting to work – 2 paths
- 28. 28 What is a user story?Thinking at the task level
- 29. 29 I want soup for lunch
- 30. 1. Goal: what I want to achieve or how I want to feel 2. Activities and tasks: What I do to achieve the goal 3. Tools: what I use to perform tasks 30 Goals - Activities - Tasks - Tools Goals Activities Tools (apps, sites, software) Tasks
- 31. Thinking at the task level 31 From: Alistair Cockburn: Writing Effective Use Cases Task / Functional - “Sea level” Can complete at one sitting Sub-Functional - “Fish level” Tasks that, alone, don’t achieve a meaningful goal Activity -- “Kite level” Longer term goals often with no precise ending. Too abstract Too detailed
- 32. Task: “Read an email message” Activity: “Manage email” Goal: Get information about my job, my team, and company in order to earn my salary Task: “Pull monthly analytics data” Activity: “Write monthly report” Goal: Convince management team to take some action 32 Goals Activities Tools (apps, sites, software) Tasks Goals - Activities - Tasks - Tools
- 33. 33 Team refines and tests for completeness Gary Levitt, owner & designer of Mad Mimi The user story mapping process
- 34. 34 Know your users (lean UX personas)
- 35. 35 Sally – changing things up Sally has been an agent for about 10 years. She’s used to doing things the old-fashioned way: holding open houses, advertising, working her network. But now she wants to branch out and learn how to use the Web. She’s been using email and online applications for awhile. But she’s been lackadaisical about it. She wants to change up her routine, and make sure her business doesn’t stagnate because she’s not keeping up….
- 36. 36 Trevor – eager entrepreneur Trevor is a new agent. He just got his license and he’s really eager and enthusiastic. Trevor is 37 and just turned to real estate after a couple different careers. Trevor is really ambitious and has aspirations to run his own brokerage one day. He knows that putting in a big effort now will mean the difference between success and failure. Trevor is constantly looking for more information about how to run his business….
- 37. Storyboards: can be used for the major activities to capture major moments in the narrative. Scenarios: tell more details stories about the various tasks users do. Plot points: include these to reflect decision points were a user might take a different path Consider Sally: She often got too busy to go back to use the product, to see what it could do. 37 Narrative Flow: stories about users
- 38. … Sally remembers she had seen an email offer for a free trial. She doesn’t think she can find the email, instead she looks for the trial offer at Homes.com. She sees an advertisement for it, clicks it, and signs up using the form. Then she takes a break to make lunch. When she returns, she sees that she’s received email confirming the sign up. In the email, she clicks the link that will take her to her account. Then, she is taken to the sign in page. However, she’s forgotten which password she used, so she uses the “forgot password” reminder to get a new password. When she’s logged into her account, she sees that she can import all her existing listings … 38 Meet Sally
- 39. 39 Now that you’ve fleshed out the major narrative flow, arrange the major activities by working from left to right Tell the story from the user perspective, working in the order that your user would perform the activities time Order activities: narrative flow Major Activities Discover product Onboard Manage Listings
- 40. Break down activities into tasks that comprise the activity Don’t get hung up on order or being perfect: goal is to get it out there Tweak later 40 time Decompose activities into tasks Discover Onboard Manage Listings Via email advert Sign up for account Add new listing
- 41. Vertical axis represents necessity Arrange tasks according to how important they are to the activity the user is doing 41 Add in necessity time necessity Discover Onboard Manage Listing Email advert Analyze Listings Edit Listing Search Listings Sort Listings Sign up for account Add new listing Search engine Search marketing CTA on site
- 42. 42 Below each activity are the child stories that comprise the activity Task flow and task decomposition time necessity
- 43. 43 1. Thens / and thens: signal horizontal movement 2. Or: signals vertical movement 3. Vertical overlap: when tasks happening around same time ands, thens, ors, and mores time necessity
- 44. Record details so they’re not lost Tuck under existing task cards 44 time Sub-Functional or “Fish level” Tasks that, alone, don’t achieve a meaningful goal What if you hit “fish level”? necessity
- 45. 45 Look for alternatives What else might users do that didn’t come up in your scenarios? Look for exceptions What could go wrong, and what would the user have to do to recover? How would our product prevent the problem in the first place. How would we help them recover. Consider other users What might other types of users do to reach their goals? Might be: people, robots, search engines, other systems Use workshops to fill in the gaps
- 46. 46 Verify with your users
- 48. 48 The user story mapping process 1. Write stories about how people use the product 2. Identify the activities that form backbone of your story map and organize in the order they are performed 3. Flesh out the tasks people do to accomplish those activities, ordering them by how necessary they are to the activity 4. Be sure to explore alternative users, tasks, activity flows and add in their paths and narratives 5. Slice out tasks according to how they help users achieve specific outcomes
- 49. 49 Jeff Patton’s User Story Mapping http://jpattonassociates.com/ http://jpattonassociates.com/
- 50. 50 the end! Thoughts? Questions? Thank you! uxkell@gmail.com kelleychowell @kelley_walker
Hinweis der Redaktion
- Welcome! I hope all the presentations have been awesome today. I’m glad you’re here because I want to share a technique I love to use: User Story Mapping for Minimum Lovable Products.
- I’m drawing on Henrik Kniberg’s illustration, that many people have passed around. It’s a great illustration of how planning releases for minimally viable products can be a bad deal for users. It also helps us see the difference between incremental releases, the bottom half of the illustration, and how iterative releases should work. Now, this is a metaphor, so it’s limited, as all metaphors are. The point Kniberg is trying to convey is that with iterative releases, you should be planning out the MVP to give value to the users. There’s little value to a user if you just build a wheel. Sure, it’s a component. It is “complete” in that sense. You can even so something with it: put it on the ground and push it and it will roll.But if the user wants a vehicle so she can move faster than walking pace, the wheel will do her little good. The skateboard, on the other hand, can actually be used for something. If she wants to get to work, she can get to work on a skateboard. And I know people who do travel to work on a skateboard. Most people won’t be happy about having to use a skateboard for awhile while they wait for the car. But, they won’t be furiously angry about it, either. They will also be able to see the value, the future value, better when viewing a skateboard than, perhaps, a wheel.
- I’m drawing on the work of Jeff Patton, a huge inspiration. I came across his work in 2012 and have been promoting it ever since. My goal here is to whet your appetite for more, so I strongly encourage you to go visit Patton’s site, read his articles, view his presentations. He just came out with a book, as well. It’s good stuff, especially for product managers. I’m going to be speaking from the position of UX practitioners about the value of user story mapping to our role.Patton didn’t invent the process. As he always points out: we know this stuff already. He also points out that a lot of these ideas were “in the air” during the mid- to late- 2000s. What Patton did was tie them together brilliantly, making sense of the technique as it ties in with Agile practice, which was really taking off during that time. You can find Patton’s user story mapping resources, here:http://jpattonassociates.com/user-story-mapping/
- Once you adopt user story mapping, I think you’ll agree that user story mapping Can be a part of your user centered design process That is a fantastica way to visually show how people use your product and what they value most about it Is a visual representation of the product that can help you and your team do the following: Analyze requirements Plan out iterative releases Organize the development process
- Before we talk about how to map user stories for your product, let’s talk about user stories. User stories are the foundation of the user story mapping process, so it’s important to understand the purposes and structure of a good user story.
- When people first learned about user stories, they sometimes reacted like this, the way Rasmussen portrays the character in his illustration. They wanted the user story card to contain all the traditional requirements they had been creating under different software development methodologies. They couldn’t imagine all these requirements would all fit on the card. But I think this was because we misunderstood the user story – that it has several purposes. When it’s written, the user story, is the beginning of a process we set in motion, not the culmination.
- Here’s what I mean.User stories have several purposes and, as such, they help use understand not only why all the requirements don’t fit on the story card, because it isn’t intended to hold all that information. Instead, the user story has several purposes: it’s a planning item It’s a token for a longer conversation It’s a method for deferring that longer conversation. We’ve all done this, right? We know we need some capability, some feature. But it is something we can’t build just now. The user story thus becomes a kind of reminder or promise to get together, as a team, to talk about it later. It represents user needs and identifies user goals. It is, in short, a way to remind us that we’re building products for people and we should do so with users needs and goals at the forefront of the development process Thus, user stories focus teams on solving user problems and helping them achieve their goals
- Jeff also reminds us that user stories have emerged because they resolve a less obvious but nonetheless important problem: bridging the gap between people who come from different disciplinary and professional backgrounds. On cross- functional teams, we all speak different languages. I’m sure all of you have experienced this, w hen the graphic designers describes something as a drop down, and the backend developer calls it a combo box. My favorite example is working on a tax preparation platform. People were referring to “little circles” on the screen. It was a head scratcher. As it turned out, that was what the tax accountants, consultants on the content in the app, were calling radio buttons. User stories serve as boundary objects that build solidarity because they work as a bridge between people with different languages. User stories allow us to collaborate even without clear consensus on the team. I’ll talk a little bit more about this later so you can see what I mean.
- So, now that we understand the purpose of a user story, we can take a look at its basic components User stories are composed of the following: The title – usually a verb phrase The essential core of the user story is the description which is identifies the type of users, the task she is trying to perform and the goals she’s trying to achieve by performing the task. This essential core of the user story has this format: As a [type of user] I want to [perform some task] So that I can [reach some goal] 3. we should also include user acceptance criteria 4. we also add sketches and notes, specification, wireframes, flow diagrams, mocks, and more
- User stories – the information contained on a 3 by 5 inch card or sticky note -- is not, therefore, a substitute for requirements. We’ll still generate requirements. However, we generate requirements because we use them to memorialize the conversations we’re having. User stories are a recognition that the generation of requirements is a team effort, that it’s grounded in conversations about what we are building together.
- Initially your notes or sketches are like tokens to help you remember all the details you were thinking about when you first wrote a user story.For example, if your user story goes something like this, “As someone looking for a new car, I want to be able to search online for a car so that I can find one near where I live.”As well all know, there’s a lot involved in that user story. So much more than those few words can convey. As you write those words, you might be thinking about search by ZIP Code (if you are in the US), searching by using a map, searching within a distance radius, searching within a city, and so forth. And that’s just to name the most obvious details that crossed your mind. So, since you can’t capture it all in the moment, you write the user story and then you write up some quick notes about all those different ways of searching by location. And then maybe you include a rough sketch. You use these to jog your memory later.Similarly, as we continue to have conversations with the team, we realize that we have to memorialize the conversation. As we come to an agreement, we need to illustrate what the agreement it. We need to document it. Thus, we generate more artefacts – the kinds of artefacts we typically associate with requirements: wireframes, specifications, task flows, diagrams, mocks, storyboards, and more.The difference with the Agile approach is that we generate these artefacts just-in-time – and not “just-in-case”. In the days of the waterfall method, when we did Big Design Up Front (BDUF), we generated requirements for every possible circumstance, for every possible user, for every possible scenario, for every happy and default path we could imagine. IT was all done “just in case” we needed to build for those people and situations – even edge and corner cases were considered. It was quite thorough!Moreover, the artefacts are not just a way to memorialize the results of a conversation – the agreement a team has come to. They are also a way to make sure we are in agreement. “This is what I think we just agreed on in this meeting? Did I get it right?” So, you might be an artefact out there only to discover that the team doesn’t quite see I t that way. You may need to make adjustments. As you know if you’ve done this for a while, sometimes we don’t know what we want or what we saying until it’s out there, outside of our words, and outside of our intellects. Artefacts produced this way are what Jared Spool calls “alignment documents”
- But not, that although the business stakeholder isn’t happy about a horse you can’t ride, the business analysts gathering requirements is not wrong. People do have horses that they do not ride. You might want a horse to draw a carriage or wagon. You might want to own a race horse, in which case a jockey might ride the horse, not the person who owns it. Or, you might want a horse for harness racing.
- product backlog + sprint backlog
- In short, building a backlog as a story map is a discussion about users experience, not a discussion about user stories
- Ordinarily, I run this presentation as a workshop, a prelude to perform the actual user story mapping for a product the team is working on. However, since workshops don’t really work with this format, I will include the instructions here so you can try this when you get back to your office and have time with your team.
- Ideally, work on building out the tasks and activities for something that’s not work-related. This helps to keep focused on a neutral topic no one’s invested in. One great approach is to talk about how we accomplish the goal we all usually have: Getting to work every day. You can also use an activity like “eating lunch” Work in a group or groups of 3 – 5 ppl. As individuals, write out the steps you take to accomplish your goal: getting to work, making dinner, etc. Arrange your notes according to the order in which you accomplish the tasks Reconvene and, as a group, compare and contrast the different tasks you perform in order to get to work every morning. Working as a team, compare the steps each of you take. Cluster items that seem similar, getting rid of duplicates As you cluster similar tasks, give them a label. Arrange the major clusters on a team timeline according to order in which the cluster of tasks are done These cluster comprise the major activities you perform to accomplish the goal, “Get to work every morning”. These activities might be: wake up, bath, have breakfast, exercise, walk / feed pets, style hair, get dressed, drive to work With major activities in mind, break out the different tasks people do as part of that activity: “Have breakfast” might include make coffee, toast bagel, slice apple, eat meal / sip coffee, read newsfeed Notice differences among the types of people who share a goal – getting to work – and how their activities and tasks may change depending on who they are. People with pets and/or children may have more and different tasks than those who do not. Similarly, someone who gets exercises daily or who car pools or who uses a bike will have different activities and tasks, even though they are accomplishing the same goal. You’ll also notice that some people will have different paths that depending on decision points: a divorced parent who shared custody may have one set of activities and timeline when she has the children as compared to when she doesn’t. Someone who gets to work using different modes of transportation, will have different tasks and may even do the activities in different order.
- This exercise helps us see a few things: People naturally think at the task level. They have goals, but to achieve them people usually think about how to do so at the task level. User stories encourage us to think at the task level as well. “ As a certain type of users, I want to perform some task so that I can reach some goal.” It also shows how important it is to understand users and their goals. When their goals change or when they have several goals that are achieved in one activity, this can have an impact on how they perform activities and what tasks they do.
- Thinking about how activities are profoundly shaped by users’ goals helps us understand how those goals will change the tasks they perform to achieve the goal. It will also change the tools people use. Consider the other activity you might have done: track the steps you take to be sure you have lunch during your workday. The interesting part with this activity is also how it shows us how much we invest in eating meals. It’s something we do where have many more goals than simply taking nourishment. The tools I need to eat a can of soup include a can opener in once scenario, but not the other two. The tools I need to make my own soup from scratch include an array of kitchen implements, produce, pots and pans, spices, etc.The reasons I might have soup in a can for lunch might be that I want to have soup for lunch because it’s a quick, inexpensive, and fast meal. It’s important to me to be able to eat at the office, at my desk. It’s also important to be frugal, and to not waste time on food preparation.But what if a major goal for my lunch hour is also getting out of the building, getting some fresh air, and maybe walk. If I want to have soup for lunch, I might rather have soup at the deli. The tasks involved in getting soup for lunch so that I can also get out of the building and get a walk into may day are different than the things I do to have soup from a can.Both of these are still very different from the tasks I’d do if my goal is to eat whole foods that I purchase or grow and prepare myself. Many different activities would be involved – and many types of tools.
- User story mapping helps us think in terms of user goals and how people use the software and apps we build as tools to achieve their goals. They use our software as tools to accomplish tasks.
- Thinking in terms of tasks, Patton says, comes naturally to us. In thinking through this, Patton borrows from Alistair Cockburn’s book, Writing Effective Use Cases. Cockburn thinks that there is a natural “human size” for tasks. This is also where we can most effectively focus our thinking on the user. To convey this, Cockburn uses the metaphor “sea level” to understand when a task is human sized and when it is too large or too detailed.
- Consider the relationship between goals, activities + tasks and tools when we look at more conventional types of software or web apps we might build. Consider how the activities (and features) that might be part of an email client might be different depending on the user’s goals and the reasons she uses an email client. At work, email is for communication with our manager, the company, with our colleagues. Since communication can sometimes be difficult or limited on email – sometimes it’s easier to talk, rather than write -- we often gravitate toward face to face meetings, when possible. Thus, when using email, we often frequently also need to use a calendar to schedule meetings. This is why all work-based email systems tend to include a calendar feature. But consider how you might use email outside of work. How important is the calendar feature to your conversations with, say, family and friends? Answers will vary, but we can see how the stand alone email clients we used to build for personal use often didn’t include calendars.
- So, how does all of this related to user story mapping?To do user story mapping, you will want to write good users stories. You’ll want to focus on actions, and you’ll be looking at tasks that involve verb phrases. This is why it’s good to use verb phrases as a title for your user story. You’ll also want to get the essence of the user story right: include the user type, the task the user wants to do, and the reasons/goals she has for doing it.Understanding how your product is a tool that supports users in achieving goals – and performing tasks to get their – is a crucial part of building an excellent user story map.
- Once you get that down, you’ll want to focus on the kind of users you are designing for.Ideally, you will start with what we call personas, which have some grounding in actual research on your users. But if you do not have the luxury of this kind of research, use this as an opportunity to start with your educated guesses about users. When you do this, you’ll be borrowing from a technique in lean UX called proto-personas. (The best discussion on the topic is straight from the Lean UX guru himself, Jeff Gothelf: http://uxmag.com/articles/using-proto-personas-for-executive-alignment . If that piques your interest, you’ll also enjoy his book, Lean UX: Applying Lean Principles to Improve User Experience. The team gets together, drawing on as much research as you might have (marketing research, surveys, customer feedback logs, information from customer service reps and sales people). I use a brain writing technique to help us work through our rough guesses as to who the users are. You’ll want to think about the kinds of behaviors they engage in that are related to your product. You’ll also want to think about the different problems and concerns and needs they have. Is your product helping them solve those problems? Are they problems they have had with your product? Then, you’ll want to speculate about ways you might be able to solve their problems. How can your product help them? Is there something the marketing, training, or sales materials can help them with? Throw all these ideas out there. ( More about brainwriting: “Using Brainwriting for Rapid Idea Generation” at https://www.smashingmagazine.com/2013/12/using-brainwriting-for-rapid-idea-generation/ )You’ll start to see that you have holes in your knowledge about users. This will help the team come up with a research roadmap: the activities you need to do in order to answer those questions.Using this as a lean UX technique also means that you want to iterate on the personas you create. What that means is you want to find out if your team is right about the people who use your products. Are your educated guesses valid? Or do you need to change the personas based on new information. Just as in any agile methodology for software development, you are now iterating on the personas: you constantly improve them as you get more information.
- The excellent thing about user story maps that are physically placed on walls or white boards is that you can “walk the story map”. This helps you get out of the ordinary, helps you play the role of the users, and step through the process with your entire being – and not just your intellect as you observe some digital version of a story map. The other great thing is that, if you have access to people who will use the product, you can have them walk through the story map too. That way, you can find out if you got it right, and users can add more detail about their “narrative flow” and the paths they take. They’ll help you think through anything you have missed.Note: you can also do this in large organizations where you build highly interdependent products. Walk through the story map with reps from the systems architecture team, the database team, the API team, and so forth. They will help identify interdependencies in the story map, and maybe more of those unconventional users of your system.
- Group stories into releases based on coherence of features to user needs In the first release, support the necessary activities. Deliver additional support for user activities in future releases
- And that it, in a nutshell.
- I hope I’ve whetted your appetite for more information about how to do user story mapping. I encourage you to visit Jeff Patton’s site, take a look at his resources there, and buy his book. His book is great, especially if you feel you have a unique situation that my high-level talk couldn’t address. He covers a lot of different examples from many types of companies, so it’ll give you insights in how to adapt this process to your own work site. You’ll definitely also want to read it if you are a product manager or business analyst, Since Patton has done product management work, he is well-versed in the PM body of knowledge and can relate this to your experience. My focus here was on the advantages of user story mapping for the UX practitioner. (see http://jpattonassociates.com/resources/ for more resources)Thank you for coming to the talk! What are your thoughts? Comments? Questions? Any other good stuff I should know about?