Prototypes that obey the design system, and say what they could not check

A prototype that looks right and is not

Business analysts at a mid-size enterprise software company had started to prototype screens with an AI tool, to show engineering what they meant before asking for it. The pages looked convincing. Many used colors, components and wording that the design system does not have, and engineering found out in review.

Take Marina, an analyst two months into the job, who needs to show an order-approval screen. She can write the brief. She cannot tell whether the page the tool gives back is made of the real design system, and nor can the tool.

What I owned, and what I did not

I ran the decisions: what the tool should check, what it should block and what it should only warn about, what its report may claim, and what to leave out of the first version. I wrote the specification, split it into tickets and did the reading that the rules rest on.

I built it with Claude Code under my direction, so I do not claim every line. I also did not run the pilot: no one but me has used it yet, and the case says so.

What I found reading the field

Before choosing rules I read how others check AI-generated interfaces against a design system. These are findings from that reading, not measurements of mine.

• A simple validator only reaches the shallow layer

  It catches a name or a token that does not exist. It does not see whether a component is used the way it should be, or anything a script builds after the page loads.

• A class with no CSS raises no error

  The build stays green and the element simply has no style. The only reliable check is against the compiled CSS, not the source.

• An agent can optimize for the validator

  If it can read or change the check, it may learn to pass it instead of fixing the page.

• A separate verifier helps, but is not enough

  Splitting the check from the agent closes some holes. It does not close the validator's own blind spots, which is why the report has to name them.

The thesis, and three decisions that follow from it

I started from the idea that automatic checking beats human review. The reading and my own first runs argued against it. The check is cheap and fast, but it cannot see most of what makes a page right. So the thesis became: the checker does not replace the reviewer, it says what it checked and what it did not, and leaves the reviewer only what it cannot cover.

• The report says what it checked and what it did not, never just “validated”

  Each finding is verified, not verified or blocked. The report is written by the script from what the checks found, not by the model. I dropped a 0 to 100 score: a number reads as proof, and a list tells a person where to look.

• Block on some things, warn on others

  A missing token, class or component and text that is not in the brief block delivery. Sample data and missing states only warn, because they need judgment. Blocking on everything would teach people to ignore the check.

• A component the system does not have is allowed, with a visible mark

  Refusing it would stop the analyst. Allowing it unmarked would let engineering assume it exists. A “Proposal” mark says: this one still has to be built.

From briefing to a report that admits its limits

1. Briefing→
2. Summary and component list, approved→
3. Page drafted→
4. Level 1 check→
5. Fix and re-check→
6. Report with “Not verified”

The person approves a summary and the list of components before any page exists, so a component that is not in the system is caught before it is drawn. Level 1 is static: it reads the page and the brief. Level 2 is optional and runs on the rendered page for accessibility problems. Both are in the design; only part of level 1 is built.

Try the workbench: generate a page, watch it blocked and corrected, then plant a styled div. It passes, and the report says it could not tell. That is the behavior I care about most.

What the figures say, with the arithmetic

Review rounds with engineering, 3.1 to 1.2

−61%

Conformity on the rules the checker covers, 54% before

96%

Conformity counting everything, 54% before

84%

Analysts who finish alone, 2 of 9 before

8 of 9

All of these are illustrative figures for the recreated tool, not a measured result: no pilot has run. The two conformity numbers are the point: of the 16 points still wrong out of 100, 13 are in the layer no check reaches. The checker fixes what it can see and a person still has to review the rest.

The time falls from 2.5 days to 35 minutes only because one is calendar time (days in a designer's queue) and the other is active time. Read it as a direction, not a like-for-like comparison.

What would count as a pass

I set the bar before running the pilot, so the result cannot be bent to fit. With a few analysts and a set of planted defects: the report must list every planted defect as blocked or as not verified, never as fine; and most analysts must finish a page on their own. If a planted defect comes back clean, the checker is the problem and the figures above mean nothing.

The failure that shaped the report

Early on, the setup command told people they could go ahead while it had not managed to run a single check. A reassuring message about nothing verified. Around the same time, the template that ships with the tool used a class its own checker would have rejected. Both were the same mistake: sounding sure without having checked.

That is why the report always carries a “Not verified” block, even when everything passes. A report that does not say what it left out is worse than no report.

• Still open: the agent may learn to pass the checker

  Running the verifier in a separate process, with the agent unable to change its rules, is designed and not built.

• Still open: no one has used it yet

  A pilot with a few analysts and a set of planted defects, to confirm the checker misses none of them, is the next step.

Related: the design system governance case shows the state of the catalog this checker reads from.