A Website Review Checklist That Starts with the User’s Task

1. Pick one task and define what success looks like

Write the task in the visitor’s language: ‘Find out whether the studio offers weekend appointments and request one.’ Avoid instructions that give away the interface path, such as ‘Click Services, then Appointment Types.’ The first version lets a reviewer see whether the page itself makes the route discoverable.

Before you begin, record the expected end state. For this example, success means the visitor can identify weekend availability and reach a request confirmation. Also note what is outside scope—for example, whether a real appointment can be booked—so a reviewer does not confuse a prototype limitation with a usability issue.

2. Follow the task without narrating the design for the visitor

Move through the page as a new visitor would. Note where you look first, what labels you interpret, what you skip, and where you hesitate. If you are observing another person, ask them to say what they are thinking, but do not explain what a control means or point them toward the next step. Those interventions hide the very confusion the review is meant to reveal.

A review by colleagues can identify broken links, inconsistent language, and obvious interaction problems. It cannot establish how representative customers will behave. If the decision has meaningful user or business risk, include people who match the audience and observe them completing the task with minimal prompting. GOV.UK’s research guidance explains why observing real users doing their actual work can reveal needs and barriers that interviews alone miss.

GOV.UK Service Manual: how user research improves service design

3. Inspect the states around the happy path

Do not stop when the main button works once. Check what a visitor sees before entering data, while something is loading, after a successful action, and when an input is missing or invalid. Follow any confirmation link and check whether the page explains what happens next. If the team cannot safely trigger a state, record it as unreviewed instead of assuming it works.

• Can the visitor tell which fields are required before submitting?
• Does an error identify the field and explain how to fix it?
• After submission, is the result clear and is duplicate submission prevented or explained?
• Do back, cancel, close, and retry actions preserve the visitor’s work where expected?
• Do links lead to the promised destination, including on a narrow screen?

4. Make a short accessibility pass, then escalate what needs a full audit

Use the keyboard to move through the page and operate its controls. Check that focus is visible and follows a sensible order, form controls have understandable labels, headings describe the content beneath them, and meaningful images have text alternatives. Resize the page and check that text and controls remain usable. These are useful first checks, not proof that a page conforms to WCAG or is accessible to everyone.

W3C’s Easy Checks are deliberately a first review, not an exhaustive assessment. When the site is subject to a conformance requirement or has high accessibility risk, use an appropriate evaluation method and include people with disabilities in research; do not treat a quick checklist as a compliance certificate.

W3C WAI: Easy Checks – A First Review of Web Accessibility

W3C WAI: Understanding WCAG 2.2

5. Check the same task at the size people actually use

Repeat the task at a narrow viewport and at the desktop size relevant to your audience. Look for content that changes order, actions hidden outside the viewport, sideways scrolling, text that is clipped, and dialogs whose primary action is hard to reach. A screenshot catches a visual state; it does not show whether the task or keyboard path works, so pair captures with notes about what you did.

6. Write the finding so someone else can reproduce it

Record the URL and state, device or viewport, starting point, action, observed result, expected result, and user consequence. Separate a confirmed observation from a possible fix. For example, a reviewer may observe that the error appears only after the form is submitted and disappears when the visitor changes a different field; that evidence is more useful than a screenshot caption that says ‘form is broken.’

Prioritize blockers and repeated friction ahead of cosmetic preferences. Explain the basis for priority—such as whether the visitor can finish the task, how often the path is used, and whether a workaround exists. Avoid a precise impact score unless the team has agreed what the score means and has evidence to support it.

• Page and state: where should the reviewer start?
• Action: what did the visitor do?
• Observed / expected: what happened, and what did they expect?
• Impact: which task or audience is affected, and how?
• Evidence: what can another person use to reproduce or verify it?