Designing for generative UI: constraints instead of screens
By Allan Leone on
When the model composes the layout at runtime, the screen stops being the deliverable. What replaces it is a set of rules about what the interface is allowed to become, including the worst version it can produce.
Responsive design forced a shift that took the industry about five years to absorb. Stop drawing one screen, start drawing a system that holds up at any width. Generative UI asks for the same shift one level further out.
If the layout is assembled at runtime from user intent, then handing over a composition is handing over a single sample of the output. Useful as an illustration. Not a specification.
What the deliverable becomes
Four categories of rule cover most of it, and they are worth writing down separately because teams tend to only produce the first one.
- Composition rules. Which components may appear together, and which combinations are forbidden. A confirmation dialog and an inline edit affordance for the same record should probably never co-exist.
- Priority rules. What wins when three things are all technically relevant. Without this the model surfaces whatever it scored highest, which is not the same as what matters.
- Confidence rules. What the interface does when the model is sure, and what changes when it is not. This is a visual state, not an error path.
- The floor. The worst layout the system is permitted to produce.
The floor is the part people skip
Everyone designs the happy path, because that is what gets shown in the review. The floor is the interesting artefact, and it is the one that stops a generative interface embarrassing you in front of a customer at two in the morning.
Concretely, the floor is a set of guarantees that hold no matter what the model decides. There is always a way back. Primary actions never move below the fold. Nothing renders more than two nested levels of generated structure. If confidence drops below a threshold, the layout falls back to a fixed template rather than improvising.
Writing those down is unglamorous and it is the only part of the spec that is genuinely enforceable in code.
What this does to review
You cannot approve a generative interface by looking at a screen, because the screen you are looking at is one draw from a distribution. Review has to move to sampling: generate twenty outputs across a spread of realistic inputs, including the ugly ones, and look at the worst three.
That is a different meeting than a design review, and it needs different inputs. Real data, including the account with one record and the account with fifty thousand.
Where to start
- Take one screen in your product that is a candidate for generation and write its floor. Five guarantees, one sentence each.
- List the component pairs that must never co-occur. This is usually a short list and nobody has ever written it down.
- Define what low confidence looks like visually before you build the feature, not after the first complaint.
- Change one design review into a sampling review. Twenty generated outputs, worst three on screen, decide from those.
Tags: ai, ux, generative-ui