Website redesign / Delivery
How to Write Acceptance Criteria for a Website Redesign
Acceptance criteria turn a broad promise such as “the new website will be responsive and easy to manage” into observable conditions both sides can review before approval.
Connect criteria to the agreed scope
Start with the page types, content, functionality, integrations, browsers, devices, accessibility target, performance expectations, analytics, migration, and launch responsibilities included in the project. Acceptance criteria should confirm that agreed work is complete, not introduce new requirements at the end.
Record assumptions and exclusions beside the criteria. If content, third-party systems, translations, legal approval, or product data come from the client, state the required format and deadline. The website design contract guide explains where scope, responsibilities, and change control should be established.
Write conditions someone can actually test
Use observable statements. Instead of “the form works well,” specify required fields, validation, consent, confirmation, notification recipient, CRM result, analytics event, error behaviour, and supported devices. Instead of “pages load quickly,” name the agreed measurement method, pages, connection or device assumptions, and threshold.
Avoid prescribing implementation unless the method is itself a requirement. Criteria should usually describe the result a user, editor, or connected system needs. Include examples and test data for complicated rules, especially calculators, filters, account states, payments, and integrations.
Cover content, experience, operations, and recovery
Include page completeness, approved copy and assets, navigation, search, responsive behaviour, keyboard use, focus states, contrast, forms, integrations, analytics, consent, redirects, metadata, structured data, CMS permissions, backups, error pages, and monitoring where they are in scope.
Define what happens when a dependency fails. A visitor should receive a useful message; data should not silently disappear; the right person should be alerted; and a safe retry or manual process should exist. Criteria for failure states prevent teams from approving only the happy path.
Agree who tests, fixes, and signs off
Create a shared acceptance list before development is complete. Assign a tester and approver for each area, prepare accounts and test data, and schedule time for user acceptance testing. Classify findings as defects, content changes, scope changes, or future improvements so every comment does not become a launch blocker.
Define the correction window, retest method, final approval, and treatment of minor known issues. Use the pre-launch testing guide to turn the criteria into a practical launch check. Acceptance works best as a continuous reference, not a surprise inspection at the end.
Make “done” clear before launch week
Need a redesign scope your team can review objectively?
Northform can translate goals and requirements into a page system, delivery plan, and testable launch standard.
Discuss your website redesign Explore website redesign services →