Acceptance criteria for website projects, with examples

Acceptance criteria are a short written list of conditions a feature must meet before you accept it as finished. Write them for every important feature before agencies quote, in plain checklists or in a “Given, When, Then” format, and tie each payment milestone to them. In my experience, for a typical website or shop, drafting them takes a few days of focused work, and it’s the cheapest insurance against overruns I know.

I set acceptance-criteria-first standards at two agencies, from the delivery side. The reason was simple: projects with criteria ended in sign-off, and projects without them ended in arguments.

What acceptance criteria are

A feature description says what you want: “customers can search the site”. Acceptance criteria say how you’ll check it works: what happens when someone searches for a product name, a misspelling, or something you don’t sell. They turn an intention into a test anyone can run.

The GOV.UK Service Manual describes them as a list of outcomes used as a checklist to confirm the work has done its job, often written as a list beginning “it’s done when…”. That’s a good working definition for any website project, public sector or not.

Good criteria are:

• Testable. Someone can say yes or no. “Fast” isn’t testable; “loads within 2.5 seconds on the test page” is.
• About outcomes, not code. What the customer or your team sees and can do, not how the developer builds it.
• Agreed before the build. Criteria written after something’s built tend to describe whatever got built.
• Short. Three to eight per feature is usually plenty. If you need twenty, the feature is probably two features.

Why a long brief without them still overruns

A long brief feels thorough. But length describes what you want, not how you’ll know you’ve got it, so every agency fills the gaps with its own assumptions.

One brief I reviewed ran to 69 pages, with no acceptance criteria and no milestones. Estimates for the same work ranged from nine months to two years. Nobody was being unreasonable: each agency read the same words and imagined a different project. Without criteria, there was nothing to price against and nothing to test against at the end.

That’s how overruns happen. The client reads “integrates with our stock system” as live stock levels on every product page. The agency read it as a nightly file. Nobody finds out until it’s built, the gap becomes a change request, and the cost lands somewhere. Two sentences of criteria, written up front, would have surfaced it during the quote.

How to write them

Given, When, Then

This format comes from behaviour-driven development, and it’s useful because it forces you to say the starting situation, the action and the expected result:

• Given sets the scene: who the user is and what state things are in.
• When is the action or event.
• Then is the outcome you can check.

It suits anything with a sequence: checkouts, bookings, forms, logins.

Plain checklists

For things that are more about a standard than a sequence, such as page speed, accessibility or what the editing screens must allow, a plain “It’s done when…” checklist is clearer. Use whichever format makes the test obvious. Mixing them in one document is fine.

Write the user story first

Each feature starts with a one-line user story: “As a [who], I want to [do what], so that [why].” The criteria then sit underneath it. The acceptance criteria builder drafts both from a one-line description, along with the questions to answer before anyone quotes.

Worked examples for common website features

These are starting drafts, not universal rules. Your business will have its own: delivery cut-offs, trade prices, cancellation terms. The point is to write yours down.

1. Checkout

As a customer, I want to pay for my basket quickly, so that I can finish my order on my phone.

• Given I have items in my basket, when I check out as a guest, then I can complete the order without creating an account.
• Given I enter a UK postcode, when I reach delivery options, then I see only the methods and prices that apply to that postcode.
• Given my card payment is declined, when I return to checkout, then my basket and address are still filled in and I see a clear message.
• Given my payment succeeds, when the order is placed, then I see an order number and receive a confirmation email within five minutes, and the order appears in the admin.

2. Contact or enquiry form

• It’s done when a completed form sends the enquiry to the agreed inbox and shows the visitor a confirmation message.
• Required fields are marked, and if one is missed, the form says which field and why, without clearing what was typed.
• Each enquiry is also stored somewhere other than email (the site admin or CRM), so nothing is lost if an email fails.
• Spam protection is in place and doesn’t require the visitor to solve a puzzle on every submission.

3. Site search

• Given a customer searches for an exact product name, then that product is the first result.
• Given a customer searches for a SKU, then the matching product is shown.
• Given a customer makes a common misspelling from the agreed list, then relevant products are still shown.
• Given there are no results, then the page suggests categories or popular products instead of an empty screen.

4. Product filters

• Given I’m on a category page, when I select a filter (for example size or colour), then only matching in-stock products are shown and the count updates.
• Given I’ve selected several filters, when I share or reload the page, then the same filters are still applied.
• Given a filter value would return no products, then it is hidden or shown as unavailable.
• The filters listed in the specification are editable by staff without a developer.

5. Booking

• Given a slot is available, when a customer books it, then the slot disappears for everyone else immediately.
• Given two customers try the same slot at the same moment, then only one booking succeeds and the other is offered alternatives.
• Given a deposit is required, when the booking is made, then the deposit is taken and both the customer and the business receive confirmation.
• Given a customer cancels inside the agreed notice period, then the cancellation rules in the specification are applied automatically.

6. Page speed

Google’s Core Web Vitals give useful thresholds: the largest piece of content should appear within 2.5 seconds, the page should respond to interaction within 200 milliseconds, and layout shift should stay at 0.1 or less, measured at the 75th percentile of real visits. A new site has no real visits yet, so write a launch test too.

• It’s done when the agreed test pages (home, a category, a product, checkout) meet the agreed lab scores on mobile, measured with a named tool, with the agreed sample content loaded.
• Thirty days after launch, field data for the same pages meets the Core Web Vitals thresholds, or the agency investigates and reports why not.

7. Accessibility

Public sector websites must meet WCAG 2.2 at level AA. Private businesses aren’t covered by those regulations, but GOV.UK notes they build on existing Equality Act 2010 duties, and WCAG 2.2 AA is the sensible standard to write into any contract.

• All functionality on the test pages works with a keyboard alone, and the focus indicator is always visible.
• Body text has a contrast ratio of at least 4.5:1 against its background.
• Buttons and links meet the minimum target size of 24 by 24 CSS pixels, or the spacing exceptions in WCAG 2.2.
• Form errors are identified in text, not by colour alone.
• The agreed test pages pass an automated check with no serious issues, plus a manual keyboard and screen reader check of checkout and the main form.

8. Content editing

• A named member of staff, after the agreed training, can create a new page from each template, add a product with variants and images, and update the homepage banner, without developer help.
• Changes can be previewed before publishing.

How criteria tie to sign-off and payment

Criteria earn their keep when they’re in the statement of work (the document that says what will be delivered, by whom, for what cost). Each milestone gets a defined output, a cost and its acceptance criteria. When the criteria pass, you sign off and pay. When they don’t, there’s a list of exactly what’s outstanding instead of a debate about whether it’s “done”.

An example structure, with illustrative percentages rather than a recommendation:

Two practical rules. First, agree who tests and how long you have to respond, so sign-off doesn’t drift for weeks. Second, any new requirement after sign-off goes through change control, with its own criteria and cost agreed in writing before the work starts. The sample documents include a specification with acceptance criteria and a change control note, written for a fictional business.

Where to start

List the five to ten features that matter most for launch. For each one, write a one-line user story and three to five criteria, using the examples above as a template. Mark which are must-haves. Then send that list with your brief, so every agency prices the same thing and you have a test to sign off against.

If you’d like it done with you, writing acceptance criteria is the core of a scoping brief: project scoping and agency selection is a fixed price from £750, or £1,500 for portals and systems. If a project is already running without them, fractional delivery leadership can bring them in mid-build, which is harder than starting with them, but far better than finishing without.