Reviewing a Claude-generated UI for real issues

Why "it looks right" is the weakest possible review

A generated UI that renders correctly and matches the intended visual design has cleared the lowest bar, not the whole review — a UI can look completely correct in a screenshot and still fail on accessibility, break at a viewport size nobody checked, or handle real, messy content far worse than the placeholder text it was built and reviewed against. Treating "it looks right" as sufficient review is how UIs ship that work in the demo and fail on real, varied, unpredictable content in production.

Test with real content, not the content it was generated against

A UI reviewed only against whatever placeholder or example content was in the original prompt tends to look deceptively solid, because that content was, by construction, well-behaved — the right length, the right shape. Real content is messier: longer than expected, shorter than expected, missing entirely in some field, containing something unusual. Testing against a deliberately awkward range of real-shaped content — an unusually long title, an empty state, a very short label — surfaces layout and logic problems a review against tidy example content never will.

Check the states a screenshot can't show

A static review only shows one moment in time — whatever state happened to be visible when you looked. Interactive states (hover, focus, active), transient states (loading, an in-progress action), and error states all need to be actually triggered and reviewed individually, not inferred from how the resting state looks. A component that looks polished at rest can still have a completely unstyled or broken loading state that nobody noticed because nobody actually triggered it during review.

Verify behaviour, not just appearance

Visual review confirms a UI looks like what was intended; it says nothing about whether the underlying behaviour is actually correct — whether a form validates properly, whether an interactive element does what it claims to do, whether state updates correctly as a user interacts with it. These need functional review, separate from and in addition to a visual pass, since a component can be pixel-perfect and behaviourally broken at the same time, with neither issue visible from the other kind of check alone.

Accessibility and responsiveness need their own dedicated passes

A visual review, even a careful one, is not a substitute for an explicit accessibility check or an explicit test across viewport sizes — both are properties that a UI can appear to satisfy at a glance while genuinely failing on closer, dedicated inspection. See prompting Claude for accessible HTML and prompting Claude for responsive layouts for what each of those specific reviews actually needs to check.

Treating a generated UI with the same scrutiny as any other code

There's a subtle tendency to review generated UI more leniently than hand-written code, on the assumption that it was produced quickly and casually and therefore doesn't warrant the same level of scrutiny — that assumption is backwards. Generated code deserves at least the same review rigour as code written by a person, precisely because it hasn't already been through the implicit review that happens naturally while a person writes something by hand, line by line, catching some issues as they go.

Building a review checklist rather than relying on impression

The most reliable defence against reviewing only what's easy to notice at a glance is a written checklist — states covered, content variety tested, keyboard behaviour verified, contrast checked — applied consistently rather than relying on whatever happens to catch your eye each time. A checklist run the same way on every generated UI catches the categories of issue that a purely impressionistic review, however careful, tends to miss inconsistently from one review to the next.