Acceptance criteria turn a broad requirement into behaviour that can be checked. They are especially useful when a business owner and a developer use the same words to mean different things. A request to approve an order sounds clear until you ask who can approve it, what information is required and what happens next.
Describe an observable outcome
Start with the situation, the action and the result. For a hypothetical Darwin maintenance supplier: when a complete job request is submitted, the coordinator can accept it and the job appears in the scheduling queue with the agreed status. This describes behaviour without dictating every visual detail. Avoid words such as seamless, fast or intuitive unless you can explain how the team will judge them. Those words express intentions but leave room for incompatible interpretations.
Add the examples that change the rule
Use concrete cases to uncover boundaries. What if the customer reference is missing? What if the job has already been accepted? What if the coordinator changes the requested date? You do not need an enormous catalogue before discussing a feature, but you do need the cases that alter its meaning. Ask someone who performs the task to supply examples. A developer can clarify behaviour, but should not have to invent the business's approval policy.
Separate correctness from preference
A missing required status change is different from a preference for a larger button. Both can matter, yet mixing them makes completion hard to judge. Keep criteria focused on the agreed outcome and record visual decisions where they can be reviewed explicitly. The tradeoff is between precision and unnecessary prescription. Specifying every pixel too early may constrain a better design; leaving essential business behaviour vague may produce a polished feature that cannot be accepted.
Review criteria before implementation
Read the examples together before development begins. Ask the supplier to explain what they would demonstrate, and ask staff whether that demonstration would cover their actual work. After delivery, use the same cases in a short review and record any gaps. Your next scoping step is to take one important feature and write a normal case, a rejection case and a correction case. GOV.UK's user-story guidance provides related guidance on connecting stories with acceptance criteria.
Planning checklist
- Use situation, action and result.
- Include a boundary and a correction.
- Agree criteria before the feature is built.