How to Audit Your UI/UX

Most interfaces don't need a redesign. They need twenty specific fixes — and nobody has written down which twenty. That is the difference between an audit and a redesign: a redesign starts from taste ("this looks dated"), an audit starts from evidence ("users abandon this form at step 3, field 7, and here is the recording that shows why"). This guide is the full audit method we use on client products: evidence first, then five passes over your interface with concrete thresholds, scored on one sheet, turned into a roadmap ordered by what each problem costs you — and a review habit that keeps the findings from creeping back.

Budget two days for a typical product: half a day of evidence gathering, a day of passes, half a day of scoring and sequencing. That is the entire investment, and it routinely finds the handful of screens causing 80% of the pain.

Guide: https://blackcard.dev/guides/how-to-audit-your-ui-ux
Markdown version (fetch this for the full method): https://blackcard.dev/guides/how-to-audit-your-ui-ux.md

I want to audit the UI/UX of my product using the full method from BlackCard's guide "How to Audit Your UI/UX": evidence gathering (funnel drop-off per step, rage/dead clicks, field-level form abandonment, session recordings, a 5-user hallway test), then five audit passes (task flow, hierarchy and layout, copy, feedback and states, accessibility and mobile), scored by severity x frequency x money-flow proximity.

Interview me first, one question at a time:
1. What is the product and who uses it?
2. What are the 3 flows where users create value or pay money (the "money flows")?
3. Which screens belong to each money flow?
4. What analytics do I have (funnels, heatmaps, session recordings, form analytics) and what do they already show?
5. Can I get 5 people for a 10-minute hallway test this week?

Then produce my audit plan: (a) the evidence to pull for each flow, with the exact report names to look for in my analytics tool; (b) a hallway-test script for my top money flow; (c) the ordered list of screens x passes to run; (d) an empty scoring sheet (screen x pass -> red/yellow/green + severity x frequency x proximity score + note) I can fill in as I go. Keep it practical — I want to run this audit this week, not write a thesis.

Why audit instead of redesign

A redesign from scratch feels productive and resets everything — including the parts that worked. It takes months, costs real money, and routinely ships with the same underlying problems wearing a new coat of paint, because nobody diagnosed the old ones. We have been handed "freshly redesigned" products whose checkout still lost the user's data on the back button — the one bug that was costing them the most, carried lovingly into the new design.

An audit is cheaper and more honest. It forces you to name each problem, point at where it lives, attach evidence, and estimate what it costs. You redesign a flow only when the audit proves the flow itself is wrong — and the audit will tell you that too, with criteria at the end of this guide.

Step 1: Pick your three money flows

A money flow is a path where a user creates value or you earn revenue: sign-up to first success, browse to checkout, request to booked call, invoice to paid. You audit flows, not screens in isolation — a beautiful screen inside a broken flow is still broken. Three flows is the discipline: if everything is "critical", nothing is. Write each one down as a start state and an end state ("logged-out visitor → first project created"), and list the screens between them. That list is your audit scope; resist adding to it.

Step 2: Gather the evidence

This is the half day most teams skip, and it is the half day that turns opinions into findings. You need four kinds of evidence, and every common analytics stack (GA4, Mixpanel, PostHog, Hotjar, Clarity — free tiers included) can produce them.

Funnel drop-off per step. Build one funnel per money flow, one step per screen or decisive action. You are looking for the cliff: the step where the survival rate drops hardest relative to its neighbors. A checkout that goes 100 → 82 → 79 → 41 → 38 has one problem, and it lives on step four. Note the cliff percentage next to each flow — it anchors every priority decision later.

Rage clicks and dead clicks. Rage clicks (the same spot hammered repeatedly) mean the user expected a response and got none — a broken control, a slow action with no loading state, or text that looks clickable. Dead clicks (single clicks on non-interactive elements) mean your visual language lies: something looks like a button or link and isn't. Pull the top ten of each; they map almost one-to-one onto pass 2 and pass 4 findings.

Form abandonment, field by field. For every form in a money flow, you want: which field is last-touched before abandonment, which fields get corrected repeatedly, and time-per-field. The pattern to hunt: a field with high corrections and high abandonment right after it. That field is confusing people out of your funnel — classic culprits are phone-number formats, VAT/tax IDs, password rules revealed only after failure, and any dropdown with 40 options.

Session recordings — twenty in an hour. Recordings drown you if you watch them like television. The working method: filter to sessions that entered the money flow and did not finish, sort by duration descending, watch at 2–4x speed, and only slow down at the screens your funnel already flagged. You are watching for four moments: hesitation (cursor circling, long pauses on one screen), backtracking (up-down scrolling, back-button loops), correction (form fields edited repeatedly), and the exit moment. Log each as one line — screen, moment, what the user was likely trying to do. Twenty recordings per flow is plenty; after fifteen you will mostly see repeats, which is itself the signal that you have found the pattern.

The 5-user hallway test. Analytics tell you where; watching five real humans tells you why. Five users find roughly 80% of the usability problems in a flow, and the protocol fits in a lunch break per person:

HALLWAY TEST PROTOCOL — one flow, 5 participants, ~10 min each

Recruit: anyone who matches your audience roughly and has never
used the product. Not teammates. Coffee voucher as thanks.

Setup: real device (their phone if your traffic is mobile),
real product, screen recording on. You sit beside, not behind.

Script:
1. "Think aloud as you go. There are no wrong answers —
   if something is confusing, that's the product's fault, not yours."
2. Give the task as a goal, never as steps:
   "You need [outcome, e.g. a quote for shipping 2 pallets to Hamburg].
   Use this site to get it."
3. Stay silent. When they ask "should I click X?" answer
   "what would you do if I weren't here?"
4. Only intervene if they are fully stuck for 60+ seconds;
   note it as a critical finding, help them past it, continue.
5. Afterwards, three questions:
   - "What was this product for, in your words?"
   - "Where were you least sure what to do?"
   - "Did anything feel like it didn't respond?"

Log per participant: task completed yes/no, time, the 2-3
stumble points with the screen name. Five sheets = your evidence.

Now you have numbers, recordings and human reactions. Only now do you start judging screens.

Step 3: Define the one action per screen

For every screen in a flow, write one sentence: "This screen exists so the user can ____." If you cannot complete the sentence, you have found your first finding. If the answer contains "and", the screen probably wants to be two screens — or at least needs one primary button and visually quieter everything-else. Keep these sentences; pass 2 tests against them.

The five-pass method

Walk each money flow five times, one pass per dimension. Do not mix passes — one lens at a time catches what a general look-around misses. Score each screen on each pass: green (fine), yellow (friction), red (loses users or data), plus one short note saying why, plus the evidence pointer if you have one ("funnel −38% here", "4/5 hallway users stumbled").

Pass 1: Task flow

Follow the flow like a first-time user with a goal, and count.

• Count steps and fields — against the best alternative. Every screen, every tap, every field from intent to done. Then do the same count on the best competitor or the obvious alternative (even "sending an email" counts as the alternative). If your flow is 14 steps and the alternative is 6, no amount of polish saves it. Within your own flow, ask of each step: what would break if this disappeared? Steps that exist for your database, not for the user, are candidates to remove, merge or defer until after the first success.
• Every form field must justify itself. For each field: is it required for this transaction, or merely nice for your CRM? Each removed field reliably lifts form completion; each added "quick question" costs real conversions. Move what you can to after the commitment point.
• Find the dead ends. Any screen where the user cannot tell what to do next is a dead end: empty search results with no suggestion, a completed action with no "what now", an error with no retry, a 404 with no way home.
• Try to lose your data. Fill the longest form halfway, then press back, switch apps, rotate the phone, let the session expire, submit with one invalid field. If anything comes back empty, that is a red — users do not refill forms, they leave. Multi-step forms must persist progress; validation errors must never clear fields.
• Check the escape hatches. Can the user go back one step without starting over? Edit step 2 from the review screen without losing step 4? Recover from choosing the wrong account type without support tickets?

Pass 2: Hierarchy and layout

This pass asks one question per screen: can a stranger tell, in five seconds, what this screen wants from them?

• The five-second test, as a protocol. Show a screenshot to someone uninvolved for five seconds, take it away, then ask: what is this screen for, what would you tap, what do you remember? Run it with three people per key screen. If two of three name your primary action, green. If they remember the cookie banner and a carousel, red. This takes twenty minutes for a whole flow and settles arguments no meeting can.
• The squint test. Squint at the screen or blur the screenshot. What survives should be the hierarchy: one dominant element, a clear reading order, the primary action discernible. If everything is equally loud — five buttons, three banners, two badges — the layout has no opinion, and users must form one themselves. They won't.
• One primary action. Each screen gets exactly one visually primary button; everything else is secondary (outlined, quieter) or tertiary (text). Two primary buttons is a decision you outsourced to the user. Check this against your one-sentence screen definitions from step 3.
• Consistency on the grid. Pick any two similar screens and compare paddings, card radii, font sizes, button heights, icon sizes. Spacing should come from one scale (multiples of 8px is the common convention — 8/16/24/32); three different "medium" gaps on one screen is how an interface starts feeling "off" without anyone being able to say why. Inconsistency findings here usually trace back to a missing design system or an unused brand guide — note the pattern, not just the instances.
• Reading order matches task order. The eye enters top-left (in LTR locales) and follows size and contrast. Does the visual order match the order of the user's task? A primary action above the information needed to decide on it forces re-reading loops — you will have seen this in the recordings as up-down scrolling.

Pass 3: Copy

Read every word on every screen out loud, as the user.

• The jargon test for labels. For each navigation item and button: would a new customer use this word on the phone? "My bookings" beats "Transaction management"; "Get a quote" beats "Initiate RFQ process". If a label needs a tooltip, the label failed. Your org chart is not an information architecture.
• Buttons finish the user's sentence. "I want to… → Save changes / Send request / Book the call." Not "Submit", "OK", or "Continue" (continue to what?). On destructive actions, the button names the consequence: "Delete 3 projects", never "Yes".
• Error messages: what happened + what to do. "Something went wrong" is a shrug. Every error needs what happened, why if known, and the one action to take: "We couldn't save your changes — the file is over 10 MB. Compress it or pick a smaller one." Audit the real error catalogue, not the happy path: trigger validation errors, payment declines, timeouts.
• Empty states are onboarding. A new user's first screen is usually empty. "No data" is a dead end; "You haven't created a project yet — start with your first one" plus a button is an invitation. Every list, table and dashboard needs a designed empty state.
• Numbers, dates and money formatted like the locale expects. 1.234,56 € vs €1,234.56, 13.11.2026 vs 11/13/2026 — mismatches here quietly erode trust exactly where trust matters (prices, deadlines).

Pass 4: Feedback and states

Every user action deserves an immediate, visible response, and every screen has more states than the one in the design file. Check the full matrix per screen:

• Loading. Acknowledge the tap within ~100 ms (pressed state), show progress for anything over ~400 ms. Rule of thumb: skeletons for content areas you know the shape of (lists, cards, tables) because they reduce perceived wait and layout shift; spinners only for short, shapeless waits (submitting a form); progress bars with real numbers for anything over ~5 seconds (uploads, report generation). A button that does nothing for two seconds gets tapped three times — and then you have three orders.
• Empty. Covered in pass 3 for copy — but check it renders at all. Many layouts collapse, misalign or look broken with zero items.
• Error. Kill the connection, submit invalid data, upload the wrong file type, let the payment fail. Does the UI stay usable? Is input preserved? Is the error adjacent to its cause (field-level) rather than a banner at the top of a long page?
• Success. After the action succeeds, does the user see it succeeded and what changed? A silent save is indistinguishable from a broken one — this is where rage clicks on "Save" come from.
• Partial and edge. One item instead of twenty; a 60-character name in a 20-character box; 1,234,567.89 as a price; a user with no avatar; a plan that expired yesterday. Long content, odd counts, slow connections, permissions the user doesn't have.

Pass 5: Accessibility and mobile basics

Not the full WCAG checklist — the floor below which you are actively losing users (and, increasingly, failing procurement reviews and legal requirements).

• Contrast. Body text and essential labels: at least 4.5:1 against their background (WCAG AA); large text 18px+ bold or 24px+: at least 3:1. Use any free contrast checker. Light gray on white fails — and fails hardest outdoors on a phone, where your mobile users actually are.
• Touch targets. Anything tappable needs roughly 44×44 px of touch area with breathing room between targets. Check the dense spots: table rows with inline icons, tag chips, footer links, date pickers.
• Keyboard path. Tab through each form: focus moves in reading order, focus is visible (a real outline, not removed in CSS), everything reachable, submit works without a mouse. This catches broken markup that hurts everyone, not only keyboard users — and it is the fastest proxy for screen-reader sanity short of a real assistive-tech session.
• Mobile reality check. Open each money flow on a real phone on mobile data: text readable without zooming, nothing essential behind hover, forms usable with the keyboard open (the submit button not hidden under it), no horizontal scroll, inputs with the right keyboard type (numeric for phone, email for email).
• Motion and zoom. Pinch-zoom not disabled; nothing conveys meaning by color alone; animations don't block the task.

The scoring sheet

Keep the output boring and comparable. One row per screen, one column per pass — and score each red/yellow finding on three factors so the roadmap orders itself:

SCORING  severity x frequency x proximity  (multiply, 1-27)

SEVERITY     3 blocks the task or loses data   2 adds real friction   1 cosmetic
FREQUENCY    3 most users hit it (evidence!)   2 common path          1 edge case
PROXIMITY    3 on a money-flow step            2 one step removed     1 side path

SCREEN           FLOW     P1   P2   P3   P4   P5   TOP FINDING + EVIDENCE            SxFxP
---------------------------------------------------------------------------------------
Checkout step 2  booking  RED  yel  yel  RED  yel  back clears form (funnel -38%)    3x3x3=27
Search results   booking  yel  grn  RED  yel  grn  filter labels jargon (3/5 test)   2x3x3=18
Signup           onboard  grn  RED  grn  yel  RED  2 primary CTAs; gray text 3.1:1   2x3x2=12
Dashboard (new)  onboard  yel  grn  RED  RED  grn  empty state "No data"             2x2x2=8

One note per cell maximum; the evidence pointer (funnel %, hallway count, recording pattern) is what separates a finding from an opinion. By the end you have the whole product's health on one page.

From findings to a roadmap engineering will ship

Sort by the SxFxP score descending, then within ties by effort ascending (1 = under an hour: copy, contrast, a label; 2 = about a day: states, form behavior; 3 = structural: flow changes). The top of the list is almost always a run of high-score/low-effort items — error messages, preserved form data, labels, contrast. Those are the quick wins: ship them in the first week; they pay for the audit immediately and buy credibility for the bigger items.

Below the quick wins sit the structural fixes — the flow reorderings and screen merges. Sequence those with engineering deliberately: group them by area so each sprint touches one surface, put the data-loss and dead-end reds first (they bleed users daily), and attach each to the metric it should move so you can verify.

A finding is ticket-ready when it has: the screen and state, the evidence pointer, the expected behavior in one sentence, and its score. "Checkout step 2: pressing back clears all fields (funnel −38%, 4/5 hallway users lost data). Expected: fields persist across back/refresh. Score 27, effort 2." A designer or engineer can act on that without a meeting; "the checkout feels clunky" generates one.

Fix or redesign the flow? A finding means fix when the step is right but its execution fails (wrong label, missing state, weak hierarchy). It means redesign when pass 1 shows the step itself shouldn't exist, when the flow fights the user's actual task order, or when one screen collects reds across three or more passes. Reds scattered thinly across many screens is a fix list; one screen drowning in them is a rebuild candidate. And when you do scope a redesign, scope it honestly: redesign that flow, against the evidence you just gathered, with the fix list as its acceptance criteria — not the whole product, and not from taste.

Keep it from creeping back

An audit is a snapshot; entropy is continuous. Two habits preserve the gains:

Re-audit on a cadence. Same flows, same sheet, every quarter or after any major release. The before/after comparison is your proof of progress — and it is very persuasive in front of stakeholders. Expect the first re-audit to take half the time.

Gate new features with a review checklist. Most regressions enter through new features shipped without the lenses you just applied. Make this the definition-of-done for anything user-facing:

DESIGN REVIEW CHECKLIST — before any user-facing feature ships

[ ] One-sentence purpose: "this screen exists so the user can ___"
[ ] Exactly one primary action, visually primary
[ ] All five states designed: loading / empty / error / success / edge
[ ] Errors: what happened + what to do, input preserved
[ ] Buttons finish "I want to..."; labels pass the jargon test
[ ] Spacing/type from the system scale; brand guide respected
[ ] Contrast at least 4.5:1; touch targets at least 44px; keyboard path works
[ ] Checked on a real phone with the keyboard open
[ ] Funnel event added, so the next audit has evidence

Ten lines, five minutes per feature — and the next audit finds twenty small things instead of two hundred.

Guide: https://blackcard.dev/guides/how-to-audit-your-ui-ux
Markdown version (fetch this for the full method): https://blackcard.dev/guides/how-to-audit-your-ui-ux.md

Act as a senior UX auditor. Audit my product using the full method from BlackCard's guide "How to Audit Your UI/UX": evidence first, then five passes, scored by severity x frequency x money-flow proximity.

Product: [what it is and who uses it]
Money flows to audit: [flow 1], [flow 2], [flow 3]
Screens per flow: [list them; I will paste screenshots one by one]
Evidence: [funnel drop-off per step / rage- and dead-click hotspots / field-level form abandonment / session recording observations / hallway test results — paste what I have]

For each screen, run all five passes and report findings with concrete checks:
1. Task flow — step and field count (vs the obvious alternative), every field justified, dead ends, data loss on back/refresh/error, escape hatches
2. Hierarchy and layout — five-second test, squint test, exactly one primary action, 8pt spacing consistency, reading order matches task order
3. Copy — jargon labels, buttons that finish "I want to...", errors with what-happened + what-to-do, designed empty states, locale formats
4. Feedback and states — full matrix: loading (skeleton vs spinner rules), empty, error (input preserved, adjacent to cause), success, partial/edge
5. Accessibility and mobile — contrast 4.5:1, 44px touch targets, visible focus and full keyboard path, real-phone usability with keyboard open

Output: (a) the scoring sheet, one row per screen: red/yellow/green per pass, top finding with its evidence pointer, and the SxFxP score (severity 1-3 x frequency 1-3 x proximity 1-3); (b) the roadmap: quick wins (high score, under-a-day effort) first, then structural fixes grouped by surface, each finding written ticket-ready (screen+state, evidence, expected behavior, score, effort); (c) for each red, an explicit FIX vs REDESIGN-THE-FLOW verdict with the reason; (d) the design-review checklist tailored to my product so this doesn't creep back. Ask me for screenshots or missing evidence instead of guessing.

An audit like this takes us one to two days, and it is how we start most UI/UX engagements at BlackCard — because fixing the right twenty things beats redesigning two hundred. If you'd rather have experienced eyes pull the evidence, run the five passes and hand you the ticket-ready roadmap, book a free call and show us your money flows.