Early preview · Six skills are always free. Paid skills open soon.
Website design · 4 min read

Run a practical UI/UX audit around real tasks

Review one user journey, record observable friction, and prioritize fixes by consequence rather than visual taste.

Editorial illustration of a magnifying glass examining the loose rung of a small ladder.

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

ObservationConsequenceProposed check
Timezone appears after confirmationPerson may book the wrong timeMove it before the final action
Error says “Invalid input”Person cannot identify the fieldName the field and correction
Save button disappears on mobileTask cannot be completedInspect 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

Working template

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

FindingEvidenceConsequencePriority rationale
Submit action obscuredObserved on the tested narrow viewportTask cannot finishFix before cosmetic changes
Error does not name fieldReproduced with missing emailRecovery requires guessingFix with the validation flow
Heading spacing feels unevenReviewer preferenceNo observed task failureConsider 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.”