It’s easy to imagine software development as a dark art - a solitary engineer writing lines of beautifully complex code (insert scene from The Matrix), that eventually transforms into a website or mobile app as if by magic. Whilst this may not be too far from the truth, there’s a lot that needs to happen before a team can start thinking about development in earnest and it mostly boils down to these core questions:
1. What are we building?
2. Why are we building it?
3. Who are we building it for?
You’d be forgiven for thinking that the software development lifecycle is an entirely logical and practical flow, but creativity inspires innovation and our product owners will often challenge ideas to ensure everyone in the team (our customers included) are providing not only the best solution, but the correct one.
The discovery phase
Our first phase in the digital product development life-cycle is “discovery”, which essentially means we’re trying to understand the answers to those three core questions. It’s perhaps the most difficult phase and tricky to pitch right, so the Product team have been experimenting with different techniques to engage with customers and elicit the right level of information needed for everyone.
What is user story mapping?
A technique best documented by Jeff Patton, user story mapping is a collaborative process that encourages stakeholders to visualise a specific user journey.
We consider each “task” a user would take as they navigate through the product and write a heading to represent it on the map (referred to as User Story).
Organising each User Story from left to right, we can then map the narrative flow of a user journey in a way that makes sense to everyone.
Focusing on task outcomes (or “Goals”); instead of emphasising specific features, helps to keep the team on track and ensures we’re prioritising the right functionality - what does the user need and why?
It’s a simple concept that requires nothing more than a few post-it-notes and some healthy debate.
What are the benefits to user story mapping?
Visualising features in this way, allows us to spot holes in the narrative much earlier, saving precious development time later in the project.
It also removes any bias that certain team members may be holding onto (even subconsciously), as each task requires some explanation and agreement.
It’s normal for stories to move around the map a lot at first, especially as new ideas and priorities are thought of; this just means that all eventualities are being considered and documented appropriately.
The process is intended to be engaging and can elicit additional information that may not have been captured in a traditional question and response meeting scenario.
The result of the session should mean that everyone has the same clear understanding of the product vision and priorities, ready to be documented and shared to the rest of the development team.
If you're interested in reading more on the concept and seeing more user story mapping examples, I'd highly recommend reading Jeff Patton & associates work.
Looking for an expert development partner to help deliver on your product vision? Get in touch, we'd be happy to help.
