How to run a UX audit with AI (and actually get useful feedback)

Most AI design feedback is useless. Not because AI can’t evaluate design, but because of how designers ask for it.

“Give me feedback on this screen” returns whatever the model thinks feedback should look like: general observations about visual hierarchy, a note about contrast, maybe something about whitespace. It’s the design equivalent of asking someone “what do you think?” without telling them what you’re trying to achieve.

The quality of AI design feedback depends almost entirely on what you ask it to evaluate against.

Here’s a better approach.

Why heuristics change the output

Heuristics are established principles for evaluating experiences. They’ve been built up over decades of usability research and are specific enough to generate specific feedback.

When you give an AI a framework like Nielsen’s 10 Usability Heuristics and a screenshot, you’re not asking “what do you think?” You’re asking “evaluate this against a specific, well-defined set of principles and tell me where it falls short.” The output is completely different.

This is not a new insight: usability testing has used heuristic evaluation for decades. The new part is that AI can run through dozens of frameworks against a screenshot in seconds, identifying issues that would take a trained expert much longer to surface and document.

The framework stack

For a thorough UX audit, you want coverage across multiple dimensions. Here are the frameworks worth including, organised by what they evaluate.

Classic usability

• Nielsen’s 10 Usability Heuristics: the foundational framework, covering everything from system status visibility to error recovery
• Shneiderman’s 8 Golden Rules: particularly strong on consistency and feedback loops
• Gerhardt-Powals’ Cognitive Engineering Principles: focuses on reducing cognitive work

Behavioural psychology

• Hick’s Law: the more choices, the longer the decision takes. Relevant for any screen with multiple options
• Fitts’s Law: the time to hit a target depends on its size and distance. Relevant for tap/click targets
• Miller’s Law: working memory holds roughly 7 items. Relevant for menus, forms, and information density
• Jakob’s Law: users expect your product to behave like other products they use. Relevant for any deviation from convention
• Peak-end rule: experiences are remembered by their peak and their end, not the average. Relevant for empty states, completion screens, and error moments

Trust and persuasion

• Fogg Behaviour Model: evaluates whether your design has the right combination of motivation, ability, and trigger to produce the behaviour you want
• Cialdini’s Principles of Influence: relevant for conversion-focused screens

Interaction design

• Gestalt Principles: how visual grouping affects perception
• Norman’s Design Principles: affordances, feedback, and mental models
• Tognazzini’s First Principles of Interaction Design: 19 principles covering everything from anticipation to readability

Accessibility

• WCAG 2.1 Quick Reference: contrast, keyboard navigation, screen reader compatibility

Content design

• The 10 Content Design Heuristics: clarity, hierarchy, and reading load

The custom checks that catch what frameworks miss

After running audits against these frameworks repeatedly, I noticed the same categories of issues appearing that the formal frameworks weren’t quite capturing. I named them to create a consistent vocabulary.

FTU: First-time user

Five checks focused specifically on the experience of a brand-new user.

• FTU.1 Next action obvious: within five seconds, can a first-time user identify what to do next?
• FTU.2 No required prerequisite knowledge: does the screen require understanding a concept that hasn’t been introduced yet?
• FTU.3 Recoverable mistakes: is the cost of being wrong clear before they commit?
• FTU.4 Empty states do work: empty states should teach, not just announce emptiness
• FTU.5 Jargon budget: count product-specific terms. More than two for a first-time user is usually a warning sign

The FTU checks exist because when you’ve worked on a product for long enough, you stop being able to see what a first-time user sees. The jargon, the assumed knowledge, the friction that’s become invisible: these show up clearly in an audit because the AI hasn’t built the same familiarity.

TRUST: High-stakes moments

Seven checks for trust and safety at decision points where users commit to something.

• TRUST.1 Preview before commit: can users see what will happen before it happens?
• TRUST.2 Test mode: can they experiment without affecting real customers or data?
• TRUST.3 State clarity: is it obvious whether something is draft, live, paused, or scheduled?
• TRUST.4 Reversibility: how difficult is it to undo?
• TRUST.5 Audit trail: can users see what happened, who did it, and when?
• TRUST.6 Volume signposting: before high-impact actions, is the scale obvious? (e.g. “you’re about to send this to 45,000 subscribers”)
• TRUST.7 No dark patterns: no forced choice, no hidden cancellation, no guilt copy, no fake scarcity

COG: Cognitive load

Four simple counts that flag complexity before it becomes a usability problem.

• COG.1 Decision count: more than three decisions before progress is usually a problem
• COG.2 Primary action count: there should be one obvious next step
• COG.3 New concept count: more than one new concept per screen is often too much
• COG.4 Reading load: more than 50 words of body copy is usually worth reviewing

These are not precise thresholds: they’re warning flags. When COG.1 fires, it doesn’t mean the design is broken. It means you should look more carefully.

How to use this in practice

The most effective approach is to build this as a skill in Claude rather than copying the frameworks into a prompt each time. A Claude skill loads the evaluation framework once, so you can run audits consistently without reconstructing the prompt from scratch.

The workflow:

1. Point it at a screenshot, a folder of screenshots, or a Figma frame
2. Answer three questions about what the user is trying to do, where they arrived from, and anything the screenshot doesn’t show
3. It walks each screen in four passes: heuristics, accessibility, UX copy, cognitive load
4. Review the findings by severity, using the Nielsen scale: 1 cosmetic, 2 minor, 3 major, 4 catastrophe

Step 2 is the one people skip, and it’s the one that decides whether the audit is useful. A screenshot shows what’s on the screen but not what’s behind it: where a button goes, what’s hidden until hover, what the default selection is, or what the user was even trying to achieve. Without that, you get a description of the interface rather than an evaluation of the experience.

The output includes the heuristic citation for each finding, a severity rating, and a recommended improvement. This is useful not just for finding issues, but for communicating them: “this violates Nielsen’s principle 5 (error prevention)” is a more credible finding than “this seems confusing.”

Be sceptical of your own severity ratings, or rather, of the ones the audit hands you. The temptation is to accept a page full of 3s and 4s because it makes the work look important. An audit where everything is a catastrophe gets ignored, and rightly so.

Download the skill

I’ve packaged this up as a Claude skill you can install and run on your own product.

It produces three files: an interactive HTML report with numbered pins on your screenshots, a written markdown report, and a structured JSON file that everything else is generated from. There’s a shortlist feature too, so you can tick the findings worth acting on and have Claude open them as tickets in Linear, Jira, or whatever you use.

Get the UX audit skill

It works in the Claude desktop app, Claude Code, and Claude.ai. Everything described in this post is in it, and the rubric is a plain markdown file, so if there are issues specific to your product that keep recurring, add your own checks. That’s exactly how FTU, TRUST and COG ended up in there.

What this is good for: and what it isn’t

A heuristic audit is a starting point, not a conclusion.

It’s excellent for:

• Finding issues you’ve become blind to after working on the same product for months
• Running a quick review before a launch or a design review
• Creating a consistent vocabulary for recurring issues across your team
• Documenting findings with citations that make them harder to dismiss

It’s not a replacement for:

• User research (the audit tells you where issues might be; users tell you what actually confuses them)
• Quantitative data (conversion rates and drop-off data tell you where the cost of issues is highest)
• Judgment about which issues to fix and in what order

The audit generates a list of issues. Knowing which ones to prioritise, given your business model, your users, and what your team can actually ship, is still the designer’s job. If that prioritisation muscle is the part you want to build, start with how to show design impact without perfect data.

The bigger point

The reason this kind of tool matters isn’t efficiency (though it is faster). It’s that most designers have stopped doing heuristic evaluations at all. The practice fell out of fashion. Now that AI makes it fast enough to do consistently, the question is whether we use that to return to more rigorous design practice, or just ship screens faster.

Using AI to understand your product more deeply, to catch what you’ve stopped seeing, is a more interesting direction.