Generative UI Runs on Your Design System

The next day, the OpenUI team published a teardown of ChatGPT's implementation. It describes a model assembling native interfaces from a catalogue of components, with a separate route for custom mini apps. That catalogue shows how a design system can become a contract for the model.

Generative UI also includes fully generated interfaces without predefined components. I see component-based generation as a good fit when user needs and product scenarios are understood. Full generation can be useful for broader requests or less defined scenarios. The choice depends on the product. For the component-based approach, the design system is one of the key design artefacts the team owns.

Inside a component catalogue, the model composes

Google's dynamic view designs and codes a customised interactive response for each prompt. OpenAI's native component approach gives the model a different set of building blocks. These are two ways to create an interface at runtime, with different uses and constraints.

OpenAI describes a library of native, streamable components and a compiler. According to OpenUI's reconstruction, the model chooses components from ChatGPT's library and describes how they fit together and behave. ChatGPT checks that description against the library's rules, then displays the interface.

The practical question is what you let the model build with. A clear catalogue gives the team control over the available parts. It still leaves the model to decide which parts belong in the response and how to arrange them.

I put quality in both places: the component library needs to cover the product's use cases, and the model needs to choose and combine those components effectively. Good parts account for a substantial share of UI quality. They do not determine success on their own.

Your design system becomes the contract

OpenUI describes a catalogue of native components, design tokens, and prebuilt composites. In the web responses they examined, the interfaces looked like ChatGPT. This is a picture of the current implementation, not a guarantee about every generative system or every platform.

That catalogue is a design system with a new reader. Designers need to understand its components. Engineers need to implement them. A model needs enough guidance to choose them for the user's request.

So the questions change. Not "Is this component documented?" but "Can a model tell when to use it and when not to?" Not "Do we have tokens?" but "What constraints should this product enforce?"

In my experience, component descriptions and constraints give the model guidance, while gaps can leave room for assumptions. A component catalogue should make its intended uses legible without assuming that documentation alone guarantees the right composition.

On another project that is not yet available for a showcase, I worked with a custom component set that performed well and stayed aligned with the wider design system. A product-specific catalogue can extend the system coherently.

The Gradient team ran into the output problem while building Norvana, an AI-native personal health companion. Oleg Gasioshyn, founding partner and design director at The Gradient, who designed Norvana, describes the trade-off between plain text, rigid templates, and free-form output in his account of the project.

What worked was a library of text blocks, metric cards, biomarker visualisations, and nutritional breakdowns. The model chooses the blocks and their order through tool calls, while the team designs their appearance. Some flows stay fixed, with room to add a card when a meal affects an out-of-range biomarker.

The aim is a catalogue the model can use well, with enough coverage for the product's needs.

Designing generative UI for the half-built screen

Streaming text is easy to follow. Each new word lands at the end of the last one. Streaming an interface creates another design problem.

For part of a response, the interface is unfinished. A table may have three rows of an eventual 10. A chart may have an axis and no data. A form may appear before the user knows whether it is ready to use.

In their captured responses, OpenUI observed repeated updates every few hundred milliseconds, preserved control state, and retention of the last working interface when an update failed. These are observations from their reconstruction of the web client.

The design work is deciding what appears first, what holds still, and what the user can touch before the response ends. Motion can help communicate that the interface is still growing rather than leaving the user to interpret a jump.

In my work, components already have in-progress states, error states, and alternative views depending on the content. Generative UI adds the question of how those states behave as an interface arrives in parts.

That in-between needs deliberate design: when a control becomes available, what the user sees while content is missing, and how the interface recovers if the next part cannot be displayed.

The model builds the tool. Local interactions run without it.

For product teams, one useful distinction is between generating a tool and using it. In OpenUI's pricing example, dragging a slider recalculates the total locally without a new model call.

The model decides what tool the user needs and assembles it. Local controls can then behave like ordinary software. A new question is a different action: OpenUI also describes buttons and forms that send a new message to the model.

The model can choose the type of interaction too, not only the content. Gasioshyn describes Norvana asking a tappable clarification when it is unsure what a user photographed on their plate. When confident, it answers directly. The context guides whether it asks or answers, rather than requiring the designer to map every branch in advance.

The design question becomes where to draw that line. What should the model generate once, and what should the user explore without asking again? Which action needs new reasoning, and which should update the tool already on screen?

A useful generative feature can hand the user a working instrument, with a clear route back to the conversation when another model response is needed.

Design the fallback before you need it

No component set covers everything. OpenUI describes an AppBlock route for custom HTML, CSS, and JavaScript mini apps, including a drum machine. It sits outside the native component catalogue. That is one implementation choice, not a requirement for every product.

A product can choose a different response when its catalogue cannot meet a request. It can answer in text or offer a designed fallback component, such as a form that asks the user to clarify what they need.

For product use today, I would choose those fallbacks before allowing unrestricted UI generation. In my experience, current model output does not yet give me enough confidence to make free-form generation the default fallback.

The decision depends on the product and the user's need. Define what happens when the available components are not enough, and make that response part of the experience. A fallback can be useful without inventing a new interface.

Inside ChatGPT, the native response speaks ChatGPT

A native generated response uses the host product's visual language. OpenUI's examples show the familiar ChatGPT interface. For brands, that raises a product question about where the interaction takes place.

Imagine a mortgage calculator, a telecom plan comparison, or a symptom checker appearing in a ChatGPT response. These are hypothetical scenarios, not documented deployments. The user could interact with the generated tool before opening a brand's own product.

Brands can also provide their own app UI within ChatGPT. Native generated responses and app experiences are different surfaces. The opportunity for a product team is to decide which interactions belong in its own experience and which can happen through a host.

For fintech and healthcare teams, that decision includes how the interface communicates context and trust. A component-based generative feature inside their own product can use their catalogue, tokens, and rules.

Generative UI is not necessary for every product or every scenario. In my experience, it can make the experience better by shortening the path to what the user needs. Whether to use it, and how much freedom to give it, depends on the client's needs.

Where to start with generative UI

Most teams will start with the system they already have. They need a clear product use case before deciding how much interface generation to introduce.

1. Audit your design system for a machine reader. Could a model choose the right component from its description alone?
2. Define what the model must never build, not only what it can.
3. Design the in-between states: partial, growing, and recovering. Build on the loading, error, and content-dependent states your components already need.
4. Decide your fallback before a user's request forces the decision. Text, clarification questions, and dedicated components are options.

The models can already generate interfaces. What they build with, where they have freedom, and how the experience handles a request it cannot fulfil are still design decisions.