Generative UI: What Happens When AI Starts Building the Interface?
What generative UI is, how AI selects and fills interface components safely within a design system, and where traditional UI remains the better choice.
Quick answer
Generative UI is an interface in which an AI model chooses, at runtime, which interface elements to show for a request and fills them with data: a comparison table for 'compare these three plans', a short form for 'book a meeting with the supplier', a chart for 'how did returns change by month'. The screen is assembled for the task rather than designed in advance.
Done well, the model does not write interface code. It returns structured data that references approved components from your design system, and your application renders them. Generative UI suits open-ended tasks where the right view depends on the question. It is a poor fit for frequent, well-understood flows such as checkout and settings, where stable layouts are a feature.
Static UI vs dynamic UI vs generative UI
Most software already has dynamic UI: the same screen shows different data and states. Generative UI goes one step further: the structure of the screen is chosen per request by a model.
| Static UI | Dynamic UI | Generative UI | |
|---|---|---|---|
| Who decides the layout | Designers, at build time | Designers; data fills it | A model, at runtime, within limits |
| What changes per request | Nothing | Data and states | Which components appear, and their data |
| Predictability | Highest | High | Lower; must be constrained |
| Best for | Core flows, navigation | Dashboards, lists, accounts | Open-ended questions and tasks |
| Main risk | Rigid for edge cases | Complexity | Inconsistent or misleading screens |
What generative UI looks like in practice
AI-generated components. In an assistant, the answer to 'what are my open orders over 10,000?' becomes a sortable table with actions, not a paragraph. AI-generated forms. 'Change the delivery address for order 4471' produces a small form with the current address pre-filled and only the fields that matter. AI-generated dashboards. 'Show me how the campaign performed by region' assembles two charts and a summary card from approved chart types. AI-generated visualisations. The model picks a chart type and maps fields to axes, while your charting library draws it. Component selection. In every case, the model's real job is choosing from a menu: which component, which data, which actions.
Structured UI generation: how it works
The reliable pattern has four parts: a component catalogue the model can use, a schema for each component's properties, the model returning a UI description as structured output, and a renderer that validates and draws it with your real components. Google's open-source A2UI specification follows this approach: an agent describes the interface as declarative JSON, and the client renders it only from a catalogue of trusted components rather than executing generated code. Event protocols such as AG-UI carry agent state, tool progress and UI updates between an agent backend and the frontend. Getting the model to return valid UI descriptions is the same problem as any structured output, and rendering rich output safely in chat is covered in AI chat interface design.
User request ─▶ Model (with tool + component catalogue)
│
│ structured output, not code:
│ { component: "OrderTable",
│ props: { rows: [...], actions: ["track"] } }
▼
┌──────────────────┐
│ Validator │ schema check · allowed components
│ │ · allowed actions · data from tools
└────────┬─────────┘
▼
┌──────────────────┐
│ Renderer │ design-system components + tokens
└────────┬─────────┘
▼
Screen ─▶ user acts ─▶ action goes through normal APIs
(permissions, validation, audit)Key takeaway
Let the model choose components and fill props. Never let it invent components, styles or actions. The design system is the contract.
Safety and consistency
Generative UI introduces risks that static screens do not have. A model can choose a misleading chart, omit an important field, label a destructive action ambiguously or show data the user should not see. Treat generated UI as untrusted output:
- Render only from an allowlist of components with typed, validated props
- Never execute generated HTML or JavaScript in your main application context
- Take data from tools and APIs, not from model text, so numbers are real
- Route every action a generated screen offers through the same APIs, permissions and confirmations as hand-built screens
- Fix labels and styles of consequential actions in the component, not in the prompt
- Fall back to plain text or a standard screen when validation fails
- Log what was generated so problems can be reproduced
Design systems and component constraints
Generative UI makes a design system more important, not less. Each component needs a clear purpose, a short description the model can read, a props schema with sensible limits (maximum rows, allowed chart types, required labels) and documented do's and don'ts. Start with a small catalogue: text, card, table, list, form, chart, confirmation. Add components only when a real request needs them. Designers move from drawing every screen to designing components, rules and examples, then reviewing samples of generated screens for quality. A well-run design system is the prerequisite.
Where generative UI makes sense, and where it does not
| Good fit | Poor fit |
|---|---|
| Analytics and 'show me' questions | Checkout and payment |
| Comparing options with varying attributes | Navigation and information architecture |
| Temporary forms for one-off tasks | Settings and account management |
| Assistants that return structured results in a conversation | High-frequency workflows people learn by heart |
| Configurators with many optional paths | Regulated disclosures and legal text |
Worth noting
Not every interface should be generated. Most products will combine a stable core with generated views at the edges, where flexibility helps and predictability matters less.
Generative UI inside AI assistants
A growing share of generative UI appears inside assistants rather than inside your own app. MCP Apps, an official extension of the Model Context Protocol, lets a tool return an interactive interface that hosts such as Claude and ChatGPT render in a sandbox. That is a related but different design problem, covered in AI assistant app UX.
How to start
- Collect real requests where users struggle with fixed screens or long text answers
- Define a small component catalogue with schemas and descriptions
- Generate UI descriptions as structured output and validate them
- Use tools for data and existing APIs for actions
- Test with real questions; review a sample of generated screens weekly
- Measure task completion and errors against the non-generated version
Designing AI features into a product?
ZSpace Labs designs and builds AI interfaces on top of design systems, from component rules to the APIs behind them. See UI/UX design.
Conclusion
Generative UI lets a product show the right view for an open-ended request instead of forcing every task into a fixed screen or a wall of text. It works when the model selects from a constrained, well-described component catalogue, data comes from real systems and actions go through normal controls. Use it at the edges where flexibility helps, keep core flows stable and treat your design system as the contract. For how it fits with other patterns, see AI interface patterns and AI UX design.
Common questions.
Generative UI is an interface pattern in which an AI model decides, at runtime, which interface elements to show for a user's request (a form, a table, a chart, a set of options) and fills them with data, instead of every screen being designed and coded in advance.