Check AI-built UI before you test it with users

I've watched a test session fall apart in slow motion. A participant lands on a screen with no empty state. The list they expected is just gone. They click around, visibly confused. The call took a week to book. We had a long list of questions to get through, and we burned a good chunk of the session learning that nobody had checked whether the agent wrote an empty state.

We already knew the product had one. That was not the insight we needed.

This page is for founders and design leads whose team ships UI from Cursor, Claude Code, v0, or Lovable, then puts it in front of users without a real desk check. It is not the same job as testing AI features with users. That article is about the product behavior participants experience. This one is about checking AI-built UI before anyone sees it.

User testing is for things you cannot know from your desk

User testing teaches you how real people think. How they read your labels. Where their mental models break from yours. What they did not expect. It is genuinely hard to get right, and hard to schedule. When you are waiting a week for a session slot, you want every minute doing work that only a participant can do.

You do not want to spend that time learning the contrast ratio fails, the error state was never written, or the microcopy sounds like it came from a different product. A designer, or anyone paying attention, would catch those in ten minutes.

AI changed the economics of building screens. Cursor, Claude Code, v0, Lovable: any of them can go from a prompt to a working UI in minutes. That is genuinely useful. But the agent does not know your design system the way your team does, does not feel when the spacing is slightly off, and will not flag a missing permission state because nobody told it one was needed. When agents design for failure in the abstract, the screen in front of you still needs a concrete pass.

Fast to build does not mean ready for users. Those are two different bars, and confusing them is expensive.

The pre-test pass: what to check before the session

Run this before any AI-built screen goes in front of a participant. It is not a full design review. It is a targeted check for the problems agents reliably miss.

Brand and system

Does the screen use real components from your design system, or has the agent approximated them? Token names that do not exist in your system, spacing values pulled from nowhere, type sizes that fall outside your scale: these are easy to miss when the screen looks plausible at a glance. Check the microcopy too. If the labels, confirmations, and errors do not sound like the rest of your product, participants notice, even if they cannot say why. When Figma and code disagree on what the system is, agents inherit the mess. A design system audit is the offer when the library is already drifted; this pass is what you run on the screen you are about to test.

States and paths

Agent-built screens most often break here. Work through the list: empty state, loading state, error state, permissions error, long content, first-run experience. Each one should be deliberate, not missing, not a placeholder. Then trace the full scenario the test script will use. If the flow cannot complete the job the task prompt asks, you will know in the first few minutes of a session you waited a week to run.

Accessibility basics

Check contrast against WCAG AA. Tab through the flow and confirm focus is visible the entire way. Make sure every input has a real label, not just placeholder text. These are not polish. They are basic quality. If they are broken, some participants will not be able to complete the task at all.

Scenario coverage

Sit down with the test script and walk through it yourself, clicking as a participant would. Does the flow do the job? Are there dead ends? Does the navigation make sense without explanation? Participants should not need a facilitator's help to get through a standard task.

What you can automate, and what still needs a person

Some of these checks are mechanical. You can automate them. Design-system linters can compare agent-written code against your tokens. MCP design checkers can lint against a DESIGN.md in the repo. That file, spelling out your real spacing scale, type ramp, component names, and voice rules, gives the agent and any checker something concrete to work against. Running automated contrast and label checks before the screen ever reaches a designer saves everyone time.

But some of this still needs taste. Automation cannot tell you whether the hierarchy feels right, whether the screen actually matches the product you have built, or whether the copy sounds like you. Those judgments need a person. Someone who knows your product well enough to say "this is off" when nothing is technically wrong but everything feels foreign.

The distinction matters. Automate the mechanical checks, and that person can spend their time on judgment work rather than token names. Long-term, that pairs with AI UI brand governance: a root system so you are not fixing the same invented blue every session.

Make the fixes stick

The fastest way to break the cycle of agent-builds-you-fix is to put the rules somewhere the agent can read them.

A DESIGN.md file in your repo, or whatever you call your taste profile, should spell out the real spacing values, the actual type scale, the component names, and the voice rules for microcopy. When the agent knows these upfront, it makes fewer guesses. Component specs help too. If you have documented how your empty state behaves, what error messages look like, and how first-run flows work, the agent can follow that rather than inventing something plausible. The file format and package are on DESIGN.md and Taste Profile. Behavioral and accessibility boundaries can sit in designgov.md above that layer.

It is not a one-time fix. It evolves with the product. The AI-ready design systems series is the map when you are building that folder on purpose. On a marketing site, the same idea applies: edit your website with AI agents only stays safe when tokens and rules live in git.

But even a good contract does not replace the pre-test pass. It reduces how often you need one.

When a screen is ready for users

A screen is ready for user testing when:

• Every state in the tested flow is accounted for: empty, loading, error, permissions
• Component and token choices match your design system, not an approximation of it
• Contrast passes and focus is traceable through the entire flow
• Microcopy sounds consistent with the rest of the product
• You have walked through the test script yourself without hitting a dead end
• Nothing on the screen would stop a participant from doing the task

If any of those are missing, fix them before you book the session, not after.

Where Clearly fits

At Clearly, we sit between your agent and your users. Our job is to make sure screens are actually ready before a participant sees them, not just built.

We review AI-generated UI against your design system, check states and paths, flag accessibility issues, and clean up microcopy. When judgment calls come up, we make them. When the same problem keeps coming back from the agent, we help you document the fix so it stops coming back.

We work inside a monthly subscription, so there is no project overhead and no scoping every review. Standard is $4,995/mo. Advanced is $7,495/mo. Confirm live plans on homepage pricing.

If your team is shipping AI-built screens and heading straight to user testing, book a discovery call and we will figure out whether we are a good fit.