Design QA for AI-Generated UI: A Four-Step Review Process

Quick Answer

Design QA is the review that sits between "the interface runs" and "the interface ships." The older meaning of the term was narrow: check the built screen against the design file and list the differences. When an agent generates the interface directly from a prompt, there is usually nothing for that check to compare against. No design file exists, and the screen itself is the first artifact anyone sees.

So the question design QA has to answer is different now. Not "does this match the spec," but "can a real person do the thing this screen exists for, and are we willing to put our name on it."

This article describes a four-step process for answering that, the checklist that goes inside it, and the two ordering rules that make both worth running. You can do this in-house or ask someone outside. The reviewers can be people, AI, or both. The decision at the end should belong to a person.

Why AI-Generated Interfaces Need Their Own Review Step

Generated interfaces fail in a recognizable way. They are rarely broken. They are usually plausible.

An agent will produce a screen with a heading, a table, a toolbar, and a primary button, and every part of it will look like something a designer would ship. What tends to be missing is the layer underneath: which of those four elements is the point, what happens when there are no rows, what a person does after they finish, whether the sample data it invented contradicts itself.

That layer is invisible to the person who wrote the prompt, because they know what they asked for. It is not invisible to a first-time user.

There is also a gap in how this work gets checked today. When we searched the English-speaking market for firms selling a packaged audit of AI-generated work on August 4, 2026, we found at least eight, priced roughly between $2,000 and $15,000. Every one we found audits code, security, or architecture. We did not find one selling a review of the interface. The output people actually touch is the part that goes unchecked.

The Part That Is Easy to Copy, and the Part That Is Not

The checklist further down this page is easy to copy. Take it and use it tomorrow.

The ordering is harder to copy, because it costs something to follow. Two rules do most of the work.

Rule 1: Write down what the screen is for before you look at it

One sentence, recorded before the review starts, somewhere you cannot quietly revise it afterwards. Not "the project list screen" but "let a site manager assemble a photo record they can submit to the client without leaving the office."

This sentence is what makes severity mean anything. Without it, every problem is "a bit hard to use," and every problem gets the same middling weight. With it, you can say the thing that actually decides whether a screen ships: this specific problem stops the screen from doing its job.

The reason to freeze the sentence is uncomfortable and worth being honest about. If you write the purpose after you have seen the screen, you will write a purpose the screen already satisfies. Everyone does this. Recording it first is the only defense.

Rule 2: Look before you hand over the criteria

Give a reviewer a checklist and they will answer the checklist. What they stop doing is noticing.

So the first pass carries no criteria at all. The reviewer gets the screen and a role, nothing else, and reports what they think the screen is for, what confused them, and what they liked. Only after that pass is closed do they receive the criteria for the detailed pass.

We measured this once, on July 30, 2026. The person making the final call on a production-style screen based that call on five specific problems. The reviewers, working separately from that person and from each other, found all five. Four of the five showed up in the unaided pass, before anyone had seen a checklist. The checklist added the fifth and sharpened the reasoning behind the other four. It did not do the finding. That is one round on one screen, so take it as a reason to try the order rather than proof that it always holds.

A useful side effect: because the unaided pass asks "what do you think this screen is for," it doubles as a comprehension test. If nobody can name the purpose you froze in Rule 1, you have your first finding already.

The Four Steps

Step 1: Subject

Decide exactly what is under review, and write it down.

Which screen or screens, at which URL or build.
Which viewport widths. Review at the widths people will actually use, and capture each one separately rather than stitching a full-page screenshot together. Full-page captures produce layout breaks that do not exist on a real device, and you will waste a review arguing about them.
What the reviewer is allowed to see. If the review is meant to be blind, the file names, the folder path, and the window title all leak context. Rename the copies to something neutral.

This step sounds like paperwork. It is the step that makes the review repeatable later, when someone asks whether the fixes actually helped.

Step 2: Intake

Before anyone looks, record:

The purpose of the screen, in one line. Rule 1. This is the reference point for everything that follows.
The screen type. A business tool, a consumer landing page, and a payment flow do not share a bar. Recording the type lets you drop criteria that do not apply, instead of scoring the screen against questions it was never meant to answer.
Who it is for. Name the people whose experience of this screen matters most. A tool for site foremen and a signup page for first-time consumers deserve different reviewers, and deciding this before the review is part of the review.
Where the user arrived from, if the flow matters. Note that this is not the same as the purpose line. The purpose is what the screen must accomplish; the entry point is context for judging navigation.

If a piece of intake is missing, leave it missing and say so. Do not let a coordinator quietly fill it in on the reviewers' behalf. Reviewers who hold context the decision-maker never had will produce agreement that means nothing.

Step 3: First Pass, Unaided

Send the screen to each reviewer separately, with their role and nothing else. Reviewers should not see each other's answers.

Collect:

First impression, in one sentence.
What they believe the screen is for.
What tripped them up, with the specific place on the screen quoted.
What worked.

Keep this pass short. Its value is the unprompted stumble, and that decays the longer someone stares at a screen and starts reasoning about it.

Step 4: Assessment

Now hand over the criteria and run the detailed pass, then decide.

For each item, a reviewer answers yes, no, or cannot tell, and gives three things: why, where on the screen, and which direction a fix would go. The direction matters. A finding with no direction attached is criticism, and criticism is not a deliverable.

Two evidence rules are worth adopting outright:

Every finding quotes the screen. No quote, no finding. This sounds harsh, and it is the single cheapest way to keep a review honest.
A finding about something missing records where the reviewer looked for it. You cannot quote what is not there, so the substitute is the search: "no way to close this; looked under the header menu, the record panel, and the footer." Without this rule, the most important class of problem in generated interfaces (the thing that was never built) gets thrown out for lack of evidence.

Rate the most serious problem in each area by severity, on a scale defined against the purpose line from Step 2:

Critical. The screen cannot do the job you wrote down. Not "annoying." Not "unpolished." Cannot do the job.
Major. The job is possible, but people will hesitate, drop out, or stop trusting the screen on the way.
Minor. Visible roughness that does not change the outcome.

Three levels are enough. The value is not in the granularity, it is in forcing the top level to be defined against a sentence you wrote before you looked, so that "critical" cannot quietly expand to mean "I did not like it."

Then a person decides. Not the aggregate, not the tooling, a person. If that person disagrees with the reviewers, the disagreement and the reason for it go into the report. A review whose final call is invisible is a review nobody can argue with, and being arguable is the point.

Finally, separate the two outcomes that lead somewhere different: this needs fixes, or this needs rebuilding. Teams lose months by treating a structural problem as a backlog of small ones.

The Checklist

Six areas. Every question is written so that yes is the healthy answer and no is a finding, which is what lets a reviewer move through the list without stopping to work out which way each item points. Under each area is the failure we see most often in generated screens, drawn from a cold test in which agents were given real industry briefs with no further context and produced screens from them. The corpus stood at 175 screens as of August 7, 2026.

Clarity: is it obvious what this screen is for

Can a first-time viewer say what the screen does within a few seconds?
Does the heading name what can be done here in concrete words, rather than "Management" or "Dashboard"?
Is the single most important number or item visible without scrolling?
When there is no data, does the screen say what to do next?
Does the screen use the user's vocabulary, with no raw status values, internal IDs, or nulls on display?

Most common failure: the main action and a minor utility rendered at exactly the same weight, so nothing leads and every element claims equal importance.

Flow: does the path hold together

Does the main task complete in the fewest steps it reasonably can? Count them rather than estimating.
Do "Back" and "Cancel" land where someone would predict, without discarding what they entered?
In a multi-step task, can a user see where they are and how much is left?
Does the completion screen offer a next step instead of ending in a dead end?
Does the same concept appear in the same place on every screen?

Most common failure: a full-page transition between list, detail, and edit, so a task that should take a minute becomes ten page loads.

Action: can people act without hesitating

Is there one primary button, labeled with a verb?
Do errors appear next to the field they belong to and say how to fix the problem?
Do destructive actions confirm, or can they be undone?
Are required and optional fields distinguished, with format examples given somewhere other than the placeholder?
Is the in-progress state visible, and is a second submit blocked?

Most common failure: three buttons styled as primary, sitting in a row.

Trust: does this look like something to rely on

Do aggregate numbers carry an as-of time and a denominator?
Before asking for personal or payment details, does the screen say what they are used for?
Do error messages say what happened and what to do, rather than "An error occurred"?
Can a user find out who runs this and reach a human in one or two clicks?
Are dates, currency, and units formatted the same way across the entire screen?

Most common failure: sample data that contradicts itself. A later stage marked complete while an earlier stage is still in progress, or a total that does not match the rows above it. Generated content is optimized for looking plausible, and plausible is not the same as consistent. Read the screen as a sequence of claims and check whether the claims agree.

Friction: is anything harder than it needs to be

Does the screen avoid asking for anything it already knows?
Do long option lists have search, a sensible default, or a recommendation?
Are controls with very different consequences far enough apart, and big enough, that a mis-tap is unlikely?
Does waiting show progress or set an expectation?
Can an unfinished task be resumed?

Most common failure: a list of fifty options rendered as a bare dropdown, because that is the shortest correct implementation.

Feasibility: does it survive real data

Does it hold with a very long name, zero rows, and ten thousand rows?
Does the layout hold at other widths?
Can the whole screen be operated by keyboard, with focus visible?
Is every meaning that color carries also carried by text, shape, or position?
Does text meet the contrast level you have committed to?
Are loading, error, empty, and success all implemented?

Most common failure: only the success path exists. Generated screens are usually built against short, tidy sample data, so the states that appear on a bad day were never written.

Running This With a Small Team

The process does not require a review board. It requires more than one pair of eyes and a bit of discipline about order.

A workable minimum:

One person writes the purpose line and the screen type, and stops there.
Two or three people do the unaided pass separately. They can be colleagues from outside the project, and they can be AI reviewers given distinct roles. Distinct roles matter more than headcount. A domain expert, a first-time user, someone thinking about accessibility, and someone working only from a phone will each find things the others cannot. Do not skip the phone. Problems that are invisible at desktop width tend to have exactly one reviewer who can see them.
The same reviewers do the detailed pass with the checklist.
One person, ideally not the person who built the screen, makes the call and signs it.

If the reviewers are AI, three things keep the results usable: give each one a role and no project context, ask every finding to quote the screen, and never let the final decision be theirs. Generated review of generated UI is useful for coverage and terrible for judgment.

Common Mistakes

Handing over the checklist first

The most expensive mistake, and the easiest to make, because handing over the checklist feels like being organized. It converts reviewers into form-fillers and quietly deletes everything the form does not ask about.

Writing the purpose after looking

You will write a purpose the screen already meets, and the review will confirm what you already believed.

Reviewing with one pair of eyes

One reviewer gives you one person's taste. The output of a single-reviewer process is an opinion, and it will be treated as one the first time someone disagrees with it.

Stopping at findings

A list of problems with no direction for fixing them is criticism. It also has no shelf life, because nobody can tell later whether it was addressed.

Not reviewing again after the fixes

The second review is what turns a review into evidence. Same criteria, same reviewers, after the changes. Without it you have opinions before and opinions after.

Progressive Disclosure for sequencing complexity rather than hiding it
Scannability for the clarity checks above
Undo and Redo for the recovery checks under Action
Fitts's Law for target size and spacing under Friction
Affordance vs. Signifier for whether a control communicates what it does

A Note on Where This Comes From

We run this process ourselves, under the name UIXHERO Design QA. The method, the criteria, and the checklist are meant to be taken and used, whether or not you ever talk to us. What we cannot hand over is reviewing someone else's screens, and that is the only part worth charging for.

FAQ

What is design QA?

Design QA is a review step before release that asks whether an interface does the job it exists for. It has traditionally meant checking a build against a design file. For interfaces produced by AI, where no design file may exist, it means checking the screen against a written statement of its purpose.

Is design QA the same as QA testing?

No. QA testing asks whether the software behaves according to specification. Design QA asks whether a person can accomplish something with it, and whether the screen earns their trust while they do. A screen can pass every functional test and still fail design QA.

How is reviewing AI-generated UI different?

The failure pattern is different. Handwritten interfaces tend to fail at the edges. Generated interfaces tend to be complete on the surface and hollow underneath: no empty state, no error state, sample data that contradicts itself, and no hierarchy among the elements. The review has to go looking for absences, which is why recording where you searched matters.

Can AI do the review?

AI reviewers work well for the passes that need coverage and independence, especially when you give each one a distinct role and no project context. They are not a substitute for the decision. Keep the final call, and the signature on it, with a person.

Do I need a design system to run this?

No. A design system makes the consistency questions faster to answer, but every question in the checklist can be answered by looking at the screen.

How often should this run?

Before anything ships to real users, and again after fixes. Reviewing the same screen twice with the same criteria is what lets you say the changes worked, rather than that they felt better.