UX Audit Checklist: When Your Product Feels Broken

Every product team eventually hits the same moment. Support tickets pile up around the same three screens. Activation numbers sag. Someone in a meeting says "the product just feels clunky" and everyone nods, because everyone feels it too. Nobody can point at the exact problem.

That's when you need a UX audit. Not a redesign, not a brainstorm about new features. A structured review of what's actually broken, how badly, and in what order to fix it.

Here's the checklist we use, in the sequence that makes sense.

Before You Start: Define the Core Action

An audit without a focus turns into a list of two hundred nitpicks nobody acts on. Start by naming the one action your product exists for. Creating a project. Sending an invoice. Completing a transfer. Everything in the audit gets weighed against a single question: does this help or block the core action?

Also decide who you're auditing for. A power user and a first-time visitor hit completely different problems. If you have to pick one, pick the new user. They see everything your team stopped noticing years ago.

1. The First Session

Walk through your product as someone who has never seen it. Better: watch a real person who never has. Give them the core action and stay silent.

Check:

• Can they tell what the product does within seconds of landing?

• Is the path to the core action obvious, or do they wander?

• How many decisions do they face before getting any value?

• Where do they hesitate? Every pause is a question the interface failed to answer.

• Do empty states guide them, or greet them with a blank screen?

The first session is where most products lose most users. Onboarding that assumes knowledge, forms that ask too much too early, screens that show everything instead of the one next step. We picked apart these exact failures in crypto products in The UX Patterns Killing Crypto Adoption, and the same patterns show up in regular SaaS all the time.

2. Navigation and Information Architecture

Check:

• Can users predict what's behind each navigation item before clicking?

• Is there one obvious way to get anywhere, or three inconsistent ones?

• Does the sidebar or menu have more than seven top-level items? If so, grouping is overdue.

• Can users always tell where they are and how to go back?

• Do labels use the user's language or your internal jargon?

A quick honesty test: read your navigation labels out loud to someone outside the company. If any label needs an explanation, it fails.

3. Hierarchy on Every Key Screen

Open your five most-visited screens and squint. What stands out? That's what the design says is important. Does it match what actually is?

Check:

• One clear primary action per screen, not four buttons of equal weight

• Data ordered by what users need, not by what the database returns

• Type sizes that create real levels, not fifteen slightly different ones

• Whitespace used to group related things, not distributed evenly like margarine

Dashboards fail this more than any other screen type. If yours shows twenty metrics with equal visual weight, users can't find the one number they came for. We wrote a full breakdown in SaaS Dashboard Design: Principles That Actually Scale.

4. Forms and Inputs

Forms are where intent goes to die. Every form in the product deserves scrutiny.

Check:

• Does every field earn its place? Each one costs completion rate.

• Are labels visible while typing, or do placeholders vanish and leave users guessing?

• Do error messages say what's wrong and how to fix it, or just turn red?

• Does validation happen inline, or only after submitting the whole thing?

• Is the primary button labeled with the action ("Create invoice") or with nothing ("Submit")?

5. Feedback and System Status

Users need to know the system heard them. Silence reads as failure.

Check:

• Does every action produce a visible response within a second?

• Are loading states designed, or does the screen just freeze?

• Do destructive actions ask for confirmation, and only the destructive ones?

• When something fails, does the user learn what happened and what to do next?

• Can users undo, or does every mistake mean starting over?

Overdone warnings deserve a look here too. When every third click triggers a confirmation dialog, users stop reading all of them, including the one that matters.

6. Consistency

Inconsistency is invisible in any single screen and corrosive across the product. It's also the most common finding in products built by teams over several years.

Check:

• Are buttons that do the same kind of thing styled the same way everywhere?

• Does the same concept have one name across the interface, or three?

• Do similar screens share a layout, or was each one designed from scratch?

• Are icons used with consistent meaning?

• Do date formats, number formats, and capitalization follow one rule?

Every inconsistency makes users relearn something they already learned. The cognitive cost is real, and it compounds. The mental models behind this are covered in Psychology of UX.

7. Accessibility Basics

Not the full WCAG treatment, but the floor every product should clear:

• Text contrast passes AA (4.5:1 for body text)

• Interactive elements are reachable by keyboard

• Focus states are visible

• Color is never the only carrier of meaning

• Touch targets are big enough for actual fingers

Accessibility problems tend to correlate with general sloppiness. Fixing them usually improves the experience for everyone.

8. Performance as UX

Speed is a design property. A beautiful screen that takes four seconds to load is a broken screen.

Check:

• Time to interactive on the most-used screens

• Whether heavy screens load progressively or all at once

• What happens on a slow connection, not just office wifi

• Whether mobile is genuinely usable or technically responsive

Turning Findings Into a Plan

The audit produces a long list. Don't fix it top to bottom. Score each finding on two axes: how much it hurts (blocks the core action vs cosmetic) and how hard it is to fix.

That gives you four buckets. High-pain, low-effort fixes go first: these are usually copy changes, button hierarchy, error messages. High-pain, high-effort issues get scheduled properly. Low-pain items go in the backlog, and the honest move is admitting most of them will never be worth doing.

One more thing worth naming: an audit that finds mostly hierarchy and consistency problems is telling you the product lacks a design system. Fixing screens one by one without one means the problems grow back. That's a separate conversation, and we wrote it up in Design System for Startups.