Acceptance criteria are part of the interface
A clear requirement describes the behaviour that marks completion. That gives the person commissioning the work and the person building it the same thing to inspect.
- 5 Sept 2026
- 2 min
- Brittek Digital
Describe a visible result
Write the requirement around an action and its outcome. For example: submitting a valid form shows confirmation; an invalid submission keeps the entered values and explains what needs attention.
Keep each check small enough to verify independently. Separate required behaviour from optional polish.
Test the whole interaction
Include keyboard use, focus movement and the way a control opens and closes. Check the composed interface, even when its underlying component is already tested.
A dialog is not complete because it appears on screen. Someone must be able to use it, dismiss it and continue their task.
Include recovery
Decide what happens when validation fails, a request times out or a result cannot be saved. Preserve useful input and make retry behaviour deliberate.
Name the state that actually completed. A successful request and a saved result may require separate checks.
Make completion easy to review
Agree on the evidence needed to accept the work and who reviews it. Keep exclusions explicit so adjacent requests do not quietly expand the scope.
The best checklist is the smallest one that demonstrates the promised behaviour.