Describe a situation and an outcome
Replace “support approvals” with examples. Given a submitted request assigned to a reviewer, the reviewer can approve it, the status changes, and the requester can see the decision. A rejected request may require a reason and a defined next step.
Use language that the people operating the workflow understand. Criteria that only describe database fields or component names can miss the experience that made the work necessary in the first place.
Include important boundaries
Decide what should happen when required information is missing, the user lacks permission, or the same action is attempted again. Choose cases that could change the outcome, rather than enumerating every visual detail.
State what is outside the change. If a request can be approved by one reviewer but not by a sequence of reviewers, make that limitation explicit. This avoids a disagreement at the end of delivery about an assumption nobody wrote down.
Make the evidence practical
Explain how the team can demonstrate each criterion with representative data. Some behavior belongs in an automated test; some requires a person to inspect the workflow or confirm that the language is understandable. The appropriate evidence depends on the behavior being evaluated.
Review the criteria before implementation with someone who knows the process. Revisit them when a discovery changes the requirement, and keep the reason for the change visible.
Avoid a final acceptance meeting that introduces an entirely new interpretation of success. The demonstration should confirm an agreement the team has been working toward. When a criterion cannot be evaluated without another conversation, treat that as a sign that the requirement needs more detail, not as permission to guess.
Test the boundary, not just the happy path.
GOV.UK’s user-story guidance connects acceptance criteria to deciding whether a user need has been met. A practical way to do that is to write a small matrix of observable outcomes. The following cases describe an assignment workflow; they are examples to adapt, not a universal requirement set.
| Situation | Expected result | Evidence |
|---|---|---|
| Coordinator assigns an open request. | Chosen technician becomes its owner. | Reopening the record shows the saved owner. |
| Submitter attempts the same action. | Assignment is rejected by the service. | The owner and audit history remain unchanged. |
| Two coordinators edit the same version. | A stale edit cannot silently replace the accepted change. | The second person sees a defined conflict response. |
| Technician is no longer eligible. | The assignment is rejected with a useful reason. | The coordinator can select another technician. |
Notice that the matrix does not require a particular database or component library. It also does not define success as a toast message appearing. The record must remain correct after the page is reopened. For a state-changing action, that distinction separates feedback from actual completion.
Make an ambiguous case executable.
Given request R-104 is unassigned at version 7
And coordinator A has permission to assign it
When A assigns technician T-12 using version 7
Then R-104 has owner T-12 and a new version
And the history identifies coordinator A
When coordinator B submits an assignment using version 7
Then the service reports a stale-version conflict
And T-12 remains the ownerThis is an illustrative behavior specification, not executable test code. It introduces a version check because the example needs to describe concurrent edits. A real system may use a different concurrency mechanism while preserving the same agreed outcome. Decide how the interface presents the conflict and how the second coordinator reviews the current record before trying again.
Keep criteria small enough to demonstrate independently. If one statement includes assignment, billing, reminders, and reporting, a failure becomes difficult to locate and acceptance can turn into an argument about partial completion. Split the outcomes, identify their dependencies, and agree which ones are necessary for the release. During review, use representative records and test the service boundary as well as the visible interface.
A practical example.
For a request-assignment feature, “the coordinator can assign requests” leaves important behavior undefined. A more useful example says: given an unassigned request and an eligible technician, saving an assignment shows the technician’s name and records who made the change. A user without assignment permission cannot perform that action.
Add a competing-edit case: another coordinator has changed the request since the page loaded. The expected outcome might be a clear prompt to review the latest record, rather than silently overwriting it. These criteria describe observable results without prescribing a particular database or component. Review them with the person accepting the work before implementation, then use the same examples during a demonstration.
Put it into practice.
- Include a successful outcome, an invalid input, and an authorization boundary.
- State what users can observe, including messages and saved changes.
- Resolve ambiguous terms such as “fast,” “complete,” and “appropriate” with concrete examples.