User stories are a great way of boiling down the intent behind a client’s requirements for a new system or product. They help everyone on the team to think about what they’re designing and building from the end-user’s perspective and they also provide transparency and a shared understanding of what’s in scope for a product.

User stories work well for agile projects as they can be added to, modified or deleted throughout the design and development process. As a bonus, they reduce upfront planning time: you only get stuck into the details when you start working on that story.

How do you write a user story?

A user story is a short description of something that your end-user will do when they come to use your system, website or software, focused on the value or result they get from doing that thing.

User stories are:

• a sentence written from the point of view of a person using your system, website or software
• written in simple language without technical details or jargon.

They cover:

• who the user is and their role (if relevant)
• the action they need to take
• the reason for the action, and/or what it aims achieve

The basic technique is simple. Take this format:

As a [role/persona] I want [action] so that [achievement]

…and fill it out.

For example: As a Facebook user I want to be able to assign different privacy levels to my photos so that I can control who I share which photos with.

The stories will form part of a product backlog, or list of requirements, which can be refined and prioritised as a team.

Who writes a user story?

How do you go about producing the stories in the first place? The requirements belong to you as the client, but what you have little experience of writing user stories or are struggle to clarify the intent behind them?

At Hyphen8 we like to take a ‘one team’ approach and work with our clients to get a shared understanding of requirements. Recent collaborations have given us some useful learning about working together on user stories.

Top tips on writing user stories together

1. Start with good discovery sessions to make sure everyone understands the process or feature that users need. Make sure you have the right stakeholders in the room so you don’t miss anything or have to keep going back with more questions. Whoever is responsible for writing the user stories should also be at the discovery sessions.




2. Try to keep stories system agnostic: focus on the who, what and why, not the ‘how’. This lets stakeholders from the client team and the product owner bring their knowledge to bear when defining the who and the why, and lets designers and developers from a consultancy bring their expertise to bear on the how.




3. Getting to the intent of the requirement is key: don’t let the people writing the stories get too distracted by replicating current process steps in story form. Try to encourage them to move up a level and think about the essence of what they’re trying to achieve and the value that the action brings.




4. Try to avoid duplication of stories: it’s good to make sure the product owner and other assigned team members have oversight of the whole suite of stories so they can spot where there’s overlap.




5. Don’t bother including stories that cover ‘out of the box’ functionality as they are not needed for the build.




6. Make sure you decide as a team about how you’re going to manage the process of story writing and refining: we’ve previously made the mistake of not doing this early enough, which meant stories weren’t feeding through to the tech team to build quickly enough.




7. It can be useful to as a business to write your own user stories as it helps you to clarify your requirements and take ownership of them. As consultants, we make sure we build some time in for coaching and supporting clients to write the stories themselves. Sometimes we ask clients to produce a first draft of stories and then have an early informal review with them to see if they need any tips.




8. Decide when it may be quicker and more effective for consultants to write stories on your behalf. As service designers we sometimes step in to help with this when we’re proposing changes to a customer’s existing process. It can be hard for people to envisage what a different approach could look like and why some of their existing requirements may be redundant in the ‘new world’. The most important thing is to get a shared understanding.




9. Do make sure there is business buy-in for the concept behind the stories and sense check them, but don’t try to spend time perfecting them upfront: that’s what refinement is for. Backlog refinement is a great way of taking user stories and working together on improving them to make sure the tech team and product owner have a shared understanding. After this, the stories are ready to be prioritised for development.




10. Don’t waste too much time on writing stories and triple checking requirements with different stakeholders! Refine the story, prioritise, develop and test. The best way of getting buy-in for the detail of a feature or product is to put an early version in front of users and ask them to test it. This can’t happen if it’s still on paper.

If you’d like to learn more about user stories and how to write them, as well how they can benefit your project get in touch with the Hyphen8 Service Design team. We can offer support, coaching and training to help you clarify and define your requirements.