Tools that turn a prompt into screens are genuinely useful: a founder can have a plausible interface in an afternoon. The screens share a signature, though. They show the happy path, on a wide display, for a user with a short name, a fast connection, a mouse and perfect eyesight, with data that fits. Real users have none of those guarantees. Product design happens in the difference. Here is what a product designer adds, in order.

What generated UI reliably misses

Nielsen Norman Group draws a useful distinction between generative UI (interfaces assembled live for each user, still mostly future) and AI-assisted design (tools like v0 or Uizard that accelerate a designer's work, very much present). Their assessment of the second is that it speeds up ideation and prototyping while the fundamentals of the job stay with the human: understanding the user, defining constraints, testing outcomes. That matches what shows up in generated screens in practice. The model optimises for a convincing screenshot. It does not know your users, your data, or your constraints, and it cannot see the screen at 360 pixels wide or through a screen reader.

The sequence

1. Map the real flow, not the screen order

Generated screens arrive as a sequence the model invented. A designer starts from the user's task and asks what the shortest honest path through it is. Six screens often become four. Steps the model added because they looked like a flow ("welcome", "tell us about yourself") are questioned. The result is a flow diagram that the screens must serve, not the other way round.

2. Design every state

Each screen has at least five versions the model did not draw: empty (first use, no data yet), loading, error (network, validation, permission), partial (some data, some failed), and success. Empty states are where products lose new users; error states are where they lose trust. The designer draws each one with real copy, not "Something went wrong".

3. Feed it real data

The 40-character company name. The list with 400 items. The price in a currency with no decimals. The date in a locale that puts day first. Right-to-left text. A user with no avatar. Generated UI breaks on all of these because the sample data was tidy. The designer stress-tests layouts with the ugliest real data available and fixes truncation, wrapping and overflow.

4. Make it responsive, from the phone up

Render at 360, 390, 768, 1024 and 1440 pixels. Generated layouts usually assume the widest one. Navigation, tables, side-by-side panels and dense forms all need a decision for narrow screens, not a squeeze. Touch targets need to be at least 24 by 24 CSS pixels (WCAG 2.2 AA) and comfortably larger where thumbs are involved.

5. Accessibility to WCAG 2.2 AA

This is a checklist, not a vibe. Contrast 4.5:1 for text and 3:1 for large text and UI components. Every interactive element reachable and operable by keyboard, with a visible focus indicator (WCAG 2.2 added requirements on focus appearance and on not obscuring the focused element). Form fields with real labels, not placeholders. Errors identified in text, not only in colour. Images with alt text. Motion that respects the reduced-motion preference. Generated UI fails most of these by default because none of them are visible in a screenshot.

6. Refine interaction details

What happens on hover, press, focus, disabled, and while saving. How long feedback takes to appear. Whether a destructive action confirms. Whether the form remembers what you typed after an error. Generated screens are static pictures; the designer specifies the behaviour, ideally in a prototype a developer can inspect.

7. Consolidate into components

Generated screens tend to have four slightly different buttons, three card styles and inconsistent spacing. The designer reduces them to a small set of components with defined variants and a spacing scale, so that the interface is consistent and the developer builds each thing once. This is also where the interface starts to look like a product rather than a collage.

8. Test with people who are not you

Three to five sessions with real or representative users, doing the core task, thinking aloud. Nothing else finds the problems that this finds. The designer writes down what changed as a result; that list is evidence of the work and the start of the next iteration.

Generated screens answer "what could this look like?" A product designer answers "does this work, for these people, on their devices, when things go wrong?" Only the second question ships.

A definition of done

Task flow mapped and reduced to the necessary steps. Every screen has empty, loading, error, partial and success states with real copy. Layouts hold with worst-case real data. Responsive at 360, 390, 768, 1024, 1440; touch targets at least 24 px. WCAG 2.2 AA: contrast, keyboard operability, visible focus, labelled fields, text-based error identification, alt text, reduced-motion respected. Interaction states and behaviours specified in an inspectable prototype. Components consolidated with variants and a spacing scale. Three to five usability sessions run; changes recorded. Hand-off package a developer can build from without questions.

What to give the designer

The generated screens as editable files where possible, the prompt, a one-paragraph description of the user and their task, the ugliest real data you have, the devices your users actually use, and any brand or component constraints. Then let them propose the flow before they touch a screen.

How this was made: written by the After AI Work team from UX work on our own platform and interfaces. Framing of generative UI versus AI-assisted design from Nielsen Norman Group, "Generative UI and Outcome-Oriented Design". Accessibility thresholds from WCAG 2.2, the version referenced by ISO/IEC 40500:2025 and the 2026 EN 301 549 European standard. AI tools helped outline the sequence; every step was rewritten and checked by a person.