Practice · 18 June 2026 · 6 min
What a UX audit actually finds
Seven categories of problem that show up in almost every audit I run, and why the expensive ones are never the ones people expect.
Most people who ask me for an audit expect a list of interface complaints. Buttons in the wrong place. Colours that could be better. A navigation bar someone on the team has never liked.
That is not what an audit finds. After ten years of running them across automotive, medical, industrial and enterprise products, the findings fall into the same seven categories almost every time, and the expensive ones are rarely the visible ones.
1. The structure does not match the user’s model
This is the most costly finding and the least visible one. The product is organised the way the company is organised: by department, by database table, by which team built what. The user’s mental model runs along a completely different axis: usually by task, by object, or by time.
You cannot fix this with visual design. Every screen inherits the wrong structure. When an audit turns up a structural mismatch, everything else in the report becomes secondary, because fixing anything above it is decorating a building with a cracked foundation.
2. Steps that nobody defends
Walk the three tasks users actually come to do, end to end, and count the steps. Then ask, for each one, what would break if it disappeared.
The answer is often nothing. Confirmation screens that confirm something obvious. Settings collected before anyone needs them. A required field that exists because a form template had it. These accumulate quietly; nobody adds five steps at once, so nobody notices when there are five too many.
3. State that is implied rather than stated
Users are not confused by complexity. They are confused about whether something already happened.
Did the save go through? Is the upload still running or did it fail? Is this setting active now or when I click apply? Products routinely leave these questions unanswered, then treat the resulting support tickets as a communication problem.
I saw this most sharply on a clinical platform. In that context, an ambiguous state is not a usability annoyance. It is a safety issue, and once you have designed for that context, you stop tolerating it anywhere.
4. Errors that describe the system, not the situation
“Error 422: Unprocessable entity.” “Something went wrong.”
An error message has exactly three jobs: say what happened, say why it matters, say what to do now. Most say the first badly and skip the other two entirely. This is the cheapest category to fix in the entire report and the one most consistently ignored, because it is filed as copywriting rather than as design.
5. Accessibility failures that are also usability failures
I check against WCAG 2.2 AA, and there is a legal argument for doing so. But the more persuasive argument for most teams is that accessibility failures are usability failures wearing a different hat.
Contrast that fails at 4.5:1 is hard for everyone in sunlight. A form that cannot be operated by keyboard is slow for power users. A focus order that jumps around is disorienting whether or not you can see it. Touch targets under 44px are missed by everyone in a hurry.
Nothing on that list only affects disabled users.
6. Empty states that teach nothing
Every product has a first day, and most designs skip it. The dashboard with no data. The list with no items. The search with no results.
These are the highest-leverage screens in the product (the user is at their most uncertain and most open to instruction) and they are usually a grey box saying “No data available.”
7. Inconsistent vocabulary
The same thing called three names in three places. A status that is “pending” in the list, “in progress” in the detail view and “processing” in the email. Each was reasonable when written. Together they make the user wonder whether these are three different things.
This is where trust in a complex product quietly dies, and it never shows up in a single-screen review. You only find it by walking the whole flow.
What I do with all of it
Findings are only useful if they are ordered. Every one gets ranked twice: by severity, meaning how much damage it does, and by effort, meaning how hard it is to fix. That produces a list your team can start on the same week rather than a document that gets admired and archived.
The cheap-and-severe quadrant is usually where the first month of work lives. It is also, almost always, bigger than anyone expected.
I run UX audits for a fixed price, in a week. Here is what that includes.