Generative UI

Generative UI is what happens when the answer to a request is a built interface rather than a block of prose. Ask about last month’s spending and a panel comes back with the figures in it and a control for changing the period. Ask to book something and a form comes back with the fields already filled in. Two things have to be in place for that to work: a catalogue of components the product already ships, and a model whose output names one of them and supplies its data. The model is choosing and filling, not inventing, which is why this reads as a pattern rather than as a rendering trick.

The catalogue is the part that gets skipped in demonstrations and matters most in practice. When the model may only return a component name and a set of properties, every answer inherits the design system’s spacing, its colour roles, its keyboard behaviour, and its accessible names, and a wrong answer is a wrong choice from a known set rather than arbitrary markup arriving in the page. Free-form generated markup fails in all the boring ways at once: it cannot be tested, it drifts from the rest of the product on every request, and it is a live channel for whatever the model was talked into generating. Bounding the generation is what makes the pattern shippable.

The tension the term carries, and the one worth saying out loud, is that an interface generated per request cannot be learned. Interfaces get easier the second time because they are in the same place: muscle memory, a screenshot in a support article, a colleague saying “the button under the chart”. A screen assembled fresh each time has none of that, and it also has no stable target for a test, a bug report, or an accessibility audit. The practical answer is to keep the arrangement predictable even when the content is not: the same kind of question should produce the same kind of panel, in the same region of the screen, with a way to keep what was built so it stops being ephemeral.

Two neighbours are close enough to be worth separating. Adaptive layout also produces different screens for different situations, but the rules were written at build time and merely evaluated at runtime, so the set of outcomes is known and can be reviewed; here the choice is made per request by something that will occasionally choose badly. Progressive disclosure is about when to reveal parts of a fixed interface, not about which parts exist at all. Whatever else it borrows, a generated panel still owes the reader the ordinary courtesies: a state while it is being assembled, an honest one when the model got it wrong, and enough of the underlying data on screen that the answer can be checked rather than merely believed.