Tuning the Review: Custom AI Design Audits

A generic audit gives generic advice. It will faithfully tell you that your contrast is low and your buttons are inconsistent — useful, but it has no idea whether your product is a consumer checkout, a clinical dashboard, or a telecom billing console where "good" means something very specific. Your product isn't generic. Your audit shouldn't be either.

Out of the box, a strong audit tool raises the floor: it catches the objective, universal problems every product should fix. But the highest-value feedback is contextual — it depends on who your users are, what they're trying to do, and the standards your team has already agreed on. That context is exactly what a stock checklist can't know. The fix is to give the audit that context, and there are two levers for it: expertise skills and custom rules.

Why generic audits plateau

Every audit tool eventually hits a ceiling on a specific product, because the same finding means different things in different contexts. A dense table of numbers is a usability problem on a marketing page and a feature on a financial reconciliation screen. A multi-step form is friction in a signup flow and a legal requirement in an onboarding-for-a-regulated-product flow. Without knowing which world it's in, a tool has to hedge — and hedged feedback is the feedback teams learn to ignore.

Domain expertise is what turns "this is dense" into "this density is right for power users, but the primary action is buried — here's the fix." You can't get there from a universal rulebook. You get there by teaching the tool your domain.

The difference between a checklist and a consultant is context. Give the audit yours.

Lever one: expertise skills

An expertise skill is a domain pack you upload — a short body of knowledge that makes the review an expert in your world. It describes who your users really are, the context they operate in, the constraints they're under, and what excellent looks like for them.

Say you run collections for a telecom's billing system. A generic tool reviews your agent console as if it were any web app. Feed it an expertise skill about telecom BSS collections — the agent's workflow, the regulatory guardrails, the metrics they're judged on, the decisions they make under time pressure — and the review changes character. Now it evaluates the console the way a principal designer who has shipped collections tooling would: is the next-best-action obvious, is the sensitive-data handling appropriate, is the workflow shaped around how agents actually move. That's the leap from research and validation to genuine design expertise.

Lever two: custom rules

Where expertise skills teach judgment, custom rules encode your non-negotiables. These are the specific, checkable standards your team has already decided on:

• Design-system tokens — flag any color, spacing, or radius that isn't from the system, so design-system drift gets caught against your tokens, not a generic palette.
• Brand and voice — check copy against your voice-and-tone guide and surface anything off-brand.
• Always / never rules — "every destructive action needs a confirm," "never use placeholder as the only label," "primary CTA is always present above the fold."
• Component conventions — your naming, your approved variants, your accessibility baseline.

Custom rules make the audit an extension of your own standards, so it enforces the things you already care about without you re-explaining them every time.

How to write an expertise skill that works

The tuning is only as good as the context you give it. A vague skill produces vague results; a specific one is transformative. When you write one, be concrete about:

• Who the user is — role, expertise level, environment, and what pressure they're under.
• What they're trying to accomplish — the real job, not the feature list.
• The constraints — regulatory, technical, accessibility, and business rules that shape what's acceptable.
• What "good" and "bad" look like — concrete examples of excellent and poor design in this domain.

Write it the way you'd brief a sharp new hire on their first day. The more real the briefing, the more the audit reads like it came from someone who has lived in your product.

Frequently asked