Top view of a business meeting table with digital devices and financial documents, showing collaboration.
Photo by Tiger Lily on Pexels

Operations

Web design agencies launch review: evidence checklist

A web design agencies launch review checklist of release, accessibility, data, security and rights evidence to request from an agency before launch.

What to take away

  • For a live project, missing evidence means holddesk research sets criteria, not findings about that project.
  • Lift hold only after the release is identified, a named acceptance owner is assigned, open defects are disclosed and dated test records are supplied.
  • Accessibility needs manual observations plus fixes and retests, not one automated scan.
  • Data, security and rights evidence must match the live configuration.
  • Only a reviewer identified by name and role, with project evidence, may record proceed and attach monitoring and restart conditions.

Checklist scope and disclosure

This web design agencies launch review checklist is for clients assessing an agency's launch readiness. It does not inspect or compare a named agency, client or live service.

No project pack was supplied for a live assessment: there is no release candidate, signed contract or test record to inspect. For any project, a proceed decision without those artefacts would be fiction; missing evidence means the practical outcome remains hold until an authorised reviewer checks it.

Criteria referenced: the GDS reliable-service standard and GDS accessibility testing guidance; NCSC secure-development guidance; the ICO contract checklist and PECR/cookie guidance; and IPO copyright guidance. These provide criteria for a checklist, not findings on a supplier or project.

Conflicts: no supplier funding, free product, affiliate link, client relationship or agency submission. Hands-on boundary: none. No repository, contract, data map, security report, accessibility audit or user study was inspected.

What desk research can establish

Guidance pages set the criteria a reviewer applies. They describe reliable operation, accessible testing, contract content and secure development. They say nothing about your build.

The GDS reliable-service standard asks teams to test close to live and keep quality assurance under team oversight. That expectation transfers into a private brief as a testable clause.

Legal duties sit alongside it. The Equality Act 2010 covers reasonable adjustments, including accessible websites. Customer data falls under the Data Protection Act 2018 and UK GDPR. The CMA and the ASA advertising codes cover fair terms and promotional claims.

So the criteria are public. The findings are not.

Evidence needed to leave hold

A web design agency or website design company working on an England project should already hold the following records.

  1. Fix the release identity. Supply a versioned artefact, content and configuration inventory, dependency record, approved scope and a named acceptance owner. Attach the open-defect list.
  2. Supply accessibility results. Give the agreed journeys, browsers, devices and assistive technologies, with automated findings, manual observations, fixes and retests. The GDS accessibility testing guidance is written for public services, yet it shows why one scan is incomplete.
  3. Map data and storage access. Record every form field, account, recipient, analytics call, tag, purpose, retention rule and transfer. Compare the agency processor terms against the ICO contract checklist, and test cookies against ICO PECR guidance. For the commission itself, use the contract guide to verify that scope, deliverables, acceptance, ownership, support and exit are recorded.
  4. Present security and rights evidence. Request a security report that records its scope, environment, findings, severity, remediation and retest. The NCSC developer guidance covers repositories, build, deployment and flaw handling. Request a rights schedule tracing code, copy, photography, fonts, libraries and design assets. The IPO notes that commissioned copyright often stays with the creator unless a written agreement changes it.

Example: a retest record a reviewer will accept

A complete retest traceability record has seven fields: ticket, journey, environment, finding, severity, owner and retest. The example below shows only ticket and journey from that record; it is an illustration, not a real project entry. Replace every value with your own data.

Retest record example

FieldWhat the reviewer needsIllustrative entry
TicketTraceable identifierACC-114
JourneyNamed user pathGuest checkout to confirmation
EnvironmentBuild, browser, device, assistive technologyBuild 4.2.1, Chrome, Windows 11, NVDA
FindingWhat failed and whereCoupon field has no accessible label
SeverityAgreed scaleHigh
OwnerPerson accountable for the fixNamed front-end developer
RetestDate, method, resultManual retest passed after the fix

An open-defect list should record the identifier, journey, environment, finding, severity on the agency's stated scale, owner, target date, status and retest result. Ask the agency to define its severity scale rather than infer one from desk research. A reviewer reads the status column first.

Decision record and restart conditions

The final decision must name the reviewer and their role, which artefacts they reviewed, what was tested, unresolved limitations and the exact release version. A failed mandatory gate on privacy, PECR, accessibility, security, IP, advertising, consumer law or contract keeps the outcome at hold.

Proceed is available only to authorised reviewers holding project evidence. They should attach monitoring duties and restart conditions for support, incident, correction, change and exit before release.

Before you act

  • Identify the exact release and the named acceptance owner.
  • Supply the versioned artefact and configuration inventory.
  • Provide accessibility results with fixes and retests.
  • Map every form field, account, tag and retention rule.
  • Present security and rights evidence with named owners.
  • If the release includes a migration, rehearse it with backup restoration and rollback.

Common questions

Why is the verdict hold rather than proceed?

The article does not issue a project-specific verdict: nothing was supplied to inspect. For a real project, missing evidence means hold; desk research offers criteria only, so a proceed decision would rest on assumptions instead of artefacts. The listed records are what a named reviewer needs before changing that outcome.

What accessibility evidence does a reviewer need?

The agreed journeys, browsers, devices and assistive technologies, with automated findings, manual observations, fixes and retests. Record the assistive technology versions as well. One scan is not a result.

Do promotional claims and prices need separate evidence?

Yes. Each advertised price or promotional claim should have a source row recording its source and relevant conditions before release. The advertising check ties each claim to the evidence row used in the final decision; this general checklist does not verify any actual prices.

What must the final decision record contain?

Who reviewed which artefacts, what was tested, unresolved limitations and the exact release version. A failed mandatory gate keeps the outcome at hold, and only authorised reviewers holding project evidence may record proceed.

More in Operations