Design and UX when the AI draws

Generate five screens in a row, describing each separately. Taken individually, all are presentable. Side by side, they use four shades of blue, three corner radii, two typographic scales and buttons that do not match. None is a failure; the set is incoherent.

This is the central difficulty of design in vibecoding, and it is widely misdiagnosed. People assume a taste problem and go hunting for better aesthetic prompts. It is a memory problem: the model does not know what it produced yesterday, and re-decides everything on every screen.

The real problem is incoherence

A user does not judge an interface screen by screen. They build expectations: primary actions sit here, this colour means danger, this card style means it is clickable. Every deviation breaks that expectation and costs a fraction of a second of hesitation.

This degradation is invisible while building, because you look at one screen at a time. It is immediately visible to a user walking the whole journey. That is why vibecoded interfaces often give a vague impression of amateurism without any single identifiable fault.

Set the frame before asking for the screen

The fix is not to describe each screen better, but to stop leaving the choice open. A design system, however minimal, turns an infinity of possible decisions into a small set of options.

Minimal really does mean minimal. CSS variables for colours, a spacing scale, two or three text sizes, one radius, one shadow. Thirty lines are enough to remove most of the drift.

:root {
  --color-primary: #003366;
  --color-accent: #e91e8c;
  --color-surface: #f0f3ff;
  --space-2: 8px;
  --space-4: 16px;
  --space-6: 24px;
  --radius: 12px;
  --text-sm: 14px;
  --text-base: 16px;
  --text-lg: 20px;
}

The instruction then changes in nature. Instead of "make a card with a light blue background and rounded corners", you ask for "a card using the existing variables, introducing no new colour and no new spacing value". The explicit prohibition matters as much as the request.

The systematic blind spots

Beyond coherence, three categories are almost always missing, because you do not think to ask and the model does not offer.

Every state other than the happy path

An AI generates the screen full of data. It generates neither the empty state of first use, nor loading, nor network failure, nor the case where a label runs to three hundred characters instead of twenty. Yet the empty state is the first thing every new user sees: it decides whether they stay.

• Empty — what does someone who has created nothing yet see, and what can they do from there?
• Loading — what happens during the two-second wait?
• Error — does the message say what to do, or only that something failed?
• Overflow — does a very long title break the layout?

Accessibility

Generated code readily uses a clickable div where a button belongs. Visually identical, but unreachable by keyboard, invisible to a screen reader and not focusable. Same logic for contrast: an AI picks colours that look right against its idea of a screen, not colours that clear a contrast threshold.

Three checks cover most of it: is everything clickable reachable by tabbing, does every field have a genuinely associated label, and is that light grey text on white still readable?

Mobile treated as an afterthought

Unless told otherwise, the model designs for a wide screen then bolts on adaptations. The result fits on mobile without being pleasant there: touch targets too small, tables overflowing, menus built around hover when a finger cannot hover. Asking for mobile first costs the same and gives a better result at both ends.

Describe intent, not a component

The difference in output between two requests often comes down to what you describe. Ask for a component and you get a component. Describe who it is for and what it must achieve, and you get coherent decisions you would not have known how to specify.

A dashboard for a tradesperson checking it on their phone between jobs, dirty hands, one free hand: they must see within three seconds whether they have been paid.

That sentence alone forces large touch targets, high contrast, a single dominant piece of information and no hover. None of those constraints was stated directly.

In practice

1. Write the variable foundation before the first screen, even roughly. Fixing it later is trivial; reconstructing it after twenty screens is not.
2. Explicitly forbid any off-system value on every request.
3. Ask for the four states in the first generation, not as a follow-up.
4. Review the whole journey in one sitting, never screen by screen — it is the only way to see incoherence.
5. Have a second model audit accessibility: it is a mechanical check, so it suits the tool well.