User stories are a prominent part of an agile software development approach. They are the main reason why we have been able to move away from lengthy requirement specification documents associated with the waterfall approach to short statements based on a number of conversations around desired functionality. For that accomplishment alone we should be hugely thankful!
User stories are generally structured in this manner:
As an [actor], I want [action] so that [goal].
As the title of this article may suggest, I will be looking at what makes a good user story for a designer or design team to pick up and run with in order to design a solution that can be researched and refined with your users. Therefore I won’t be diving into things like acceptance criteria that are required for taking a fully fleshed out user story into development, but only that which gives us design constraints and yet allows us freedom in the process to create usable solutions.
Good user stories are based on real user needs
It’s right there in the name. A good user story is based around the real needs of actual users. They do not start with phrases like “as a developer”, or “as a product owner”, these are internal needs of the business and part of developing better ways of working as a team and in no way should be bundled together with real user stories.
I am not saying that these requirements do not exist, but filing them as user stories is a misnomer. This generally doesn’t happen in the early stages of discovery before going into a design phase, but it is worth mentioning as user stories are far more refined and detailed before they arrive in the hands of the developers, and can be introduced from other avenues aside from the results of research with users. If you do have these stories, may I recommend calling them “stakeholder stories” as this more accurately reflects their need to exist.
Sorry, back to real user stories after that brief departure!
User stories should be derived from user research; the uncovering of real problems that need a solution in relation to the digital product you are working on. A user will have a particular goal, they want to use your product to reach that goal, and will provide you with their specific context in which they find themselves.
This will help you to create your single statement outlining a user story.
Good user stories are aligned with business goals
Even though I’m am a strong advocate of user-centred design, I am not blind to the fact that you wouldn’t be able to design anything for your users if there wasn’t some kind of business or organisation which provides the product which you are working on for the benefit of your users.
To this end, the user stories that you are able to work on will align to the needs of the business, and help to achieve the business goals as well as the goals of the user.
If you’re working for a bank and the user wants to be able to easily set up a savings account for their goal of putting a deposit on a house or apply for a credit card to build a better credit rating, these will most likely be well aligned to the business, but maybe there is a drive within the business to build their number of customers who hold a credit card with them, in which case the latter of the two examples would take priority.
Pragmatically speaking, without the business there will be no users, therefore a good user story helps both the business and the user to achieve their goals.
Good user stories come from collaboration
The single line of a user story only provides the starting point from which the user story develops from this initial statement into a designed, researched, and tested solution. The real value in a good user story comes from the conversations around it; the collaboration within your team and organisation.
Your discussions will involve your findings from user research, what those findings could mean within the context of your product, how some approaches may dovetail nicely with existing features and journeys or how some may break down at the first hurdle. You should involve everyone in your team (not necessarily all at once) to make sure that the work you are doing on your proposed solution to the given problem in the user story is feasible, in keeping with recognised flows and patterns, delivers value to the business, and is actually delivering a real solution to that problem.
These conversations and collaboration happen as part of the process whilst you are designing and building prototypes of your solution. As you go you can involve different members of the team for their input, making sure that you haven’t missed out on anything obvious, introducing things that shouldn’t be there, and essentially making sure that everyone is happy with the direction in which the work is moving towards that solution for the user need.
It is through this process that the user story will grow in terms of understanding within your team, and will begin transforming into a more fleshed out story that you would see handed over to a development team that includes elements like acceptance criteria, dependencies, considerations, related artefacts and more.
Good user stories do not prescribe a solution
When it comes to the design process, constraints are great, but building out a prototype to the letter of a specified solution does not leave room for exploration and experimentation. Part of the design process is being afforded the freedom to make mistakes early, discover the wrong paths, and cease pursual of them in light of the evidence you will obtain from user research and usability testing.
If your user story describes precisely how a problem should be solved, or even hints to a specific direction, it is possible that the design work will be railroaded in that specific direction, and it then becomes an uphill battle to attempt to deviate from the set course.
By only posing the problem that needs solving can you effectively carry out the design process to explore the avenues available to you, and to verify whether the direction you are taking is the right thing for your users through research and testing.
Good user stories that have these four characteristics are the spark that puts starts design process on the right foot and enables you to go and create something the will satisfy, or perhaps even delight the user when it comes to serving their needs and helping them to reach their goals. They are a focal point around which conversations happen and decisions can be made, and are a great way to encourage collaboration with your entire team in the early phases of your work, and everyone can have an impact in shaping what your product will become.
Originally published at https://westleyknight.com on November 3, 2020.