Generative UI: when AI draws the screen

For three years, talking to an AI has mostly meant reading. You ask a question and get paragraphs back, maybe a table, maybe a list. That is starting to change, and the change has a name: generative UI.

The idea is that the model answers with an interface instead of text. Ask about mortgage options and you get a calculator with sliders. Ask how your sales went last quarter and you get a chart you can filter. Ask to rebook an appointment and you get the three available slots as buttons.

Last week made this hard to ignore. On 18 November, Google launched two experiments in the Gemini app, called dynamic view and visual layout, which build a custom interactive page for a prompt on the spot. The same technology reached Google Search's AI Mode for paying subscribers in the US. Three days later, OpenAI and Anthropic, together with the team behind an open-source project called MCP-UI, proposed a shared standard called MCP Apps for putting interactive interfaces inside AI conversations.

Two very different things share the name

When people say generative UI they mean one of two things, and the difference matters for anyone deciding what to build.

The first is the model choosing from parts you have already built. Your team designs a product card, a booking widget, a comparison table and an order-status panel. The model decides which one fits the moment and fills it with real data. OpenAI's apps inside ChatGPT, launched in October, work this way: the company provides the interface, ChatGPT decides when to show it. Developer tools like Vercel's AI SDK and CopilotKit have supported this pattern for a while.

The second is the model designing the interface itself, writing the layout and code from scratch for each request. That is what Google's dynamic view does, and what Anthropic showed in September with Imagine with Claude, a five-day research preview where Claude generated working software screens as you clicked.

The first is ready for real products today. The second is impressive and not yet something we would put in front of your customers.

Why the freeform version is not ready

Google's own research is candid about the limits. In its testing, people preferred these generated pages to plain text answers, but pages designed by human experts still scored best. Generation can take a minute or more. And the pages sometimes contain mistakes.

That last point deserves more weight than it usually gets. A wrong number in a paragraph looks like a wrong number. A wrong number in a polished chart with a legend and a filter looks like a fact. Good design makes information more convincing, which is exactly why it needs to be right.

For a business there are other problems too. A freeform interface will not follow your brand reliably. It is hard to test, because there is no fixed set of screens to check. Accessibility is a gamble. And running code a model just wrote, inside your product, needs careful sandboxing.

Where the practical version helps

The constrained version, where the model picks from your components, solves real problems. A few we think are worth building:

• Support chats that show an order's status as a card with "change address" and "talk to someone" buttons, instead of a paragraph and a link.
• Product finders that ask two questions and answer with a comparison table of three real products, with prices and stock pulled live.
• Internal dashboards where a manager types "leads by city this month" and gets the chart, built from a fixed set of chart types your team trusts.
• Booking flows inside a chat or a WhatsApp-style assistant, where the slots are buttons and the confirmation is a proper summary.

In each of these the model handles the language and the choice. Your components decide how it looks and where the data comes from. If a button books something or spends money, it goes through the same checks it would anywhere else in your product.

What it means for your product

One consequence surprises people: your design system matters more. If a model is going to assemble screens from your parts, those parts need to be well defined, consistent and documented, so the model, and your developers, know exactly what each one is for. A messy component library becomes a messy AI interface.

It also suggests a sensible order of work. Start with the two or three moments in your product where a text answer clearly falls short: someone comparing options, someone checking a status, someone picking a time. Build proper components for those. Let the model choose between them. Measure whether people finish the task faster than they did with text.

The freeform version will improve quickly. Google, OpenAI and Anthropic are all investing in it, and a shared standard for interfaces inside chat would let a business build once and appear in several assistants.