How to write acceptance criteria for a website build

Acceptance criteria are the conditions that show a website feature works for its intended user. Write them as observable outcomes before development is complete. This gives the client and developer a shared way to test the build and reduces arguments based on vague words such as 'easy' or 'modern'.

Start with a real user journey

Take one task at a time. For a contact form, the user needs to enter details, correct mistakes and receive a clear result. Staff need the enquiry to reach the right place. Criteria should cover both sides rather than only whether the submit button can be clicked.

An example criterion might be: 'When a visitor leaves the email field empty and submits the form, the page identifies that field in text and keeps the other entries.' Another might be: 'When a valid form is submitted, the record appears in the agreed inbox and the visitor sees a confirmation.' These are testable without prescribing the developer's exact code.

Include failure and edge cases

Ask what happens when a service is unavailable, a user submits twice or a field exceeds its limit. A booking feature needs criteria for a taken slot and a cancellation, not just a successful booking. A file upload needs limits, error messages and a way for staff to see the result.

Prioritise cases that could cause lost data, confusion or financial harm. The aim is not to list every conceivable input. It is to describe enough normal and exceptional paths that the team can make a confident release decision.

Make accessibility and devices visible

Criteria can require a task to work with keyboard navigation, readable labels and clear error messages, as well as on narrow screens. The W3C guidance on identifying form errors explains why an error should be described in text rather than signalled by colour alone.

Agree which browsers and devices are in scope and how testing will be carried out. Do not write 'mobile friendly' without a check that a reviewer can perform. A concise website brief helps connect these checks to the audience and purpose of the site.

Agree who accepts the work

Put criteria beside each deliverable and name the person who can approve it. Record test evidence and unresolved defects. Decide which issues block launch and which can be scheduled later. If a requirement changes, update the criterion so everyone tests the same target.

Acceptance is not a claim that the website will never fail. It is a documented decision that the agreed journeys work to the required standard at the time of release, with remaining risks understood.

Frequently asked questions

Should acceptance criteria describe the design in detail?

They should describe outcomes that matter to users. Specify necessary visual or accessibility constraints, but leave implementation choices open where several solutions could work.

Who should write and approve the criteria?

The client and delivery team should shape them together. A named client representative should approve the final set before it becomes the release test.

Can criteria be added after development starts?

Yes, but late additions may change scope and cost. Record the reason and agree their effect on timing before treating them as mandatory.