In all my days of working with service 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 charity teams put aside their assumptions, empathise with their users and focus on what their users need most.
Any charity can use user stories to improve its online and offline services. They aren’t exclusive to digital services and they can be written to capture any stakeholder needs, not just your beneficiaries
What are user stories?
They are a simple, succinct way of describing a user’s need in relation to your service. 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.
As an app user I need to be able to easily reset my password so that I can log in when I’ve forgotten it.
As an online counselling service user I need to know where I need to be and when for my first online session, so I don’t feel anxious about this new way of receiving a service.
As a service administrator I need to be able to easily sort and respond to website queries so our beneficiaries get a response within one working day.
Why they are awesome!
As a… [user type]
Phrasing the need through the eyes of your user encourages design thinking and 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
Once you have a list of solid stories use them to guide your product’s development or to design your service better:
- 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 criteria for each story – outcome statements that help you know when each need is met
You can even use stories to guide funding bids and project pitches.
More agile tools
The Government Digital Service has a good guide to other agile tools. Check it out here.