Key takeaways
- A finding without a fix is a note. Every row in the audit needs evidence, the issue in plain language, and a buildable fix.
- Walk representative routes — quote, book, buy — not homepage screenshots in a deck.
- Severity ranks the backlog. Blockers ship before polish so the audit becomes tickets, not theater.
You paid for a UX audit. You got forty-seven slides, a heatmap, and zero tickets in the backlog.
That is how a website UX audit fails before anyone ships. The deck looked finished. Nobody could tell a developer what to change on Tuesday. A finding without a fix is a note. Evidence without a route is a screenshot. Severity without a rubric is opinion dressed as research.
A buildable audit names one representative path, records what broke, ranks it, and writes the fix in words a builder can implement. Not "confusing navigation." A label, a criterion, a component, a acceptance check.
A finding without a fix is a note
UX audit severity is for the backlog, not the cover slide. The job is not to prove the site feels bad. The job is to turn a stranger's attempt into work someone can schedule.
That means three fields on every row:
- Evidence — what you saw, where, under which conditions. URL, step, viewport, input method, screenshot or recording ID.
- Issue — what the stranger could not do or had to fight to do. Plain language. No jargon handshake.
- Fix — what to change so the route works next time. Specific enough to estimate.
"Weird menu" is not a row. "Hamburger opens on click but focus never returns to the trigger after close; keyboard user cannot reach the quote button" is a row. The fix names the component behavior, not "improve UX."
Heatmaps show where people paused. They do not say what to build. Pair them with a walked route.
How to structure a homepage is the orientation layer most audits skip. Eight service tiles on the first screen means every route downstream fights a catalog.
Run the representative-route protocol
Choose one route that carries money or leads. Request a quote. Book a call. Buy the SKU. Apply. Subscribe. Not "the site." One path a paid visitor is supposed to finish.
Walk it as a stranger would. No admin login. No devtools open on the first pass. Phone in hand or keyboard on the desk — match how the traffic arrives.
Complete the route four ways:
1. Keyboard only, pointer untouched. 2. At 200% zoom on a narrow viewport. 3. With sound off when video carries the offer. 4. With reduced-motion preferences enabled.
At each step, stop when the route becomes unclear, invisible, unreachable, or exhausting. Record the step number, what you tried, what failed, and a screenshot or clip ID. That is evidence.
Map each failure to a criterion when accessibility is in scope. WCAG 2.2 is the public checklist for whether a stranger can use the interface — focus not obscured, targets large enough, labels present, captions when speech carries the claim. The W3C — Web Content Accessibility Guidelines 2.2 and W3C WAI — Easy Checks are the references to cite in the row, not a proprietary score.
Accessibility is conversion work is the same route from the other side of the glass. A form nobody can finish is not a UX polish item. It is a blocker on the quote path. Accessible forms is the teardown for that step: labels, errors, and keyboard recovery on the send button.
Score the walk before you write recommendations:
| Question | Strong answer |
|---|---|
| Route | Named path from entry to success state |
| Evidence | Step, condition, and artifact per failure |
| Issue | What the stranger could not do, in their words |
| Fix | Buildable change a developer or writer can schedule |
If you cannot fill the fix column, you are not done auditing. You are annotating.
Write evidence, issue, fix on every row
A UX audit checklist that ships work looks like a table, not a narrative. One row per failure. No merging five problems into "mobile experience."
Example row:
| Evidence | Issue | Fix |
|---|---|---|
| Step 4, iPhone 14, keyboard: tab order jumps from email field to footer social icons, skips submit | Cannot reach Send without a pointer | Reorder DOM to match visual order; add skip link that targets main; verify tab reaches submit before footer |
The issue column is what the stranger would say if they emailed you. The fix column is what engineering and content need. If the fix requires a design decision — "replace hero video with static headline" — say that. If it requires copy — "rename button from Submit to Request a quote" — say that. If it requires code — "trap focus inside modal until dismissed" — say that.
Do not hide fixes in a recommendations appendix. Group rows by route so marketing, design, and development read one path top to bottom.
Rank with a severity rubric
Severity is how the backlog gets ordered. Without a rubric, every stakeholder argues from fear. With one, blockers ship first.
| Severity | Definition | Example |
|---|---|---|
| Blocker | Route cannot complete | Form unreachable, payment fails, account cannot be created |
| Major | Route completes with wrong outcome or hidden failure | Error not announced, price changes without warning, success state missing |
| Friction | Route completes with excess effort | Tiny tap target, focus hard to follow, redundant steps |
| Polish | Redundant naming, verbose labels, cosmetic inconsistency | Duplicate headings, icon without text where text is cheap |
Blockers go to the top of the sprint. Major items follow. Friction and polish wait unless the route is already clean — chasing polish on a blocked form is how audits become slide decks again.
Tag each row with one severity. If two severities fit, pick the higher one. The rubric is for scheduling, not for feelings.
Regression belongs in the same table. When a campaign script or component update ships, rerun the representative route and add new rows. An audit is a living backlog, not a PDF from last quarter.
What you can finish alone
You can run the representative-route protocol without a agency. You can fill evidence, issue, fix on every blocker you find. You can rank with the rubric and hand engineering a table they can import.
One quote path is enough to start. Three offer families may need three routes before the site map is honest. Web design that starts from the audit table ships faster because the first screen already names the route.
If one high-intent path fails in a hand, that is conversion repair: one page, one path a person can finish. Repair is narrower than a rebuild. If the map is wrong, fix the map first.
A full website applies the same discipline at more URLs. Web development without an audit table is guesswork with a launch date.
CLICK.BLUE has designed and built sites from walked routes since 2014 — twelve-plus years, fifty-plus businesses, a hundred-plus websites. The audit is the backlog. The route is the test. The fix is the deliverable.
Start with the route that already fails. Write the row. Ship the fix. Then walk the next path.
