User story mapping
In my last post I wrote about finding the place for UX in an agile environment. In particular, I talked about the challenges of creating a shared understanding of product design and user behaviour. The agile method, as I’ve discussed before, usually means developers work from singular user stories which on their own, communicate little context. The developer may find him or herself creating a software application without a sound understanding of who will use and it and why. Whilst agile maintains that just ‘getting it made’ and improving it later is good enough, the UX team and product owner may have knowledge and ideas that would help the developer create something better and more cohesive on the first attempt. How then, can we help our developers whilst avoiding waterfall artefacts like spec documents and detailed UI designs?
Although DNV GL adopted agile methods some time ago, we are still learning what works best for us, experimenting and refining our process as we go. One of our teams, faced regularly with the problem above, has been trying out story mapping as a means of giving the team the broader context they need, and with considerable success. Previously the team would write user stories and simply put them in a ‘backlog’ list, highest priority at the top. It worked ok, but it sometimes left developers in the dark about what was really needed and led to products that just weren’t quite on target.
There is plenty freely available online about story mapping as a technique, so I will skim over that here. Devised by an insightful man named Jeff Patton, it is a means of mapping out the scope and requirements of a product as a big collection of user stories, typically scribbled on to post-its or cards and stuck on the wall. From left to right, the user stories set out the tasks and goals a person needs to accomplish, where possible in a rough order from start to finish. If I were designing a banking app, these might describe accessing my account, checking the balance, making a transfer, and logging out safely, for example.
The top row will describe the overall parts of the process, then below each part we break the task up into smaller and smaller component pieces, until each user story is a small, manageable piece of work that a developer can take on. The key thing is firstly wording these stories correctly – they always describe the task to be performed, never the execution. So, they should say ‘access my account’ rather than ‘type my password.’ This way, the team is free to innovate with the user in mind, rather than working from a prescriptive spec.
With a complete story map, developers can see where their user story fits in the bigger picture. They can move upwards to see the overall task their story contributes to achieving, and go left and right to see what happens before, after and what is related. This means a better understanding of context and crucially of the person we’re building the product for.
At DNV GL, we build the map the most efficient way, by having users, UX designers, product owners and developers all discuss it together, and map it in a no fuss, low tech way with post-its. We also built a digital equivalent that is linked to the developers’ backlog – that way, it’s easy for anyone to reference it at any time and for work items to be formally tracked. The creation and thinking though, mostly happens at the wall.
Populating a map for an entire product is a big task, and the process of building it forces us to be candid about what we know. If there is a gap in our understanding, it will become obvious and we will need to conduct research or collaborate with users to fill the gaps. If a feature has been requested for the product, we cannot place it in the story map without knowing the user task it will help achieve. The most progress on product design happens when this multi-disciplinary team get together and have a candid discussion about what we’re making and why. A complete map is very large and takes days to build, but it has a huge impact in terms of reducing risk and improving product design.
Months ago, I was writing notes and creating small pieces of story map as a result of my research work, but struggling to provide developers with this information in a practical format. The main story map is a natural home for this information, as my findings can be digested and incorporated quite easily. My work is disseminated into the map rather than becoming an additional document for people to lose.
What then of the wireframes? Well, the map is proving very useful, but we still have to discuss design strategy and details. In many cases the wireframes have already been tested through user research studies and iterated several times by the UX team before sprints begin. Since the story map helps people get a view of the big picture, we felt we needed the same for the design and have begun printing out every screen of the wireframe, sticking the pages on the wall next to the story map. As you might guess, there’s precious little wall space left these days! Nevertheless, the story map and wireframe prints together, help the entire team to see other’s work progress, understand the big picture and how their contribution fits into a cohesive whole. The impact on both our product and the feeling in the team is overwhelmingly positive.