Generative UI

Generative UI means the interface is assembled at runtime by a model rather than laid out in advance by a designer. The system decides which components to show and how to arrange them for a particular request.

This is a narrower thing than "AI in the design process". Using a model to help produce a layout still ends with a fixed layout that ships. Generative UI means the layout itself is produced per request, and two people asking similar questions may not see the same arrangement.

Where it fits

The case for it is genuine and specific: the shape of the answer varies and cannot be anticipated.

A question that is sometimes best answered with a table, sometimes a chart, sometimes a short paragraph and sometimes a form is a reasonable candidate, because designing one layout means being wrong most of the time. Analytics, support and anything conversational sit here.

The case against it is everything else. Where people do the same task repeatedly, a designed layout wins on every dimension that matters: it can be learned, documented, supported and tested.

What it costs

Muscle memory disappears. The largest cost and the least discussed. Professional users get fast because things are where they were yesterday. An interface that rearranges itself denies them that permanently, and in a tool somebody uses for six hours a day that is a significant tax.

Support becomes hard. "Click the button at the top right" stops being sayable. Help articles, onboarding and training all assume a stable arrangement.

Testing is harder. You can test a layout. Testing a generator means testing a distribution of layouts, and the bad ones are the ones you will not see in a session.

Trust suffers from incoherence. A model can assemble something no designer would have shipped. One genuinely odd arrangement makes people wary of the rest.

Accessibility is unpredictable. Focus order, landmarks and reading order all depend on structure, and structure is now variable.

Constraining it so it works

The difference between a usable generative interface and a mess is how tightly the generation is bounded.

Compose from a fixed component set. The model chooses among documented components rather than producing markup. This is the single decision that most affects the result, and it makes a design system a prerequisite rather than a nicety.

Fix the frame. Navigation, headers and primary actions stay where they are. Only the answer region is generated, which preserves most of the muscle memory.

Write composition rules. Which components may contain which, what may not appear together, how many elements before it becomes noise.

Have a fallback. When the model produces something that fails validation, fall back to a plain, always-correct presentation rather than showing whatever came out.

Log what was assembled. Support cannot help with a screen nobody can reproduce.

The honest assessment

Measured demand for the term is small and falling — it was 251 a year ago and is 84 now — which suggests the idea is being absorbed into ordinary product work rather than becoming a category of its own.

That is probably the right outcome. Most products need one or two regions that adapt, inside a frame that does not. Describing that as generative UI overstates it, and building a wholly generated interface understates how much of an interface's value comes from staying still.

Telling it apart from what it is often confused with

Three adjacent things get called generative UI, and only one of them is.

A model helping you design. Output is a fixed layout that ships. This is a tooling change, and the interface is conventional.

A model filling a designed layout. The arrangement is fixed; the content within it is produced per request. This is most AI features, and it carries none of generative UI's costs.

A model choosing the arrangement. Only this is generative UI, and it is the one that trades away muscle memory, supportability and predictable accessibility.

Being precise matters commercially as well as technically, because the second is usually what somebody means when they ask for the third, and it is far cheaper to build and better to use.

In practice

An analytics product replaces its fixed dashboard with a generated one: ask a question, get whatever presentation the model judges best.

Demonstrations are excellent. Daily use is not. Analysts checking the same four numbers every morning get a different arrangement each time, so a task that took fifteen seconds now takes a minute of reading. Two of them start exporting to a spreadsheet instead, which is where they had been before the product existed.

The version that works keeps a fixed dashboard for the recurring questions and generates only the answer to an ad-hoc query, in a panel beside it. The generation earns its place where the question is genuinely novel, and stays out of the way of the work that repeats.

Where teams get it wrong

• Generating what repeats. The same task deserves the same layout.
• Free-form markup. A new visual language per request.
• No fixed frame. Nothing to orient against.
• No fallback. Whatever the model produced, shipped.
• Testing one output. The distribution is the product, and the bad tail is invisible in a demo.