# Run a practical UI/UX audit around real tasks

A practical interface audit begins with a task someone needs to complete. Follow the journey, record what happens, and distinguish usability problems from visual preferences. A beautiful screen can still leave the reader unsure what to do next.

## Pick one journey
For a fictional booking app, use “find an available time, confirm the timezone, and book.” Record the starting state, required information, success state, and recovery paths. Testing a single screen without the surrounding flow can miss a confusing handoff or a missing confirmation.

## Write observations before recommendations
| Observation | Consequence | Proposed check |
| --- | --- | --- |
| Timezone appears after confirmation | Person may book the wrong time | Move it before the final action |
| Error says “Invalid input” | Person cannot identify the field | Name the field and correction |
| Save button disappears on mobile | Task cannot be completed | Inspect viewport and sticky layout |

These are fictional findings. Do not present an audit checklist as observed user behavior. If you have not watched a person use the page, label your findings as a heuristic review.

## Give AI the evidence
```text
Review this user journey from the supplied screens and behavior.
For each concern, separate observation, likely consequence, and proposed fix.
Prioritize blocked tasks, errors, accessibility barriers, and unclear decisions.
Keep visual preferences separate from usability defects.
Do not invent user research, conversion losses, or measured impact.
Task and screens: [context]
Observed behavior: [notes]
```

## Verify fixes on the same task
Repeat the journey after each important change. Test keyboard use, small screens, slow loading, empty results, and errors where relevant. If the redesign changes the task itself, explain that rather than comparing unlike flows.

Prioritize defects by consequence and evidence. A blocked final action deserves attention before a subtle spacing preference. Keep a short record of the change, expected behavior, and actual check. An audit can guide improvements, but it does not establish that conversion increased or that all users now succeed.

## Create a severity record that explains the consequence
| Finding | Evidence | Consequence | Priority rationale |
| --- | --- | --- | --- |
| Submit action obscured | Observed on the tested narrow viewport | Task cannot finish | Fix before cosmetic changes |
| Error does not name field | Reproduced with missing email | Recovery requires guessing | Fix with the validation flow |
| Heading spacing feels uneven | Reviewer preference | No observed task failure | Consider during visual polish |

The priority is a judgment with a reason, not a fabricated numerical impact. Avoid multiplying arbitrary severity and confidence scores into a number that looks measured.

## Audit the states people reach after the happy path
A product screen often has loading, empty, error, partial, and success states. Review the transitions between them. A page that looks excellent when data is loaded may leave the person stuck after a network failure. A form that preserves data on success may lose it when validation fails.

For the fictional booking flow, test no available times, a time that becomes unavailable, a missing email, a slow response, and a confirmation that requires the correct timezone. State exactly which scenarios you tested. Do not claim complete coverage if you only reviewed screenshots.

## Keep design and evidence together
Ask the designer or AI assistant to propose a fix for one recorded consequence. “Move the timezone before confirmation so the person can check it before booking” connects the change to the task. “Make the page feel more premium” may guide art direction, but it does not explain a usability fix.

After implementation, repeat the task and record the result. If you observe fewer mistakes in a small test, report the actual participants and conditions rather than converting the observation into a population claim. Preserve unresolved concerns for the next review instead of marking the whole interface “fixed.”

---
SkillStall · 2026-10-02