Recommended
More Related Content
Similar to Aligning Organizational Stakeholders with User Story Mapping
Similar to Aligning Organizational Stakeholders with User Story Mapping (20)
More from UXDXConf
More from UXDXConf (20)
Recently uploaded
Recently uploaded (20)
Aligning Organizational Stakeholders with User Story Mapping
- 1. Story mapping Tell better stories about your products @TobiasHJensen
- 2. Hi! I’m Tobias I use design thinking to solve complex problems and create valuable experiences. tobias.jensen@blackboardinsurance.com www.tobiasholm.com Product Designer in NewYork City
- 3. We’re Blackboard A tech-forward insurance start-up reimagining an archaic industry with a customer-, value-, and data- centric approach.
- 4. Story mapping Tell better stories about your products What? Why? How?
- 6. Building software often feels like playing the telephone game
- 8. As a __________ I want to __________ so I can __________ Who What Why
- 9. I want to filter users by their job title so I can filter users by their job title As an admin
- 10. As a ___ I want to ___ so I can___ As a ___ I want to ___ so I can___ As a ___ I want to ___ so I can___ As a ___ I want to ___ so I can___ As a ___ I want to ___ so I can___ As a ___ I want to ___ so I can___ As a ___ I want to ___ so I can___ As a ___ I want to ___ so I can___ As a ___ I want to ___ so I can___ As a ___ I want to ___ so I can___ As a ___ I want to ___ so I can___ As a ___ I want to ___ so I can___ SPRINT 1 SPRINT 2 SPRINT 3 NEVER?! As a ___ I want to ___ so I can___
- 11. “The real value of stories isn’t what’s written down on the card. It comes from what we learn when we tell the story.” — Jeff Patton
- 17. Story mapping benefits — Communication — Prioritization — Outcome thinking — Proactiveness
- 18. Use at every step — Research Source: UXDX
- 19. Use at every step — Research — Hypothesis Source: UXDX
- 20. Use at every step — Research — Hypothesis — Prototyping Source: UXDX
- 21. Use at every step — Research — Hypothesis — Prototyping Source: UXDX — Build, test, release
- 22. Workshops (remote) Development process Easy Agile for JIRA Workshops (co-located) Pens and Post-its Mural.co
- 23. How to: user story mapping workshop Find it on Medium!
- 24. “Teams must build a shared understanding and focus on outcomes — rather than what to build — for their users” Jeff Patton
- 25. Key takeaways — Don’t expect people to fully understand your written documents — Collaborate early to achieve shared understanding — Start telling stories – don’t just write them — Flat backlogs don’t show the big picture
Editor's Notes
- Hi! Thanks Anna and UXDX It is important to better tell stories about our products Bridging the gap between UX and development. Who here knows of Story Mapping? Who has used it?
- Use design thinking to solve complex problems and create experiences. Product Designer From Copenhagen - lived in New York City for two years but from Denmark. Degrees from IT-University of Copenhagen Obsessed with handling complex domains Currently work at an insurance company.
- We work hard to reimagine the current way insurance works. New look at insurance - how can insurance be a good experience? Historically boring and tedious No trust Asymmetry My mission is to figure out how design can change insurance for the better.
- Why story mapping is important What it actually is How to use it in your organization. I’ll try to leave time for questions at the end as well.
- Has anyone seen this video before? Telephone game - explain Usually super wrong and hilarious Explain video Big difference between what was first and last enacted So.. Why am I showing you this? This is all fun and games - but…
- Feels like playing telephone game Instead of doing it for fun, we just switch this out with written documents – passed on to others And this can go on and on until the original idea is completely lost. We write down requirements and then we expect everyone to look at these documents and understand them the same way we do. But what actually happens is this …
- When I read something, I will most likely understand it differently. No shared understanding of what they’re actually looking at, so they use their own judgment. Point: we should never expect people to read documents and understand them the way that we do ourselves. Just because you share a document with someone else, it doesn’t mean that it leads to a shared understanding of that document.
- These documents (if agile) will look like this. Standard format for a user story Goes: As a (persona), I want to (do something) so I can (accomplish something). Features from users’ point of view. By doing this, the users and their motivations are always considered. However, we most often end up with this…
- Very informative right? Extreme example, but… reality. Seen this before? If we don’t put this story in context, we won’t know why it is important to filter by job title.
- Take these small documents and we start putting them in an agile workflow. Lost desired outcomes of the stories, we have also lost the bigger picture. What are we trying to accomplish? What should the system do for the user? Why in this particular order? How do things relate or fit together? Are we building the right thing? Isolated chunks of work To do list - or an assembly line It is clear that there is no holistic narrative The vision got shredded a part, then the features are prioritized and then we expect to be able to build a a wholesome, holistic product. No clear vision Makes sense to people who write them, but how could we expect others to understand the bigger picture?
- Jeff Patton says … Stories are tools for communicating better about features and not a different way to write down requirements. Stories don’t become stories before they’re told. If you just keep the stories in writing, they aren’t stories.
- We want to get to this point We want to be able to see things from the same perspective and have conversations Shared understanding is when we both understand what the other person is imagining and why. Maybe the solution is not to try to be better at writing stories, maybe the solution is to start telling them.
- This why this book has become so popular Jeff Patton talks about these challenges Introduced in 2014, but has been around for longer. If you haven’t read it!
- He talks about story maps Fosters conversation and creativity with the user’s journey at the center. Example: going to a conference to speak - you take a big story and break it down Being able to take really big ideas, and then break them into smaller ideas. Take time to explain our thoughts with words and pictures, we build a shared understanding of our users. Building a shared mental model.
- So let’s look at the basic anatomy of a story map It will ALWAYS be created with users/customers/personas with a goal in mind Goals are reached by completing activities. To complete an activity, users needs to perform tasks. And these tasks can be transformed into user stories for software development. The we slice up the map into releases
- Viability is defined by the outcomes we get (not the outputs to get there). Not viable in terms of it being a wholesome successful product Not viable to think “what is the crappiest thing we can build to get out there” Viable from what you need to be able to validate an assumption about your product. Chunks of value But Minimum and viable are both subjective – get shared understanding if all knows what we want to accomplish Break down product ideas into parts Formulate hypotheses about what your product needs to do for your users.
- Prioritization It’s about slicing features and defining road maps for products A visual roadmap to communicate both the planned work and the work that remains. Planning releases Communication A shared language about people and their jobs to get done A framework for conversation Keeps the context of the user’s journey Outcome thinking Outcomes over output Customer outcomes are in focus Iterative (always WIP) Proactiveness Used for designing proactively Instead of reacting to problems
- Can be used in many phases of a project. Initial product vision/discovery workshop Restructure a backlog that has lost focus Internal team activity for alignment Research Before research starts – what would be valuable to research. See knowledge gaps are and what you need to research. Connect your research findings with the story map If you want to do you favor, structure your research phase from a jobs to be done perspective. This will help you understand what jobs (in each phase of the journey), the user wants to get done.
- Hypothesis Formulate hypotheses about your users. Where in the user journey you’re most unclear about what your users What is the product hypothesis you want to validate? (Lean UX)
- Prototyping Having a user story map is super useful in a design process. Understand the journey I’m designing for. What MVP could be designed and tested even before development starts.
- Build, test, release Use it for the different agile ceremonies Grooming to realign everyone on the “why” while discussing features Good for release planning and road maps. Measure using the story map (did we meet the goals of the MVP?)
- Tools to get started Pens and sticky notes - preferred Miro.com - good for remote EA - story map in JIRA which is awesome
- Specific guidelines for doing a workshop
- This quote from Jeff sums it up really well This is the essence of what user story mapping does – it creates a sheared understanding of outcomes for their users.
- Don’t expect people to understand your written documents Flat backlogs don’t show the bigger picture Tell stories, don’t just write them - Stories are not requirements – they facilitate conversation Collaborate to achieve shared understanding