Lighthouse will give you a performance score. It'll flag missing alt text and low contrast ratios. It will not tell you that your error messages are confusing, that your empty states are invisible, that your mobile nav collapses in a way that traps users, or that your form's success state is so subtle half your users resubmit because they're not sure it worked.
Those are the UX problems that cost you users. And they require a human to find — specifically, a human who knows what to look for. This is that framework. Five phases, six minutes each, 30 minutes total. You'll come out the other end with a prioritized list of real UX issues you can fix in the next sprint.
Before You Start
Open your site in an incognito window — no saved sessions, no auto-filled forms, no cached states. Use a device you don't test on regularly, ideally a phone. Set a timer. The goal is to experience the site the way a first-time user does, not the way someone who built it does.
Land on the homepage as a stranger. You have five seconds to answer these questions before you look at anything else. This is the only moment you'll ever experience your site the way a brand-new user does — use it.
- Can you tell what this site is for in under 5 seconds? Cover the logo and read only the headline. Is the value proposition obvious without knowing the brand?
- Is there a clear visual hierarchy? Squint at the page. Your eye should move from the largest, most contrasted element downward in a natural reading order. If everything is the same weight, nothing is.
- Is there exactly one primary CTA above the fold? One clear, high-contrast button telling the user what to do next. Not two. Not three. One.
- Does the body text pass contrast on white? Open DevTools, pick your body text color, and check it against your background at color.review. WCAG AA requires 4.5:1 for normal text.
- Does the page breathe? Cramped spacing signals low quality to users before they read a single word. Check that headings have enough space above them, and that paragraphs aren't wall-to-wall text.
Navigation is the skeleton of your UX. A user should always know where they are, where they can go, and how to get back. Most nav issues are invisible to developers because they know the site too well to get lost in it.
- Is the current page visually active in the nav? The active link should look different — a color, a border, a weight change. Without it, users can't tell where they are.
- Can you tab through the entire nav with a keyboard? Press Tab from the top of the page. Every link should receive a visible focus ring in the correct order. If it disappears or jumps erratically, that's an accessibility and usability failure.
- Does the mobile nav open and close correctly? Shrink your browser to 375px. Test the hamburger open/close. Test that links actually navigate and close the menu. Test that the background content is inert (not scrollable) when the nav is open.
- Is the logo linked to the homepage? Always. Without exception. Users click the logo to go home by default — break this expectation and you've silently broken trust.
- On deep pages, is there a breadcrumb or clear back path? Any page more than two levels deep should tell users where they are in the hierarchy and give them a path back without needing the browser's back button.
Forms are where most UX audits find the most issues per square pixel. Submit every form on your site — happy path, wrong inputs, empty inputs, and deliberately bad data. The error states reveal more than the success states.
- Do all inputs have persistent visible labels? Not placeholders. Labels. A label above the field that stays visible when the user starts typing. If you're using placeholder-as-label anywhere, fix it today.
- Submit the form with deliberate errors. Does every error message say what went wrong and what to do? "Invalid input" is not an error message. "Your email address needs an @ symbol" is an error message.
- Is the form success state obvious and durable? Submit successfully. Is there a visible confirmation — a message, a state change, a redirect — that's impossible to miss? Does it persist long enough to read? Does it give the user a clear next step?
- Does every button have a loading state during submission? Click submit. Does the button immediately disable and show a loading indicator? If not, users will click it twice — and you'll have double submissions in your database.
- Do hover and focus states work on every interactive element? Tab through every button, link, and input. Each should have a distinct, visible focus indicator. Hover over buttons — they should respond. No invisible interactives.
Designers spec the happy path. Developers build the happy path. Real users live in the edge cases. This phase finds the states that nobody designed for — the ones users discover on their own, usually at the worst moment.
- Does every list or data table have a designed empty state? Log out or delete all data from a test account. Navigate to every list view. An empty state should have a heading, a sentence explaining why it's empty, and a single action to fill it.
- Does every async data load show a skeleton or spinner before content renders? Throttle your network to "Slow 3G" in DevTools. Navigate to every page that fetches data. The skeleton should appear immediately — not after the data loads.
- What does a network failure look like? In DevTools, set network to "Offline" and trigger an action that requires a server call. Does the user see a meaningful error — or does the UI silently fail, leaving them stranded?
- Does long content break your layout? In DevTools, find a text element and paste in 500 characters of Lorem Ipsum. Does the layout hold? Overflow hidden can silently truncate real user content. Wrapping should be intentional, not accidental.
- Is your 404 page helpful? Navigate to a URL that doesn't exist. Your 404 should acknowledge the situation, match your brand, offer navigation back to the homepage, and ideally suggest related content. "Page not found" alone is a dead end.
The final phase is about what users feel, not just what they see. Performance perception is a UX metric — a fast-loading page that jumps around on load is worse than a slightly slower page that stays stable. Test both on your real device, not the DevTools simulator.
- Are all tap targets at least 44×44px on mobile? On your phone, try tapping every link, button, and interactive element with your thumb without looking carefully. Anything you miss or have to retry is undersized.
- Does the page shift as it loads? Hard refresh the page and watch the layout. Does content jump around as images load, fonts swap in, or ads render? Every jump is a CLS violation and a moment of user frustration.
- Does the hero or main image load quickly? If your LCP element takes more than 2.5 seconds on a mid-tier device, users are forming negative impressions before they've read a single word. Run PageSpeed Insights to confirm your LCP timing.
- Is the font size readable without zooming on mobile? Body text should be at least 16px on mobile — anything smaller and users pinch-zoom, breaking your layout. Check actual computed font sizes in DevTools on the mobile viewport.
- Does interacting with the page feel instant? Tap through key interactions on your real phone. Every button press, link click, and interaction should respond visually in under 100ms. If anything feels "laggy," that's an INP problem — profile the main thread in DevTools.
What to Do With Your Results
You should now have a list of issues across some or all of these five phases. Don't try to fix everything at once. Instead, run a quick triage: mark each issue as High (visible to every user on every visit), Medium (visible on specific paths or devices), or Low (edge case or minor polish). Fix all High items in the next sprint — they're costing you users right now.
"A UX audit isn't about proving your site is bad. It's about finding the gap between how you think your users experience it and how they actually do — before that gap costs you."
Run this audit every time you launch something significant — a new feature, a redesigned page, a new user flow. You'll get faster at it. By the third time you run it, you'll start catching these issues before they ship, because you'll have built the instinct to ask the right questions during development, not after.
That's the real goal. Not a 30-minute ritual, but a permanent shift in how you read your own work.