Everything you do to your product has a reason. There’s a reason that button is blue, or that message contains those words. There’s a reason you display that data or that notification.
Every reason is, at its heart, about the user.
This is why I like using user stories to talk about specific product developments and changes: writing stories reminds us that at every step of the way, everything you do is about your user. Every time you want to change something or add something, you need to understand ‘why’ – why are you adding what you’re adding, and why should the user care.
Connect the user story with the real user value. What the user wants. Not what you want, what marketing wants or what your boss wants – but what the user wants.
Here’s an example of a user story that came across my desk recently:
As a user, when I hover over search results in the search list, I want the pins on the map to change colour.
What’s wrong with this user story? Firstly, it’s a bit ambiguous – which pins?
As a user, when I over over search results in the search list, I want the pin representing that search result to change colour.
Ok, it’s a bit clearer. But is this what the user really wants? I don’t think users have a pin colour problem. What they have is a problem of identifying where the search result is located on the map. The colouring of the pins is a solution, which should be saved for the story specification or acceptance criteria. What the user wants, I think, is this:
As a user, I want to quickly understand where each search result is on the map relative to the other search results.
Clear. But why? Why does the user really want this? Understanding the why helps us understand how to solve their problem. That’s where the second, and often forgotten, part of the user story comes in: the ‘so that’ part:
As a user, I want to quickly understand where each search result is on the map relative to the other search results, so that I can get a feeling for where the place is relative to me or some other point.
Now we are at the core of what the user really wants, and we can go on to design a solution that solves this user problem. This process of story refinement gives us a better understanding of the true motives of the user: the ‘why’.
If you find that you’re looking at a user story that contains more problem specification than solution, keep refining until you get to the real user value; what the user really wants.