How to write acceptance criteria for website and design work

Define what must be true for this work to be accepted

Write acceptance criteria as clear, verifiable conditions for a specific deliverable. State the expected result, the circumstances in which it will be checked and the evidence needed to decide whether it passes. Agree the criteria with the client before producing the work, then tie the review to an identifiable version.

A requirement such as “visitors can send an inquiry” expresses a need. Acceptance criteria make that need checkable: required information is validated, a valid inquiry reaches the agreed destination and the visitor receives confirmation. They describe outcomes rather than prescribing every implementation step.

Atlassian and Scrum Alliance both emphasize clear, testable conditions. Scrum Alliance also distinguishes item-specific acceptance criteria from a definition of done: the latter is a shared quality standard across work items. A studio’s standard handoff checklist can coexist with criteria written specifically for one client’s contact form.

Write the criteria together before implementation

The client explains the business need; the freelancer contributes feasibility and ways to verify it. A client should not need technical expertise to understand what a pass means. Resolve ambiguous words such as “intuitive,” “premium” and “works everywhere” before they become the basis of a final review.

1. Name one deliverable and its intended user outcome. Split unrelated features or assets into separate items.
2. List the observable conditions that would demonstrate the outcome, including important error or empty states.
3. Choose a checklist for static requirements or a Given–When–Then scenario for behavior.
4. Specify the review environment, reference files, test inputs and evidence where they affect the result.
5. Ask the client and delivery team to walk through each condition and agree what passing means.
6. Record the criteria version, authorized reviewer and review date before work starts. Revise transparently if understanding changes.

Website example: a working inquiry form

Fictional example: Noor is delivering inquiry form build 18 for Juniper Architecture. Criteria set FORM-1 covers the form on the staging contact page, not the rest of the website. The test plan records browser and operating-system versions, with desktop Chrome at 1440 CSS pixels and mobile Safari at 390 CSS pixels as the agreed initial environments.

These examples are a small feature checklist, not a comprehensive security, accessibility or browser-compatibility audit. Agree any wider standards and supported environments separately; passing a few functional checks does not establish compliance.

1. FORM-1A: Given the form has an empty required email field, when the reviewer selects Send, an email error appears and no inquiry is submitted. Evidence: the error and absence of a new test inquiry in the destination.
2. FORM-1B: Given the reviewer enters the agreed valid test name, email and message, when Send completes successfully, exactly one inquiry containing those values appears in the client’s designated test inbox. Evidence: the received test message.
3. FORM-1C: After that successful submission, the page displays “Your inquiry has been sent.” Evidence: a screenshot of the confirmation for the same test run.
4. FORM-1D: Given the test environment simulates a submission-service failure, when Send is selected, the page displays an error rather than success and retains the entered message for retry. Evidence: the recorded failure test.
5. FORM-1E: In each agreed browser environment, the reviewer can reach and operate every form field and Send using the keyboard, with a visible focus indicator. Evidence: a recorded keyboard walkthrough.

Design example: a verifiable logo handoff

For a design deliverable, separate creative judgment from production checks. Juniper’s director first selects logo direction B in concept document version 3. The final package is then reviewed against that selected direction and the following agreed requirements, rather than an unlimited instruction to “make it feel more premium.”

LOGO-1: the package contains the selected horizontal and stacked arrangements, each in full-color, black and white variants, as SVG and transparent-background PNG files. That is 2 arrangements × 3 color variants × 2 formats = 12 export files. Each PNG is 2400 pixels wide, with proportional height.

LOGO-2: SVG fills use the exact approved color values in palette sheet version 2. LOGO-3: the exported wordmark spelling matches the approved company name, and exported letterforms use outlines rather than requiring installation of a font. Evidence includes the file inventory, document properties and opened exports.

These checks establish conformity to the agreed package; they do not prove that a brand will appeal to every customer. If subjective direction still needs a decision, schedule that decision explicitly before treating final-file checks as the last hurdle.

Name review authority and preserve the version boundary

For the website example, director Elena is the authorized delivery approver. Noor runs the checks and provides evidence; the office manager verifies receipt in the test inbox. Their observations inform Elena’s decision but do not create competing approval authorities.

Record: “Review covers inquiry form build 18 against FORM-1, criteria version 2. Elena will return a decision by October 23. The linked evidence records the tested environments.” Keep the build or export snapshot available so the review link does not silently change underneath that decision.

A later build is not automatically covered by an earlier approval. Identify what changed and repeat affected checks, including connected behavior that could regress. Preserve the old result instead of overwriting it. Payment of an invoice is a separate event and is not evidence that these criteria passed.

Record failures, blockers and new requests differently

Use pass, fail or not tested for each criterion, together with evidence and the reviewer’s name. A blocked inbox test is not a pass. A failed required criterion means the agreed acceptance conditions have not all been satisfied, even if most of the work looks complete.

A mismatch against an agreed condition is a correction to assess under the existing agreement. A request for a new booking calendar is different work. Do not rewrite the original criteria retroactively to hide a failure or absorb a new feature. Record the proposed change, its effect and the authorized decision.

If the client accepts a known exception, describe exactly what is waived or deferred, by whom and for which version. That is a documented exception, not a claim that the original test passed.

A reusable acceptance record

Use this compact record for each item: “Deliverable and version: … Criteria set and version: … Review environment and inputs: … Criterion ID and expected outcome: … Actual result and evidence: … Authorized reviewer: … Decision and date: … Exceptions or follow-up: …” Keep the test observations distinct from the final acceptance decision.

Start with one deliverable this week. Ask whether another person could repeat the review and understand the decision without reconstructing a conversation. Moolamochi’s separation of agreement, delivery acceptance and payment supports that distinction; new access is currently waitlist-only.