Generative UI is the practice of assembling an interface at request time from a stated intent and the surrounding context, rather than serving a layout drawn in advance. Instead of a fixed screen, the user receives a composition produced for that moment: the controls, copy, and arrangement are chosen when the request lands, against constraints the designer set rather than pixels the designer placed.
- An interface stops being an artifact and becomes the output of a function over intent and context.
- Designers specify outcomes and bounds; the runtime selects the concrete arrangement.
- Two users with the same goal may meet two different screens.
- Consistency moves from layout to behavior, since the layout is no longer fixed.
- Trust now depends on whether a one-time screen can be read and verified.
- Evaluation shifts from inspecting a mockup to sampling a distribution of renders.
What is generative UI when the screen is built per request?
Generative UI refers to interfaces that are composed at runtime from a model of intent and context, so the rendered result is a candidate among many rather than a single canonical design. The discipline treats a screen as derived output. What the user sees is one resolution of a space of possible compositions, narrowed by the request and the constraints in force.
This is a different object than a responsive layout. Responsive design rearranges a known set of elements across breakpoints; the element set and their relationships are still authored. Generative composition lets the element set itself vary: which fields appear, which actions are offered, how dense the result is, and what is omitted. The variation is the point, not an edge case.
The working definitions that have settled across 2025 and 2026 share one commitment. The interface is assembled from a description of what should be true after the interaction, paired with what is known about the situation, and the concrete form is left to the moment of rendering.
It helps to name what stays human in this picture. The intent, the vocabulary of components, and the constraints are still authored deliberately. What is delegated is the act of arrangement: the binding of those pieces into a specific screen for a specific request. Generation does not remove design judgment so much as relocate it from the surface to the rules that govern every surface.
How does design change from drawing screens to specifying outcomes?
When the artifact is generated, the designer's leverage moves upstream. The unit of work becomes a specification of intent, the permissible building blocks, and the constraints that any valid composition must honor. You stop arranging a screen and start describing the screen's acceptance conditions.
That sounds like a small relocation of effort, but it changes what "finished" means. A drawn screen is finished when it looks right once. A specified outcome is finished when every plausible render inside the bounds is acceptable, which is a far larger claim. The design surface widens from one composition to a family of them.
One tradeoff that surfaces is expressiveness against governability. Loosening constraints lets the runtime serve a sharper fit for each request and each context. Tightening them keeps the family small enough to reason about. The craft sits in choosing which decisions to fix as invariants and which to delegate to the moment.
| Property | Pre-drawn screens | Runtime-composed interfaces |
|---|---|---|
| Unit of design | A fixed layout | Intent plus constraints |
| What varies | Data inside slots | Slots, actions, density |
| Definition of done | One screen looks right | Every render in bounds is acceptable |
| Review target | A mockup | A distribution of outputs |
| Failure mode | Wrong static layout | Valid but disorienting render |
Can an interface stay consistent when no two renders match?
Consistency was historically carried by the layout itself: the same button in the same place taught the user where to look. When the layout can change per request, that anchor weakens, and consistency has to be re-expressed at a higher level than position.
The field's answer tends to be invariants. Certain relationships are declared non-negotiable regardless of composition: a destructive action is always confirmable, primary intent is always reachable in one step, the same concept always uses the same label and affordance. The runtime is free below those lines and bound above them.
This reframes a product language as a set of rules the generator must satisfy, not a screenshot it must match. Consistency becomes behavioral and semantic rather than spatial. The harder questions are about which invariants are load-bearing, because each fixed invariant trades away some of the adaptivity that justified generating the interface at all.
There is also a temporal kind of consistency to defend. A single user returning over days will meet different compositions, and the system has to feel coherent across that sequence even though no two visits align pixel for pixel. The anchors that carry this are conceptual: a feature keeps its name, an action keeps its meaning, and the mental model the user formed last time still predicts what happens this time.
Why is trust harder when a screen exists only once?
A screen that is rendered for a single request, then never seen again, complicates the usual sources of trust. Users build confidence partly through repetition and shared reference: the same screen others described, the same path they walked yesterday. A one-time composition removes that shared ground.
Trust then has to come from legibility within the render itself. The interface must make its own reasoning inspectable: why these fields, why this action is primary, what data shaped the arrangement. When a composition can justify its own shape, a user can verify it in the moment instead of relying on having seen it before.
Predictability provides a second source. Even a screen seen once feels trustworthy when it behaves the way its declared invariants promise, so the user can reason about what an action will do before taking it. The risk is the opposite: a render that is technically valid yet surprising, where the composition stayed inside its bounds but still defied what the user expected. Guarding against that surprise is as much a part of trust as exposing reasoning.
- Composition envelope
- The declared space of arrangements a generator may produce for a given intent, bounded by constraints.
- Invariant
- A property every render must hold regardless of composition, such as reachability of the primary action.
- Legibility
- The degree to which a one-time render exposes why it was assembled the way it was.
How do you evaluate a UI that is different on every request?
Inspection assumes a stable target. When the target is a distribution rather than a single screen, evaluation has to move from checking the one design to characterizing the population of designs the specification can emit. The question shifts from "is this screen good" to "is the envelope of screens acceptable."
A practical order of operations tends to look like this:
- State the intent and the context the interface answers, in terms a non-author can read.
- Declare the invariants every render must satisfy, and the bounds it must stay within.
- Sample many renders across realistic intents and contexts, including sparse and adversarial ones.
- Score each sample against the invariants and against task completion, not against a reference mockup.
- Tighten constraints where renders drift, and loosen them where the bounds suppress a better fit.
The shift is from a one-time design review to a standing evaluation loop, because the specification keeps emitting new screens after it ships. Coverage matters more than polish on any single render. An interface that is correct on the cases someone happened to inspect is not yet known to be correct, and the cases nobody inspected are exactly where a valid-but-disorienting composition tends to hide. Treating evaluation as sampling, rather than approval, is what makes that hidden region observable.
Where runtime-composed interfaces appear to be heading
The trajectory points toward interfaces treated less as documents and more as systems with behavior to be specified and monitored. As composition moves to runtime, the scarce skill becomes writing constraints precise enough to be safe and loose enough to be useful, then watching what the generator actually produces against them.
What gets harder is accountability for a screen no one drew. When a render misleads, the cause lives in the specification, the context, or the generator's choice within bounds, and separating those becomes its own discipline. Versioning a distribution, reproducing a single render, and explaining a one-time composition after the fact are open problems the field is still naming.
Tooling tends to follow that division. The instruments that mature are the ones for writing constraints, sampling renders, and tracing a single composition back to the inputs that produced it, rather than the ones for placing elements by hand. The center of gravity moves from the canvas to the specification and the monitor sitting beside it.
The likely settling point is a division of labor: humans own intent and invariants, the runtime owns arrangement, and a continuous evaluation layer sits between them. The interface stops being a thing that is finished and becomes a thing that is governed, which is a quieter but more demanding posture than drawing screens ever asked for.