UX Audit Checklist: What a Review Should Cover
By CodexierPublished 5 min read
A UX audit can be a fifty-page document of opinions or a short list of fixes that measurably improve enquiries and sales. The difference is method. This checklist describes what a proper audit covers, in the order the work should happen, so you can judge a proposal before you pay and judge the report when it lands. It applies to websites, webshops and web apps alike.
Goals and key tasks first
Before anyone looks at a screen, the audit should establish what the site is for and how success is measured: booked calls, quote requests, completed purchases, sign-ups. Then it names the key tasks: find the right service, understand the price, trust the company, contact or buy. Everything reviewed later is judged against these tasks. A beautiful page that does not help a key task is not a finding; a plain page that blocks one is.
Heuristic review of flows
The expert part of the audit walks each key task from entry to completion, on a phone and on a desktop, and records where the flow breaks. The reviewer uses established usability principles, but the output is specific: this step, this element, this problem, this fix.
- Entry: does the landing page match what the visitor searched for, and is the next step obvious within seconds?
- Orientation: can users tell where they are, what you offer and what it costs without hunting?
- Forms: are fields necessary, labelled, forgiving of formats, and do errors say how to fix them?
- Trust: are company details, organisation number, real people, terms and privacy easy to find?
- Mobile: are tap targets large enough, is text readable without zooming, does nothing important hide behind hover?
- Speed: does the page render quickly on a mid-range phone on a mobile connection?
- Completion: after the action, does the user know what happens next and when?
Analytics and drop-off data
Expert review finds possible problems; data shows which ones matter. The audit should pull your GA4 or equivalent, session recordings if you have them and consent for them, and search console data, and answer a short set of questions.
| Question | Source | What it tells you |
|---|---|---|
| Where do visitors enter, and from what? | Analytics landing pages, search console | Whether the entry pages match the key tasks |
| Where do they leave the key flows? | Funnel or path reports | Which step to fix first |
| Which devices convert worst? | Device breakdown | Whether mobile is the priority |
| Which forms are started but not sent? | Form events, recordings | Where friction lives |
| Which pages are slow? | Speed reports, field data | Whether performance is a UX problem |
If tracking is missing or broken, the audit should say so and propose a fix; guessing from opinion alone is the mark of a weak audit.
Accessibility checks
Accessibility is part of usability, not a separate compliance chore. The audit should test the key flows with a keyboard only, with a screen reader on at least one page, and with a contrast checker, and note whether headings, labels and alternative texts are in place. For companies covered by the accessibility act this is a legal need; for everyone else it is a cheap way to remove barriers that slow all users on a small screen in bright sunlight.
A prioritised fix list
The deliverable is a list, ordered by expected effect divided by effort, where each item names the change, the reason, the evidence and the rough size of the work. Quick wins go first so something improves within days; bigger items get a scope you can hand to a developer or use in a redesign brief.
| Priority | Typical items | Effort |
|---|---|---|
| Now | Broken form errors, unclear main call to action, missing prices or contact details, slow hero image | Hours |
| Next | Restructured service pages, simplified checkout or booking steps, mobile navigation | Days |
| Later | Information architecture changes, redesign of key templates, new content | Weeks |
When you do not need a UX audit: if the site is under a year old, was tested with real users before launch and has tracking that shows healthy flows, spend the money on content or traffic instead. If you already know you are rebuilding everything, put the audit's budget into the new design process. And if traffic is tiny, an audit's data section has nothing to work with; fix that first. Our UX audit follows this checklist exactly and is priced as a fixed package on the pricing page; a free 15-minute call is enough to tell whether it is the right next step for you.
Frequently asked questions
How long does a UX audit take?
A focused audit of a small site or a single funnel takes one to two weeks, most of it review and analysis. Larger apps take longer because there are more key tasks. Anything promised in a day is a screen-by-screen opinion, not an audit.
Do I need analytics in place before an audit?
It helps a great deal. Without data, the audit relies on expert review alone, which is still useful but cannot tell you which problem costs you the most. If tracking is missing, a good auditor sets up the basics first, then audits once a few weeks of data exist.
What is the difference between a UX audit and a redesign?
An audit diagnoses; a redesign rebuilds. An audit usually finds that a handful of changes deliver most of the gain without a full redesign, which is why it is worth doing first. If it concludes that the structure is beyond fixing, it becomes the brief for the redesign.
Can an audit help a webshop's checkout?
Checkout is the highest-value flow to audit because every friction point there costs a completed order. The review covers cart clarity, guest checkout, payment method visibility such as Klarna and Swish, shipping information, error handling and mobile layout, against your own drop-off data.
Want to know whether your site needs an audit or a fix?
Tell us your goal and where you think visitors get stuck. In 15 minutes we look at the key flow with you and say whether a full audit is worth it or whether two or three changes would do.
Book a free 15-minute call