A UI task is easy to phrase as "make it look good" and to accept from a single screenshot where everything is in place. That is exactly how an interface is born that looks great in precisely one state and at one screen width - the one that made it into the screenshot. Everything else - empty data, a network error, a narrow phone, long text, a keyboard instead of a mouse - stays uncovered, because it was never agreed on.
The naive move is to judge an interface as a picture. There is a mockup, there is a result, they look alike - the task is done. This model carries over to a live UI the logic of a static image, which has no states, no input, no different screens. But an interface is not a picture but a behavior: the same layout lives through loading, emptiness, an error and success, and "looks like the mockup" describes only one frame of that life.
It breaks on everything that did not make it into the happy path. A list beautiful at ten items breaks at zero and at a thousand. A button neat in English falls apart on a long localization. A form convenient with a mouse turns out impassable from a keyboard. A layout tuned on a laptop overlaps itself at 320 pixels. Each of these failures is invisible on a single screenshot and inevitable in real use.
Hence the notion of a visual contract - of what must be named before the edit, not judged after. It includes: the reference or mockup, design tokens instead of magic values, the target viewports, the mandatory loading, empty and error states, and accessibility requirements. A separate line of the contract is to reuse existing components rather than breed new ones: this keeps the system consistent and does not dilute the same tokens with new variants.
Why states and tokens matter more than an exact pixel match. Pixel-perfect on one screen is a fragile goal: it breaks from a change of data or width. A contract of states and tokens, on the contrary, describes behavior that is portable: if loading, empty and error are defined and built from shared tokens, the interface holds its form on data the mockup's designer never drew at all. An agreement about behavior outlives what an agreement about a picture did not foresee.
The check of a UI comes not from imagination but from Browser Preview - and it has a documented peculiarity. Preview proxies your local dev server and lets you select elements and capture console errors, but the agent does not see the page automatically: you yourself pick which element and which error to send it as context. That is, the visual feedback is curated by a human - and the quality of the check depends directly on whether you showed the agent not only the happy path but also the broken states.
The cost of a skipped contract is paid where you are not - on other people's devices and data. An interface accepted from a single frame meets the user with a blank screen without explanation, unreadable contrast, a form there is no tabbing out of, or a layout that fell apart on their phone. These defects are invisible to the author because the author looked at their own screen with their own data; they are found by someone whose conditions differ, and found painfully. And you then fix them blind: from a terse bug report on someone else's device instead of your own screen, where all of it would have been visible at once.
This does not mean every label must be run through the full checklist. A pointed edit of a margin or a color inside a finished component is checked by a glance on the spot. The visual contract pays off where a new state, a new screen or user input appears: the more states an interface has and the wider the spread of devices, the more expensive it is to do without an explicitly named agreement about behavior.
You must check a UI by a list, not by an impression, and this list is concrete. Keyboard focus and the tab order. Contrast and an accessible name on interactive elements. Behavior on long text and another locale. Three widths - narrow around 320-390 pixels, medium and wide. A network error and a resubmit. Walk this list in Preview, sending the agent not only the successful but also the broken states, and "looks good" turns from an impression into a verified fact.
The typical failures repeat the skipped items of the contract. No states - a blank screen instead of an empty state and a white screen instead of a handled error. No accessibility - an interface impassable from a keyboard and invisible to a screen reader. No width check - a layout alive only on the author's screen. No Preview curation - the agent "fixed" what already worked, having never seen the broken parts. The sign of all of them is the same: the result was accepted by the happy path without naming the other states. Name the contract in advance, and there will be something to check rather than something to admire.