A design-first approach to writing great user stories

Imagine a movie just came out based on your favorite book. Now imagine the main character looks nothing like what you pictured them when you were reading the book. Disappointed?

Words are powerful tools, but they are abstract. And therefore, harder to agree on. Take this phrase for example: “As a user, I want to see a list of To Do tasks for the day and be able to later add new tasks in a section named Unplanned tasks”. This might sound straightforward when you first read it, but once you start digging deeper, you realize it leaves a lot to the imagination. And that's one thing you don't want to do when you are building software products.

What we`ve found working with businesses and product owners throughout the years is that good user stories emerge naturally from well-thought-out design, rather than the other way around. Most approaches treat user stories as a requirements gathering tool, requirements which are then shipped to the UI/UX design department once everyone is happy with them. However, this relies on several false assumptions: 

• people can imagine how something works just by reading
• people can agree on what each person individually imagined just through reading
• people can make informed decisions based solely on abstract requirements  

This is why, in our design-first approach, we make the process of gathering, clarifying and prioritizing requirements as visual as possible. We create high-fidelity mock-ups right from the start and iterate on those designs based on feedback and in-depth discussions with product owners, clients and everyone involved in the product discovery process. 

Once everyone has agreed on the designs, we start writing user stories, which expand upon, explain and provide richer context for the screens. This is by no means a linear process. Most times we move back and forth between designs and user stories, but, since everyone already has a good visual reference of the app, this makes everything a lot easier.

There are also other advantages to this design-first approach:

• It allows us to tackle aesthetics and functionality and the same time and to make important decisions early on
• It makes it easier for everyone to be on the same page and to literally see what they are agreeing on
• It gives everyone involved an accurate representation of how the end product will look and behave, since we are working directly with high-fidelity mock-ups

And the biggest advantage of all? It makes writing good user stories a lot easier. Because, it plays on their strength, not their weakness. Rather than expecting user stories to help people imagine things, we use them as a tool to clarify things. 

In this three-part article series, we'll be looking in-depth at how to write good user stories based on a design-first approach:  

1.) How to use UI/UX as a tool to discuss, clarify and agree on app requirements. The first article tackles design and how to approach design work in order to make it easily translatable into user stories.

2.) Turning your UI/UX designs into user stories. The second article discusses at length how to write good user stories based on a real application example: the back office of a tech recruitment platform.

3.) How to estimate user stories for improved planning. The third article deals with presenting the user stories to the development team and using them as a tool to estimate tasks.   

If you liked this article subscribe and get an email when we publish new, juicy stuff. We hate spammers, so we don’t spam.