How and why the personas must be the starting point of our user stories to build better products
This week I started a new project — CooLab. We need to create an application that helps cooks to reach more people with their receipts. They upload them on the platform, and people from all over the world can try them, in exchange for a restaurant that has limited tables.
Meet Ben. He’s my colleague and representing the development team today.
Ben has been working with Agile methodologies for a while, and he read a lot about it.
We are at the sprint planning this Monday, and the user stories looked like this: As a user, I want to be able to upload my new chocolate ice cream receipt in 1 hour so children can make it for Mother day. A straight forward user story, you might say. Ben can go and implement it. However, then Ben comes and asks:
Who’s the user?
A cook! Of course!
But what about the cook? Is he a cook or a restaurant manager or a mom who loves to cook? What do we need to know about him or her that will help us to build a product he or she will be delighted to use?
We often limit ourselves to “user” when defining the user stories. In the happy scenario, we use the role of the user — cook, marketing expert.
Treating the end users only at a role level only causes 2 two main issues:
- We spend a lot of time debating the features and technology behind them. How long do you spend in discussing features, how they should we implement them, technical design, low-level details? For example, debating whether to use one framework or another.
- We build products that aren’t used. There are a million ways of implementing a user story on how to implement the version that provides the highest business value to the user without knowing who the user is. Imagine our cook needs to upload images for his recipe. The Product Owner provides information about the user story, with acceptance criteria and everything is required. But then the recipes don’t have images.
Meet Oscar — passionate cook and values family time.
Oscar represents the ideal user profile of the CooLab App.
Oscar thinks that everyone should be able to cook for their beloved ones and spend time together. It is important because family is the most important thing we have. Oscar thinks that while eating with family at home, we get closer to them and share more precious moments than in a restaurant. He says the dinners we are superficial.
Oscar loves to share his passion for cooking and family with the world. But he’s overwhelmed with doing many things to teach people to cook: food taking pictures, sharing, replying to emails.
Oscar feels motivated when people love his cakes and enjoy his food with his beloved ones. However, he feels stressed when he has to do digital things. He loves to cook
Oscar does shopping for his restaurant, prepares for his clients every single day he spends in the kitchen.
What would you think now when reading the story?
As a user, I want to be able to upload my new chocolate ice cream receipt in 1 hour so children can make it for Mother day.
The moment I started to think about the user stories from Oscar’s perspective, instead of associating a feature to a persona, everything changed. The moment I began to use the name of people and learned more about them, the quality of the user stories increased by ten folds:
- The features are tightly connected to an action Oscar does
- The features resolve a real need that Oscar has
- There is a better understanding of Oscar's way of using the application and a stronger focus in delivering value to him rather than closing a user story as quickly as possible.
- the development team needs to make decisions every day about the “HOW” to implement specific user stories, knowing Oscar helps to develop better products than knowing the “cook-user.”
- build products for the users, not create users for products
In my career, this was a game-changing experience. It all started with one project where the user stories kept on changing the description, expectations from one sprint to another, from one day to another. We couldn’t just keep things steady for longer than two days. However, the moment that we started to name the users, to identify them in real life, there was clarity, empathy, and ownership. We began creating products for people, not searching for people for our products.
Note: we want to name the representative users, to give them life and a character, not to build an app for each user.
Give it a try on your projects and the products you are creating. I’m interested in your experience. If you already tried it, how did it go?
Related articles:
