How to write acceptance criteria for a small web app
Write each acceptance criterion as three short parts: the situation you start in, the one thing the user does, and the result you expect to see. Keep each criterion to one behaviour, use concrete values, and word it so that a person who did not build the feature can say clearly whether it passed. Agree the criteria before the work starts, not after.
What acceptance criteria are for
Acceptance criteria say what must be true for a feature to count as done. They stop the argument at the end of a project, because the agreement was written down at the start. They also give the builder something specific to build towards, instead of a general idea like "booking should be easy".
The three part pattern
The Cucumber documentation on Gherkin describes a structure used for executable specifications. Given steps describe the initial context of the system. When steps describe an event. Then steps describe an expected outcome. You do not need any software to use the idea. Writing in this order simply forces clarity.
The Cucumber reference also says the purpose of Given steps is to put the system in a known state before the user starts interacting with it, and advises avoiding talk of user interaction in them. If your Given sounds like an action, it probably belongs in When.
One behaviour at a time
Keep each criterion to a single behaviour. "Given a customer has chosen a free slot, when they submit the form, then they see a confirmation with the date and time" is checkable. "The form works well and looks good" is not. If a sentence needs the word "and" between two outcomes, consider splitting it.
Use concrete values
Replace vague words with values that can be tested: a specific date, a specific amount, an exact message. The Gherkin reference shows how similar examples can be gathered into a scenario outline with a table of values. In plain terms, when the same rule applies to several cases, write the rule once and list the values underneath.
Cover refusals and edge cases
For each feature, add at least one criterion for what should not happen: a slot already taken, a missing email address, a person without permission. Many disputes at the end of a project involve an edge nobody wrote down.
- The expected result when input is invalid
- What a user without permission sees
- What happens with an empty list or a first-time user
- What the page looks like on a narrow phone screen
- Which keyboard-only steps must still work
A hypothetical example
Imagine a small app where clients request a repair visit. One criterion reads: given a client is signed in and has no open request, when they submit a request with a description and a preferred day, then the request appears in their list with the status "Received". A second reads: given the description is empty, when they submit, then the form stays open and shows a message next to the description field. A third reads: given a signed in client, when they open another client's request address, then they see an access refused page. Each can be checked in a minute. This example is hypothetical.
Agree them and keep them
Review the criteria with the person who will accept the work, before building. When something changes, change the criteria too, and note the date. At delivery, go through them one by one together. Passing every criterion does not prove the app is perfect, but it makes the agreement visible and the handover calm.