User stories for designers: format, criteria and mistakes
A user story says who needs something, what they want to do and why. How to write one, which quality criteria to use (INVEST) and where design contributes.
What is it and where does it come from?
Mike Cohn, at Mountain Goat Software, credits Ron Jeffries with the three-word formula: card, conversation and confirmation. What matters is the conversation: the written sentence is a reminder to talk, and the full requirement emerges from that talk.
The three-part template came later. Agile Alliance calls it the Connextra format, after the UK company where it was invented in 2001, and presents it as: who wants to accomplish something, what they want to accomplish and why. Martin Fowler describes it in similar terms: “As a” says who, “I want” says what, and “so that” says why. For judging quality there is another tool, INVEST, which according to Agile Alliance originates in an article by Bill Wake and is among the techniques Cohn recommends in his book User Stories Applied (2004).
An example from Agile Alliance, translated: “As a bank customer, I want to withdraw money from an ATM, so that I am not constrained by opening hours or queues at the teller’s window”. The story does not say how the ATM should be built. It only says what the person needs and why.
Why does it matter to a designer?
Because the “why” is where design usually adds the most. A development team can build “an application form” without asking whether the person understands what they are being asked. A story that says “so that I can tell whether I can pay the instalment without asking for help” already contains an experience criterion.
Fowler notes that the “so that” clause provides context to understand what is actually needed, not only what the customer believes they want. That is the point where user research and the jobs to be done (JTBD) approach meet the story. If the situation matters more than the role, see job stories.
How do you write a good one?
Fowler reminds us that stories are deliberately not fleshed out in detail until they are ready to be developed. A good starting point is to follow the template and then check quality against INVEST:
- Independent. It can be delivered without depending on another story to make sense.
- Negotiable. It is a need, not a closed feature contract. The team can discuss how to meet it.
- Valuable. It gives value to someone. If nobody gains anything, it is not a story.
- Estimable. The team can roughly calculate its size.
- Small. It fits within one iteration.
- Testable. There is a way to know whether it was met.
Agile Alliance says these formats are meant more as checklists, that spending much effort on complying with the template is without much point, and that it works as “training wheels” for teams learning to think about who a feature serves and why. Cohn agrees: the template helps when it improves the conversation, but it should not become a ritual. The important question is not whether the sentence has the right shape, but whether the team understands who it serves and what must happen for it to be considered done.
Acceptance criteria are the concrete conditions a story must meet to be considered finished; they are a common practice when working with stories, though not part of the template. This is where design comes in: states, error messages, behaviour on mobile or with the keyboard. A story that arrives with those criteria leaves fewer open questions for the conversation with development.
How does it work alongside design?
Stories do not replace designs, but they connect them to the team’s work. A useful practice is to link each story to its screen or flow, for example with user flows or wireframes, and let the design be the visible answer to the story’s criteria.
Be careful with the wording. A story written as “As a user, I want a blue 48-pixel button” does not describe a need; it describes a solution. That reduces negotiation and makes the story harder to verify. Design should appear as a criterion (“the primary action is identifiable without reading its label”) rather than as a specification.
A quick test for any story is to try to describe how you would know that the “so that” is met. If the answer is that you would not know, the problem is usually in the story, not in the implementation, and it is worth rewriting before building.
When should you NOT use them?
- When the problem is not yet clear. A story about a solution nobody has validated is an opinion with a template.
- When the work is technical and has no direct user, such as a migration. A task may be enough.
- When the story becomes a contract. If the team cannot negotiate scope, the word “negotiable” loses its meaning.
- When hundreds are written without review. A backlog full of vague stories is harder to manage than a short one.
Example
Illustrative example: a team building an invoicing app wants to improve how payment reminders are sent to customers. An initial story says: “As an invoice issuer, I want to send reminders, so that I get paid faster”. The designer proposes reviewing it with the team, and the result is: “As an invoice issuer with overdue payments, I want to send a reminder with the amount and due date, so that the customer can pay without me having to call them”. The acceptance criteria include: the reminder shows the amount and the date, the issuer can edit the text before sending it, and the sending is recorded on the invoice. The story is smaller, clearer and easier to verify.
For your next backlog: take three stories, rewrite each one with who, what and why, and check whether you can write a criterion that someone could verify.
Common mistakes
- Writing solutions instead of needs.
- Using “as a user” for everything, without distinguishing profiles.
- Leaving out the “so that”, which is where the context lives.
- Leaving stories without acceptance criteria.
- Stories that are too big to fit in one iteration.
- Applying the template mechanically, without conversation with the team.