Your typical morning might start at the office. The scent of freshly brewed coffee (or tea) starts floating around. This is a typical morning for a lot of teams, but not for the ones slowly gathering in a creativity room.

User Story Mapping encompasses a full-on and complicated day, followed by weeks, or months of work by UX teams to make users happier. At Zalando, the backend team is also involved in this process. This is their chance to realise a full, common understanding of a product, get to know their users, and to get a feel of what’s going to come.

Recently, my team took on the challenge of enabling our Category Management team of more than 550 at Zalando to restructure and simplify their processes; to clearly define their responsibilities and easily change them (if necessary), all while providing a consistent solution and aligning dependent systems.

There’s a lot of details to consider – let’s take a look.

From a product perspective

Get a good impression of your user There is a problem you need to solve. And there are people that are struggling with this issue during their daily work. Draft the personas of your possible users. It’s even better if you get a chance to talk to them. Who are they? What are they trying to achieve? Why are they having this problem? Are their problems connected?

Question the map You will miss the details. Maybe not exactly you, but at least someone from your team. Usually some things are just taken as assumptions, but it doesn’t mean you’ve understood the process. If there’s even the smallest detail that’s not clear, question it. Don’t be afraid to, either: This is the best time to build a shared understanding.

Question everything Since you don’t work as your users do everyday, you need to understand them exceptionally well. Question every term that may have more than one definition to you. Question every word they’re using that you’re not familiar with. Question the way they work. This will not only help you understand more, but also for users to understand that something they’re doing is obsolete and can be skipped or delegated.

From a system perspective

Think in terms of the big picture A User Story Map is sliced into different milestones (or releases). Though an MVP may be a relatively small part of the whole product, at the time you see the map, you should be able to understand the overall picture. This brings us to our next point.

Think in terms of a system You should also consider the ecosystem that the product will be integrated into. In a world of microservices, integration itself has become much easier, but there’s still a lot of challenges to solve. You will need to obtain the data the user needs from somewhere. Sometimes you will need to pass these changes on to other services. How will they interact? You might say it’s too early to consider these points, but as soon as you do, you will notice gaps in your understanding that have to be filled.

Within such a system, there are a lot of dependencies. Need convincing?

Treat dependent systems just like users There are other stakeholders to consider. They will not use your product as directly mentioned. Instead, they are going to need the data you have. Has your user created an order? Great, they will take it and process it further.

As it turns out, you need to speak to them while doing User Story Mapping just like you speak with your users. What are their preferred methods of transfer? What are their performance needs? What exactly do you need to transfer?

It is the User Story Mapping where you define the foundation you’re going to work from. Understanding their needs and your possibilities is essential to having a smooth future process. Create user stories together.

From a team perspective

Think about costs There’s always more you can build than what you have resources for.

There’s also the case of technology you want to try out, but doesn’t really fit into the bigger story. Additionally, you’ll need to spend a reasonable amount of time learning about it to be effective using it. These are just a few examples that can disrupt a project if you don’t analyse the value and effort to build it up.

And of course, no matter how hard you try, at no stage will 100% of your possible users be satisfied. Therefore:

Focus Focus on the main user group. Find the sweet spot where minimal functionality delivers maximum value. This user group will benefit the most from what you’ve done and change the way they work.

Share the knowledge To stay on top with the recent developments, share knowledge across your team. With all your different experiences, you may have a brittled understanding of the business domain. To be able to work together effectively, make sure you’re all on the same page.

Would you use it? The ultimate question. What is the way you want to present it to the world? The speed of reaction, the processing speed, the data load. If you were presented with this tool, would you be happy? Would it be easy for you to adapt to the changes? Are these changes natural?

Conclusion

The perspective of User Story Mapping from the backend is something that might not be readily addressed, but it’s important to highlight the questions we’re asking to gain a better understanding overall. Knowing your users and understanding their needs enables you to build better software, in all measures.

Some teams might not be considering all of the above points, or might want to share their own ideas, so we’re happy to hear feedback. You can contact me on Twitter @sovereign_36 or via email to share your thoughts.