Approving your relaunched website also means establishing whether visitors can complete the agreed tasks. A visible confirmation after submission is not enough: the enquiry needs to reach the right place and be processed successfully. Defining the expected outcomes beforehand lets you check these flows deliberately and resolve differences with development. A screenshot alone does not show this part of the site.
Identify the version before checking it
A reliable approval needs an identified version and environment. A preview with sample data may demonstrate the layout without showing the processing of the fully connected site. Documenting those differences makes it clear which parts remain open rather than accidentally treating them as checked.
Also name the person who consolidates feedback. A shared record keeps contradictory requests out of separate message threads. Each finding needs a URL, starting state, action and observed result.
Derive test cases from customer tasks
The shortest page using a template may not reveal many layout problems. Including long names, absent optional images and offers with different prerequisites gives you a better view of whether the structure works with everyday content. You can then follow the important journeys from those pages through to completion.
A test case for an enquiry flow can be recorded like this:
Start: the relevant service page
Task: send an enquiry about that service
Expected: enquiry stored with the selected service
Feedback: receipt confirmed, no appointment promised yet
Negative case: enter an invalid email address
Observed: [add the result and location]
Adapt the outline to the processing actually agreed. If the flow only delivers an email, record that outcome instead.
A complete test case also covers invalid input, expired sessions and failed storage. These show whether the page explains a problem rather than already confirming success. Sending an email and storing a record can be separate outcomes, so the feedback needs to match the processing actually agreed.
Include narrow screens and keyboard use
Following the same tasks on a phone and without a mouse reveals whether the journey works with different space and input methods. Understandable labels and visible focus help people find the next action; fixed bars must not cover it. Enlarged text can reveal further constraints missed by a normal desktop comparison.
W3C Easy Checks provides an initial review of titles, contrast, text size, keyboard interaction and forms. It is not a comprehensive assessment. Use it alongside the agreed evaluation scope and record what has not been checked.
The guide to relaunch redirect mapping covers old addresses separately. Before switching, confirm that destinations belong to the accepted site; afterwards, check the actual responses.
Decide what happens to outstanding issues
Deciding what happens to an unresolved item depends on whether it differs from the agreed behaviour or describes a new request. A record of that distinction, the person who decides and any missing information lets you establish what belongs to acceptance and what needs a new agreement.
The final list of completed, open and deliberately deferred items shows who still needs to act after the changeover. This includes responsibility for checking public pages, forms and important connections. Clearly identified test data and a prior agreement about real message delivery keep those tests distinguishable from customer enquiries.
Agree the evaluation scope when commissioning website and landing-page development. At approval, you can then return to the same pages and flows described for implementation.
