A feature request can sound perfectly clear until two people try to build and test it. “Let staff complete a job” might mean one button to the business owner, a six-step form to the person doing the work and several new records to the developer.
Acceptance criteria remove that ambiguity. They describe the observable conditions a feature must meet before everyone agrees that it is complete. For a small business commissioning a custom app, they are also a useful way to catch missing decisions before those decisions become rework.
Start with the user’s job
Write down who needs the feature and what they are trying to achieve. Keep the first sentence about the job, not the screen. “A member of staff can record the outcome of a site visit” is more useful than “add a completion button” because it leaves room to find the right interface.
Then list the conditions that would prove the job can be completed. For an illustrative site-visit feature, the criteria might say:
- An authorised staff member can open a visit assigned to them.
- They must enter the visit date and choose an outcome before submitting it.
- The app records who submitted the outcome and when.
- If a customer notification fails, the visit record remains saved and staff can see that follow-up is needed.
These statements give the team something concrete to discuss. They also expose questions about permissions, required information and failed notifications while there is still time to answer them properly.
Describe the result, not the implementation
Acceptance criteria should usually say what must be true, rather than dictating how the developer must make it happen. A criterion such as “show a large green button at the bottom right” fixes a design choice before the layout has been explored. “The user can submit the completed visit from the review screen” describes the required result and keeps the design open.
There are exceptions. If the business must use a particular accounting system, data format or approval rule, record that constraint. Just be honest about the difference between a business requirement and a personal preference.
Make every criterion testable
Words such as “easy”, “fast” and “user-friendly” sound positive but do not tell anyone how to decide whether the work passes. Replace them with behaviour that a person can check.
Instead of “the form is easy to complete”, state which fields are required, what happens when information is missing and whether a user can return without losing saved work. Instead of “managers can see useful reports”, name the decisions the report should support and the information it needs to show.
A good test is to hand the criterion to someone who was not in the original conversation. Could they demonstrate a clear pass or fail without guessing what the author meant? If not, the wording needs another pass.
Include awkward cases
The happy path gets most of the attention because it is easy to picture. Real work also includes duplicate records, missing information, expired links and people attempting actions they are not allowed to perform.
You do not need to predict every technical problem. Cover the business situations that would cause confusion, lost work or an incorrect decision. Useful prompts include:
- What should happen if the same request is submitted twice?
- Who can view, edit or reverse this action?
- What does the user see if a connected service is unavailable?
- Which information must be kept when the wider action cannot finish?
This is where a vague feature often turns into a workable one. It may also show that the first version needs to be smaller.
State what is outside the feature
Acceptance criteria can grow into a hidden wish list. Keep a separate “out of scope” note for sensible ideas that are not part of the current piece of work. A visit feature might record an outcome now, while route planning and automated invoicing remain separate decisions.
That boundary protects the budget and makes approval more meaningful. It does not discard the later ideas. It stops them quietly changing the feature after development has started.
Use a format people will actually review
The GOV.UK Service Manual describes acceptance criteria as a checklist of outcomes that confirms a service has done its job and met the user need. That is a good starting point for most small projects.
Some development teams use a structured “Given, When, Then” format. It can be helpful when the starting state and sequence matter, but plain language is fine if it stays specific. The best format is the one that the business owner, users and developer can all challenge before work begins.
A short acceptance criteria template
Use this outline for each feature:
- User and job: who needs to do what?
- Starting conditions: what must already be true?
- Successful outcome: what can the user complete or confirm?
- Rules and permissions: what is required, restricted or recorded?
- Failure handling: what should remain safe and what should the user see?
- Out of scope: which related ideas are not included?
Review the list with someone who performs the work, not only the person funding the project. Their questions often reveal shortcuts, exceptions and terminology that a meeting-room version of the process misses.
Use the criteria throughout the build
Acceptance criteria are not paperwork to file away after a quote. Use them when reviewing a prototype, checking a development build and deciding whether a feature can be accepted. If the business rule changes, update the criteria deliberately so the change is visible.
They will not replace a clear workflow or thoughtful design. They give those conversations a firm edge: this is the job, these are the boundaries and this is how we will know it works. If an app idea is still mostly a collection of screens and feature names, start with the process and the people using it.