Skip to content

User Stories: Describe a User Need and Define Acceptance Criteria

Summary

Learn to write user stories that explain real goals, define outcome-based acceptance criteria, and create a testable slice of a booking workflow.

Published

Write the User’s Goal Before Specifying a Feature

A user story briefly describes a user, what they need to do, and why. It shares a goal in context before specifying the implementation.

Add a booking button says little about the problem it solves. Describe the need to choose an available appointment, then define the conditions the finished work must meet.

Describe the User, Need, and Reason

GOV.UK identifies the user, need, and goal as story elements. (GOV.UK: User stories) For example, a first-time visitor needs to choose an available appointment so they can request a booking without calling.

Combining unrelated goals obscures what to test. Describe requesting and changing a booking in their own contexts.

Write Acceptance Criteria as Outcomes

Criteria can require available slots, a clear indication of missing required information, and a visible submission status. Component names and colors alone cannot establish whether the goal was met.

If submission and confirmation are separate stages, include that distinction. The interface should not lead users to mistake a request for a confirmed booking.

Keep the Story Small Enough to Test

Choose a coherent slice, such as selecting a slot and submitting a request, rather than the entire booking operation. Make the end of that slice explicit.

Let relevant users try it and compare outcomes with the criteria. When releasing the feature, explain its scope and the post-submission process on the service website.

SpreadSite is a no-code website builder that lets you create, publish, and update a website from Google Sheets using ready-made templates.

To publish a website explaining how to use your new service features, give SpreadSite a try!

Build a website with SpreadSite →

Frequently asked questions

Q: Is a fixed user-story format required?

A: The user, need, and goal should be clear. A template can help, but filling it in is not the objective.

Q: Can I copy a requested feature into a story?

A: Investigate the underlying problem and describe it. Other solutions may meet the same need.

Q: How many acceptance criteria are needed?

A: Enough to assess the goal and important exceptions. Choose coverage rather than a fixed count.

Q: What happens after writing a story?

A: Discuss implementation, assess the result against the criteria, and update the story when user trials reveal problems.

Sources

Build a website with Google Sheets using SpreadSite