The success or failure of a piece of software, or any product for that matter, is how well its users are satisfied, and how well it solves their needs. In the world of web software, adding functionality is rarely the differentiating factor that will lead to the winning product. More likely the winner is the product that solves the user’s problem in the simplest, easiest and most delightful way.
In other words, product design is all about the user: solving their needs the best way possible. Every single line of code you write should help the user solve their needs better and easier…
… which is why I am often confused when I see user stories like “As a product owner, I want…” or “As a manager, I want…” Or worse still: “As a data centre, I want…”
Who ever asked a data centre what it wants?
User stories start with “As a user…” for a reason: the process of writing a clear sentence that starts with “As a user” forces you, with each product decision you make, to consider and understand how what you are about to do allows you to solve the user’s needs in a better, more efficient way. If you can’t do that, then you have to question why you are adding this user story at all.
Avoid stories that start with anything other than “As a user”. That’s why they’re called User stories. If you can’t work out what a user gets out of the deal, it probably isn’t worth it.
Love this. You’re very right, and…
There are exceptions:-)
As a User, when I register on the site, I want to have a capcha so that… No. Users don’t want capchas. Yet you might want to still add such a feature.
In these cases, I like to write the story in a way that it gets clear that the user might not want it. That you state clearly who’s actual need is fulfilled and that this solution is a compromise.
As you can’t build a business with only the customers interests in mind, you can’t build a software only for the users. But their perspective should go first:-)
Thanks for your inspiring post!
Olaf
It’s a good point that sometimes you have to include features and user flows that users might not want or like. The Captcha example is a good one: no user would ever want that. One could argue that every single thing you do to a product should have a positive impact on the user, however indirect it may be… whatever you do you do in the interest of the business, which allows it to exist to continue to provide the product to the user… but I agree, it’s a bit of a stretch. Still, it is extremely important to consider, for every thing you build and every line of code you write, how it will impact the user. When you get into the habit of writing user stories that have someone else’s interests in mind (other than the user), it’s easy to forget the user completely. And at the end of the day, you first have to know the rules, before you know when you can make exceptions. 🙂
Will
Nice post Will.what I disagree to is not all stories can be made use centric. A good example would be a product manager would like to know how many people are signing up on a daily basis so that he can give these metrics to the management to request for more funding.
Here the user is not getting anything out this story right ? Would love to hear from you if you can suggest an alternative.
Thank for the post
Varun