Back in July our funded projects had a rough idea of what their users needed. Since then they’ve been developing more specific ‘user stories’. Learn how to use user stories to make sure you’re creating what your users need, not what you think they want.
In all my days of working with agile service and product designers there’s one trick they use that never fails to impress me.
It’s user stories. Or more specifically, the power of user stories to make project teams put aside their assumptions, empathise with their users and focus on what their users need most.
Any charity or social enterprise can use user stories to improve any of its services. They aren’t exclusive to tech products and they can be written to capture any stakeholder’s needs, not just end users.
What are user stories?
They are a simple, succinct way of describing a user’s need in relation to your service or product. They capture it in a really useful way:
As a… [who is the user?]
I need/want/expect to… [what does the user want to do?]
So that… [why does the user want to do this?]
Here’s some examples
As someone with a mental health issue I need help on a weekend so that when I’m feeling most vulnerable I don’t end up in crisis.
Why they are awesome!
As a… [user type]
Phrasing the need through the eyes of your user encourages empathy. It makes you stand in their shoes, and consider what it’s like for them. Rather than thinking we know what we’d want if we were that user, we have to make the effort to think as they do.
Note, its harder to empathise if you haven’t done some user research first.
I need/want/expect to… [goal]
This piece of the story defines the user action or goal they are trying to achieve. It should help us understand what need or experience would make their life better. It shouldn’t ever describe how to achieve that need or experience.
If what you’ve written here feels or looks like a feature then remove it and try to articulate the underlying need instead.
So that… [reason]
The final piece in the jigsaw – the reason behind the user need. It’s crucial. Without it you’re flying blind, unaware of the context and rationale for the task or goal. It conveys your knowledge of their fears, feelings and desires. If the reason is evidence-based and well articulated then it will help you plan how to meet the need.
It’s easy to skip this part. If you do then circle back later and try to validate it objectively.
How to use them
Write user stories after doing user research. Use the research to create personas, empathy maps and user journeys then use these to drive your ideas and features. Focus on what the evidence tells you and be ruthless with your own biases.
Alternatively write your stories pre-research, based on your best guesses. Then research each one, challenge its accuracy and discard or change those that are wrong.
If you want to be really thorough, or need more insight into particular needs test out different story versions with your users, or ask them to rank stories for importance.
What to use them for
-
Prioritise, grouping the most important ones together so you know which to focus on
-
Run an ideation session, listing as many ideas as possible for each need
-
Pick those ideas you think are worth testing, and test them.
- Draft acceptance critieria for each story – outcome statements that help you know when each need is met
