A UX audit is a structured diagnosis of how people complete important website tasks. This checklist helps teams define priority journeys, document observed navigation, content and accessibility barriers, attach evidence, and decide whether to investigate, test or improve each finding. It is designed to guide evaluation before implementation choices are made.
- Frame the audit around user goals and complete journeys, not a list of pages or visual preferences.
- Record each finding with its context, observed barrier, supporting evidence and next decision.
- Include keyboard, focus, form and content-structure checks, while recognising that an audit is not an accessibility conformance claim.
- Prioritise by task importance, observed interruption, recurrence and evidence strength rather than a universal score.
A UX audit is a structured review of what happens when people try to complete important tasks on a website. It records journey barriers, navigation and content problems, accessibility observations and supporting evidence before a team chooses what to change. It is a diagnosis, not a responsive-design build guide, performance-tuning plan or promise that a change will produce a particular outcome.
What a Useful UX Audit Produces
The useful output is an evidence log, not a long list of design opinions. Each finding should name the task, the point where progress becomes harder, what was observed, the evidence available and the next decision. This format makes it easier to separate an apparent issue from a proven one, combine repeated patterns and leave lower-confidence questions open for research.
| Finding field | What to record |
|---|---|
| Task and context | User goal, entry point, device and relevant state |
| Observed barrier | Where progress became harder and what happened next |
| Evidence | Screen, note, analytics pattern, support theme or research observation |
| Decision | Investigate, change, test with users or defer, with a named owner |
Run the Audit as a Structured Review
Start with Tasks and Context
Choose the tasks that matter to the site and phrase them as user goals, such as finding the right service, comparing an option, making an enquiry or getting help. State the entry point and the expected end point. Then note the context to check: a small screen or desktop, a new or returning visitor, and any sign-in, location or form condition that changes the path. A precise task keeps the review anchored in behaviour rather than page-by-page preference.
Walk the Complete Path
Follow each task from its likely landing page to its completion or stopping point. Check whether navigation labels predict what they contain, whether a visitor can return without losing their place, and whether calls to action make the next step clear. Include empty, error and confirmation states where they exist. Record the exact page or component and the action that caused the problem; “navigation is confusing” is too vague to act on.
Check Clarity at Decision Points
At each decision point, ask what the visitor needs to understand before continuing. Review headings, short descriptions, button labels, form instructions, errors, eligibility details and any information that sets an expectation. Look for terms that make sense only to the organisation, important conditions placed far from the action, or several competing next steps. Mark the missing question, not just the text that looks weak.
Include Accessibility in the Same Review
Use accessibility as a practical review lens: can a keyboard user reach and operate the path; is focus visible; are form controls and errors understandable; and do headings and links communicate structure and purpose? WCAG 2.2 groups accessibility guidance under perceivable, operable, understandable and robust principles. Consult the W3C’s guidance when recording a specific concern. An automated check can help reveal candidates, but W3C notes that knowledgeable human evaluation is required to determine whether a site is accessible.
Gather Evidence Beyond the Walkthrough
Compare the walkthrough with evidence the team already holds, such as analytics patterns, search terms, support themes or session notes. Treat each source as a clue with limits: an exit pattern may show where people leave, but not why. When the question is important, observe likely users attempting a realistic task. GOV.UK describes moderated usability testing as watching participants complete specific tasks and recommends asking them to think aloud; this can expose language and layout problems that a desk review cannot settle.
Turn Findings into Decisions
Group observations that describe the same barrier, then decide what deserves attention first. Consider how central the blocked task is, how severe the interruption appears, whether the issue affects more than one journey or context, and how strong the evidence is. These are prompts, not a universal score. A clear barrier on a core path with repeated evidence may justify action; a plausible issue with thin evidence may instead need a user test or a narrower investigation.
UX Audit Checklist
- Name the user goal, entry point, context and finish point for every path reviewed.
- Walk the path without using internal knowledge or shortcuts.
- Check that navigation, headings and calls to action predict the next step.
- Record unclear information, competing choices and missing form guidance at decision points.
- Try the essential path with a keyboard and note focus, labels, errors and feedback.
- Attach the most relevant evidence to every finding and label its confidence.
- Combine duplicate observations rather than counting the same barrier repeatedly.
- Assign a next decision, owner and follow-up method to each priority finding.
Fictional Finding Example
Fictional example: a visitor arrives on a service page and selects “Get started.” The button opens a form that asks for project information before explaining what response the visitor can expect. A keyboard walkthrough also reaches an error summary that does not make the next correction obvious. The record should identify the service-page-to-form journey, attach the screen and keyboard notes, and separate the observed facts from the proposed change. Because the form affects a central enquiry path, the team may choose to test clearer expectation-setting and error guidance with likely users before wider changes.
What This Checklist Cannot Establish
A UX audit can identify visible barriers and turn them into testable questions. It cannot prove that every visitor behaves the same way, reveal motives from analytics alone or establish full accessibility conformance. It can also miss paths that depend on real accounts, data or assistive-technology setups. Use the audit to choose the next evidence-gathering or improvement decision, then validate consequential changes in the relevant context.
Sources Behind the Checklist
This checklist uses W3C WCAG 2.2 for accessibility review framing, W3C accessibility-evaluation guidance for the limits of automated checks, and GOV.UK guidance for task-based usability observation.
This guide was prepared with AI-assisted, source-linked research. Examples are illustrative; confirm current platform settings and policies for your own business.
Fresh thinking from Technogital.
Let’s put it into action.
