Before you sign off a new website, check that people can use it to do the things that matter. Test the main tasks, check the facts, and agree which faults must be fixed before launch. A site can look right and still send an enquiry to the wrong inbox.
Your review is not a substitute for your agency's technical checks. It adds the view only your team can bring: what your users need, what your content means, and what should happen next.
Agree what sign-off means
Start with the agreed brief and scope. List the key tasks the site must support. Then agree who will check each one, who can approve the work, and where to log issues.
Keep new ideas apart from faults. A form that fails to send is a fault. A request for a new booking tool may be a change in scope. Both deserve a clear answer, but they are not the same kind of work.
If your team is still unsure what the site needs to do, our guide to what a website brief should include can help you turn broad aims into clear checks.
Test a task, not just a page
Choose a short set of tasks that matter to your users. For example:
- Find out if a service suits your needs.
- Find the cost, dates or rules for taking part.
- Book a visit or send an enquiry.
- Find help when you do not know where to start.
These are sample tasks, not claims about a client project. Adapt them to your site. Start where a visitor might start, such as a service page or an old search link. Do not assume everyone enters through the home page.
For each task, write down what success looks like. For an enquiry, that may mean a clear form, a useful success message and a test email that reaches the right team.
Watch someone who does not know the site
People on the project know where things live. A new visitor does not. Ask people who match your users to try key tasks, including people with access needs where you can.
Give them a goal, not a set of clicks. Say, “Find out how to arrange a visit.” Do not say, “Open the menu and click Book a Tour.” Ask them to say what they are thinking. Watch where they pause or take a wrong turn.
This follows the GOV.UK guide to usability testing: use clear, neutral tasks and avoid hints that give away the answer.
A page that loads is not the same as a task that works.
A small round of checks can reveal useful problems. It cannot prove that every user will succeed, or replace a full access review.
Check the facts your agency cannot own
Your team should check names, dates, prices, phone numbers and policy text. Read the page as a visitor would. Is there enough detail to make a choice? Is the next step clear?
Check lists as well as single pages. The right items can all be present but in the wrong order. Look at news, staff, events and service lists. Check links to files and any content that appears in more than one place.
Use the agreed page list to track this work. Mark each page as checked, with an owner and a date. “Someone has seen it” is not a clear sign-off.
Test forms with a safe plan
Agree a test window with your agency and the team who gets the messages. Use made-up test data. Do not send real personal details or trigger a payment as part of an informal check.
- Send an agreed test entry from a phone and a computer.
- Check required fields and helpful error messages.
- Check the success message and any reply email.
- Confirm that the entry reaches the right inbox or system.
- Ask the tracking owner to check the agreed event, if tracking is in scope.
A form can behave differently on a test domain. Spam checks and third-party tools may need the final domain to work. Record what is still unproven and set a time to check it after launch. Do not mark it as passed because the form looks fine.
Sort issues by their effect
Keep one shared list. For each issue, record the page link, steps taken, what you expected and what happened. Add the device, browser and a useful image or short video.
Our guide to reporting a website bug explains what helps a team repeat and fix a fault.
Agree which issues block launch. A failed key form, wrong service details or a barrier to a key task should not be treated like a small spacing change. An access issue can be serious even if it affects only some users.
Once a fix is ready, repeat the failed task. A note that says “fixed” is a prompt to check, not proof that the task now works.
Make a clear launch call
Record who approved the site, what was checked, and which open items remain. Give each open item an owner and a due date. Ask your agency to confirm its own technical checks too.
Some checks need the live domain: redirects, search access, forms and tracking may need a final pass. Set that work up before launch, rather than leaving it to chance.
Sign off on evidence, not just a good first look. If you are planning a new site, talk to IGNITE about your launch plan. We can help define the key tasks, review roles and checks your team needs before it approves the work.