How to conduct a UX audit

Conducting a UX audit means walking the experience cold before you examine it, running a structured checklist over the same screens afterwards, sorting what you find by what it costs rather than what it takes to fix, and writing each finding so that someone who was not there can act on it.

The order carries most of the value. Almost everyone does the structured pass — that is the part that feels like work. The cold walk is what people skip, and it is the only part that produces findings the reviewer could not have predicted.

What do you need before you start?

You need the URL, a private browser window, one sentence stating what the page is for, and somewhere to write things down as they happen. Analytics, session recordings and research findings are useful if they exist, but the audit is not blocked without them — they narrow where you look, not whether you can look.

The one thing worth insisting on is the sentence about what the page is for. “Get qualified visitors to start a free trial” and “get anyone to hand over an email” are different jobs, and a page can be excellent at one while failing at the other. Without that sentence you are not auditing; you are reacting.

Write it before you open the page. Once you have looked, you will unconsciously write the job description that the page happens to satisfy.

Step 1: State the job of the page

Write one sentence naming the visitor, what they are trying to do, and what success looks like for the business. Everything after this is measured against it. A finding is only a finding if it gets in the way of that sentence — without one, every audit degenerates into a list of things the reviewer would have done differently.

Two examples of the difference it makes:

• “A developer evaluating whether this can replace their current tool wants to see the pricing model before they invest time.” Now a missing price is a blocker, not a preference.
• “A marketer sent here from an ad wants to know if this handles their use case before they give up an email.” Now a long form is a blocker and the missing price is barely relevant.

Same page. Different audits. Both correct.

Step 2: Walk it cold

Open the page in a private window and go through it once at normal speed, recording every moment of hesitation as it happens. Do not fix, do not analyse, do not go back. The output of this pass is a list of moments — where you paused, what you expected, what surprised you.

This is the pass that expires. The moment you have examined a page closely you can no longer experience it naively, and notes reconstructed afterwards are notes about what you now know rather than what you first felt. If you skip this step you can never go back and do it.

Practical notes:

• Record, do not remember. Talk out loud into a voice memo, or type as you go. Anything you plan to write up later is already contaminated.
• Go at real speed. Reading every word carefully is the second pass. This one is the speed a visitor actually moves at.
• If you built it, get someone else. You cannot un-know your own product. Fifteen minutes of watching someone else try is worth more than an hour of you pretending.

The kinds of things this pass catches: a headline you had to read twice, a button whose consequence was unclear, a moment of “wait, how much is it?”, a form field that made you stop and think about whether to continue.

Step 3: Run the structured pass

Go back through the same screens against a defined list of questions, in a fixed order, writing down what you see rather than how you feel about it. This pass catches the things a visitor would never articulate — the ones they experience as vague friction rather than as a specific problem.

Using a published list matters more than which list. It makes the audit repeatable, it makes it arguable, and it stops the findings being a record of whatever the reviewer happened to notice that day. Nielsen’s ten heuristics are the classic set; the checklist I use is 26 questions grouped into four lenses, and either works.

Whatever list you use, run it in a consistent order. Working the same sequence every time is what makes two audits comparable, and comparability is most of what a score is for.

Step 4: Sort by cost, not by effort

Order every finding by what it is costing the business, then — and only then — note how hard each is to fix. These are two different sorts, and merging them is the single most common way an audit ends up feeling productive while changing nothing that matters.

Effort-first ordering is seductive because the top of the list is achievable. The result is a week of shipping copy tweaks while the broken step in the signup stays broken, because it was the hard one.

A workable way to hold both:

List	What it costs	What it takes
Critical blockers	High — people leave, or finish with the wrong expectation	Often needs a decision before a designer
Quick wins	Lower individually	Shippable this week, no redesign

Both lists are useful. They are just not the same list, and the report should not pretend otherwise. How severity gets decided is worth writing down once so you are not re-litigating it every audit.

Step 5: Write findings someone can act on

Each finding needs three parts: what you observed, why it costs something, and what specifically to change. A finding missing the third part is an observation. One missing the second is an opinion. The test is whether a person who was not in the room can act on it without asking you a question.

Compare:

❌ The signup form is too long.

✅ The signup form asks for company size and phone number before the visitor has seen the product work. Both are useful for sales routing, and neither is needed to create an account — a visitor who is still evaluating reads them as a sales trap and some close the tab. Move both to the first in-product screen, after activation.

The second one costs three sentences instead of one, and it survives being forwarded to a developer who has never spoken to you. That is the whole difference.

Two habits that make findings survive contact with a team:

1. Name the mechanism, not the vibe. “Feels cluttered” cannot be actioned. “Four elements compete for the first click” can.
2. Leave room to be wrong. State what you could not see. A reviewer working from outside does not know your constraints, and a finding that acknowledges that gets argued with productively instead of dismissed.

How long should a UX audit take?

For one page or one flow, expect two to four hours of examination and about the same again to write it up properly. Anything under an hour is a checklist run without thought; anything past a couple of days for a single page is usually scheduling, meetings and formatting rather than analysis.

The write-up genuinely takes as long as the looking. That surprises people, and it is why so many internal audits end as a list of bullets in a doc nobody opens — the examination happened and the translation into something actionable did not.

What makes an audit useless

• No stated job for the page. Findings become preferences.
• Skipping the cold walk. You get only what a checklist can see.
• Sorting by effort. The important thing stays undone.
• Thirty findings. Read once, actioned never. Lead with three.
• No reasoning attached. Nobody can disagree with it, so nobody engages.
• Auditing something you cannot change. True and useless in equal measure.

---

Once you have run this on your own page, the natural next question is what the output should look like — what goes in a UX audit report covers the deliverable, and the teardowns show the whole process applied end to end on pages you already know.