What Is a UX Audit and What Do You Actually Get?

A UX audit is a review by trained evaluators, not a test with real users. The most common method is a heuristic evaluation: Nielsen Norman Group describes it as "a method for identifying design problems in a user interface", in which evaluators judge the design against a set of guidelines called heuristics (NN/g). The best-known set is NN/g's 10 usability heuristics: visibility of system status, error prevention, consistency, and so on.

Baymard Institute, which publishes large-scale e-commerce usability research, defines a UX audit as "a focused, systematic review that helps you identify the usability issues that are holding your site back", and names heuristic evaluation as one primary way of conducting one (Baymard). Baymard also draws the line we draw: usability testing shows how real people behave, and an audit explains why issues occur and how to fix them. The two are complementary.

Two method details from NN/g are worth knowing when you compare quotes. Ideally three to five people evaluate the same interface independently, so one reviewer's taste doesn't become the whole report. And a heuristic evaluation "cannot replace user research": it tells you where the likely problems are and which questions are worth testing with people.

A worthwhile audit works through the same four lenses on every page that matters: the homepage, the top service pages, the contact or booking path, and whatever page the site is actually built to sell.

Table · scrolls sideways

None of these is checked in isolation. A page can pass an accessibility scanner and still fail a person because the button doesn't look clickable. The reviewer goes through each page with a task in mind, such as "book a consultation" or "get a quote", and notes exactly where that task gets harder than it needs to be.

Automated tools do a first pass. Lighthouse covers performance and some accessibility checks, and a scanner such as axe covers more accessibility basics. A proper audit uses them, because nobody should check by hand what a tool checks in seconds. What a tool can't judge is whether the menu matches how a visitor thinks about their problem, or whether the third form field is the reason people abandon the booking flow. That judgement is what you are paying a person for.

The output is a list, not an essay. Each item names the page, the element, what is wrong, why it matters, and a rough size: small, medium or structural.

• Useful: "Contact page, on a phone: the submit button sits below the fold after the form is filled in. Move the button up or shorten the form. Small fix."
• Useless: "Consider improving your call to action."

The first can go straight to a developer. The second is good taste with no instructions attached. Screenshots or a short screen recording usually go with the list, because "here is the exact spot" beats "somewhere on this page". If performance is in scope, the raw Core Web Vitals numbers belong in the report, not just a pass or fail label.

Ask, before you pay, whether findings are ranked. A report that marks all 47 items "high priority" leaves you to do the prioritising yourself.

The Redline is the free entry offer we use to start every project, and it is a narrow form of audit. We mark up your homepage by hand: what to cut, what to add, and why. It answers one question, whether anything obvious on the front door is costing you enquiries, and it is enough to decide whether a fuller audit or a redesign is worth pursuing next.

The paid version is the Full Redline: your key pages marked up the same way, with the rules that apply to your sector. It is a fixed price, quoted in writing before any work starts, and the fee is credited against a build. We are deliberately not publishing a page count, price or turnaround here until those are confirmed; the Redline page carries the current wording.

What the Redline is not: it is not usability testing with your customers, and it is not a substitute for watching real people use your site. When a finding depends on behaviour we can't see from the page, we say so and suggest how to test it.

Here is the market context, with a clear label: these are vendor-reported figures from agencies' own price guides, in US dollars, read on 15 October 2026. They are not an independent survey.

Table · scrolls sideways

Both guides name the same price drivers: who does the work (freelancer, agency or tool), how many flows and screens are in scope, whether research such as usability testing is added, and whether accessibility testing, which is mostly manual, is included. Whether the auditor gets analytics access (GA4, Search Console, heatmaps) also changes what the report can say. Without it, an auditor points out likely friction. With it, they can point at the page where visitors actually leave.

These solve different problems, and doing the wrong one first wastes money either way.

Table · scrolls sideways

If the honest answer is "the whole thing", an audit will mostly confirm what you already suspect. If you're replacing the site, read how to redesign without losing rankings before anything moves.

A fix list built for handoff should be usable by anyone with basic web skills. Small fixes, such as copy changes, image compression and contrast adjustments, are reasonable for an in-house person or a freelancer. Structural fixes, such as a broken information architecture, a slow platform or a form that needs rebuilding, usually need a developer whoever wrote the audit.

A sensible order: clear the small items first, because they are cheap and easy to check. Schedule medium items into your next content or development cycle. Treat structural items as a separate project decision. Sometimes the answer is a redesign, and the audit's job was to tell you that with evidence instead of a hunch.