UX audit

The problem this solves

Most audits arrive as a list of heuristic violations. Contrast is low here, the label is ambiguous there, this button is below the fold. All true, all cheap to write, and none of it says which one is costing you money.

The reason is that a heuristic review never leaves the screen. It cannot tell you that people abandon the plan comparison because they lose their place scrolling between two cards, because that is not a property of a screen — it is a property of a task carried out over several of them.

So the useful audit starts from the job rather than the interface: what someone came to do, where the product made them stop, and what it cost when they did. That ordering is the whole deliverable. A ranked list of four things is worth more than an exhaustive list of forty, because the exhaustive one gets read once and archived.

What you get

• A findings document ordered by cost

  Each finding written as the task it breaks, the evidence it rests on, and what it is plausibly costing. Ordered so the first three are the ones to argue about.

• Session evidence, not opinion

  Clips or annotated recordings behind every significant finding. A finding nobody can watch happening is a preference, and it will be treated as one in the room.

• A ranked fix list your team can act on

  Split by effort: what a front-end engineer can ship this week, what needs a design decision, and what is a roadmap item wearing a UX costume.

• A walkthrough with the people who will build it

  One session, recorded. Documents get skimmed; the conversation where an engineer pushes back is where a finding turns into a ticket.

How it runs

1. 1

   Agree what the product is for

   The two or three jobs it exists to support, and which of them the business actually earns from. Everything downstream is scored against this.

2. 2

   Read the analytics, then distrust them

   Funnels and event data say where people stop. They are the map of where to look, never the finding itself.

3. 3

   Watch real sessions

   Recordings, or moderated runs with people who fit the job. This is where the reason shows up, and it is usually not where the drop-off is.

4. 4

   Work the tasks end to end

   Including the states nobody demos: empty, partial permissions, slow network, too much data, and the second visit rather than the first.

5. 5

   Rank, write, and hand over

   Findings ordered by cost, split by effort, walked through with the team that has to ship them.

The longer version of this, with what happens in each week, is on the process page.

Where this has been done

• Consumer VPN pricing and checkout

  18% higher checkout CTR, 35% faster page load

  GA4 showed where people left the pricing page and nothing about why. Session recordings did: visitors were comparing plans by scrolling between them and losing the comparison each time. The finding rewrote the page around the decision rather than the catalogue.

• Symantec CloudSOC, for Broadcom

  20% higher retention, 35% fewer UX support tickets

  Twelve sessions with security analysts changed the direction of the redesign. Policy creation and alert triage were reworked around how fast a decision could be made under pressure, which is not what the original brief asked for.

Typical engagement

Two to three weeks for a single product, and it ends in a document and a walkthrough you can act on with or without me. A multi-product suite, or a product with two distinct user types who barely overlap, runs longer because the tasks have to be worked separately rather than sampled.

An audit is deliberately a standalone piece of work. It is often the honest first step before a redesign is scoped, because it is the cheapest way to find out whether you need one.

Who this is not for

• You want a second opinion that confirms a decision already made. An audit that cannot change the plan is an expensive formality.
• Nobody can give me access to real users or real session data. Without evidence this becomes a heuristic review, which you can get anywhere and should trust less.
• You want the fixes designed as part of the same fee. That is a separate piece of work, and pretending otherwise makes both worse.
• The product has not shipped yet. Nothing to audit — a sprint is the shape that fits.

How I think about this

• Hick's law is not a rule about having fewer options — the finding an audit keeps making, and why deleting choices rarely fixes it
• Five users is per group, and almost nobody reads it that way — how many sessions an audit actually needs, and per what
• Ask about last Tuesday, not about next quarter — the difference between evidence and a prediction someone made up to be helpful
• Your team is not a sample: where dogfooding stops working — why internal opinion keeps producing the wrong ranking

Frequently asked questions

How long does a UX audit take?

Two to three weeks for a single product. That covers agreeing the jobs, reading the analytics, watching sessions, working the tasks end to end, and writing findings you can hand to an engineer. Longer if there are several products, or two user types whose tasks share almost nothing.

What is the difference between a UX audit and usability testing?

Usability testing is one of the methods an audit uses. The audit is the wider piece: analytics, session evidence, task walkthroughs across the states nobody demos, and then the ranking. Testing tells you whether a task works. The audit tells you which broken task to fix first.

What do you need from us to run one?

Access to the product with realistic data, whatever analytics you already have, and either session recordings or a way to reach four or five real users. If none of that exists, say so early — it changes what the audit can honestly claim.

Do you fix the problems you find?

Often, but as separate work quoted after the audit rather than bundled into it. Keeping them apart is what lets the findings be uncomfortable: an audit priced as the front half of a redesign has an obvious incentive to recommend one.

Will the findings be specific enough for our engineers?

That is what the walkthrough is for. Every finding names the task it breaks and the evidence behind it, and the fix list is split by effort so the week-one items can go straight into a sprint without a design round.

What timezone do you work in?

Karachi, UTC+5. That overlaps most of the European working day and the US East Coast morning, so sessions and the walkthrough get scheduled at your end of the day rather than mine.