Generative UI
Let the assistant build parts of a screen safely.
Generative UI means the assistant helps build the screen, not only the words. Instead of a long reply, a person may get a small chart, a form or a set of choices. This guide says how to do that safely.
What it is
Think of a line with two ends. At one end, the assistant writes plain text. At the other end, it builds a whole new screen. Most useful designs sit in the middle.
Text only
The assistant writes a reply. Safe and simple.
Parts from a list
The assistant picks approved parts, such as a chart or a button, and fills them in.
Its own page
The assistant writes a whole page. Flexible, so it needs a closed box around it.
Two ways to build it
Describe the screen as data
The assistant sends a plain list that says which parts to show and what goes in them. The app draws the parts. This is the safer way, and the one to try first. Tattva does it with .
Use a sandboxed frame
The assistant writes a whole page and the app shows it inside a closed box. The page cannot reach the rest of the app. Use it only when parts from a list cannot do the job. Tattva does it with .
The research notes describe the same split. One group of tools sends a description of the screen. Another group sends a page that runs in a frame.
The rules that matter
- Keep a catalog. Give the assistant a list of approved parts. Ignore anything else.
- The app owns the look. The assistant picks what to show. The app picks colors, spacing and type.
- Fall back to text. If a screen is invalid or fails, show the same answer as plain text.
- Confirm what matters. Ask before anything that sends, pays or deletes, in the app's own words.
- Label what was generated. Say who made the screen. Offer Regenerate and a way to report a problem. See .
- Keep the sandbox closed. A page that runs its own code gets no access to the app. Opening a link or running a step needs a yes each time.
When not to use it
It does not suit every task. The research says it works best for exploring, for dense information and for conversations with many turns.
- Simple tasks that people repeat, such as paying a bill. A fixed screen is faster and calmer.
- Places where consistency matters, such as checkout. People should find the same button in the same place every time.
- Anywhere a wrong screen would cost money or trust and a plain reply would do.
How to check quality
Do not trust one good result. One study, EvoGenUI-Bench, found that the best models passed about 75% of single turns but completed only about 37% of five-turn runs. So test screens over several back-and-forth turns, not just the first one. It is a single recent paper, so treat the numbers as a warning and not as a rule.
- Run the screen in a real browser and look at the result, not only at the data behind it.
- Try bad input: an unknown part, a missing label, a style the app did not ask for. The app should fall back to text.
- Check that every button still works after the person asks for a change.
- Automatic checks catch missing labels. They cannot tell if a label makes sense, so have a person read it.
Go further
- Patterns: , and .
- Parts: , and .
- For AI tools: /genui/prompt.md, a ready-made instruction for building screens from the catalog, and components.json, every component in one file.