User stories.
As designers, we need to be focused on stories whose goal is to describe some aspects of a particular experience in a particular context, lived by a person.
A user story can be written, storyboarded or even recorded — audio or video.
You may have experienced something different at work when you have to prioritise on Jira, but the reality is that this phrase contains two clear words: user and stories.
User stories came from software development and they are mostly used in Agile software development.
They are slightly different per company but they mostly follow this pattern: “As a [ role of a person ], I want [ capability ] so that [ receive benefit ]”
embedded in a big value that we are going to provide to our end user.
It is a pity to see that sometimes in development we get confused we create the description in a way that is more a ‘system requirement’.
When we develop systems that interact with human beings we need user stories to describe who is going to interact with what and in which particular context.
*Ecosystem requirements are needed too when we have well-defined user stories, what the system needs to do in order to build the user story but we shouldn’t start with them.
As a User Experience Designer I want to see the TO-BE experience we’ve planned split on several user stories ranked on a list so that I can follow up the solution that we are going to build.
and…
As a User Experience Designer I want to see a user story with all the ecosystem requirements belonging to it so that I can make sure we build the ‘To-Be Experience’ that we’ve planned before.
*Ecosystem: (in general use) a complex network or interconnected system.
User stories are very important because they help us to understand situations, be more empathic with our target users and filling a situation with those hidden details we will further follow all across the design process.
Designers need to be aware of they need to be good listeners. Because before even we can start to create a new experience we need to listen a good story that may require analysis in order to get the needs, problems or just a good opportunity to innovate.
Once we have collected the user stories we can start thinking on create the new ones that can be built in order to change the scenario from the AS-IS to a TO-BE one.
I strongly recommend to start mapping the experience out and then from there, you can extract the stories that make substantial changes on it. You can even use the jobs to be done format.
Wrapping up, we can take the most of our user stories just being smart enough to find the key moment to share them.
Here I’m sharing 4 situations when you might need to share your user stories with other people:
. Illustrating user research findings.
. Pointing out some interactions we may need to fix.
. Reviewing a design concept — keeping the user centred focused.
. Describing the new experience we are going to provide.
Now you have the set of user stories that will compose, altogether, the experience that you and your team are planning to provide to end users.
Well done! This is the best part of the process.
If you now are in the situation to rank them, now it’s time to fight and get ready for a real time-constrains war.
Don’t let them money-makers to win. Fight for your users, let them talk through your stories and be your ambassador.
This post is part of the #30dayUXchallenge: you can read more about why we started it here, and don’t forget to follow us on Twitter and Instagram!
Originally published at blog.prototypr.io on November 14, 2017.
