AI interface design: what changes when part of the interface is generated

AI interface design used to mean designing fixed screens that display a model's output. It can now also mean designing the rules a model follows when it decides part of the interface itself: which component to show, what goes in it, and sometimes the layout or the code. Because nobody will see every screen the product shows, the designer's specification moves from screens to a catalogue of approved components, rules for combining them, the parts that must never change, and the checks every generated result has to pass.

That shift takes away four things a fixed screen gave a team without effort: consistency, accessibility checked once, tests against a known layout, and a design system that only people had to read. This article covers each one, starting with the decision that sets how much of all this applies to you.

How much of the interface is generated?

"Generative UI" covers very different amounts of model control. Reading the platform makers' own documentation side by side gives at least four levels (the grouping is ours), and each one moves more of the design work from the screen to the system around it.

The level is a product decision, not a technology choice. Our rule of thumb: use the lowest level that does the job, and go higher only where a fixed design genuinely cannot anticipate what people will ask for.

Level 4 is impressive, and it has costs. In Google's own evaluation, human raters, setting generation speed aside, overwhelmingly preferred the generated interfaces to plain markdown answers, but expert-designed websites still scored higher, and the generated results were "at least comparable" to them in about half of cases. Google's announcement also notes that generation "can sometimes take a minute or more" and that outputs contain "occasional inaccuracies". That profile suits a one-off answer that explains something. It suits a screen people return to every day to do their work far less, which is our judgement from those limits rather than something Google states.

Consistency: what the adaptive-interface research already found

Generated interfaces are not the first interfaces that change themselves. Human-computer interaction research on adaptive interfaces goes back decades, and two studies by Krzysztof Gajos and colleagues bear directly on the consistency worry.

In a 2006 study, a "split" interface that copied frequently used functions into a separate adaptive toolbar, leaving the original toolbars untouched, made people significantly faster than a non-adaptive baseline and was strongly preferred. A "moving" interface that promoted buttons by shifting where things sat was only marginally faster than the baseline and was not rated significantly higher than it, and some participants found it disturbing that other buttons changed position. The two adaptive designs did not differ significantly from each other on speed or satisfaction ratings, but the split design was the one people ranked first. The authors' conclusion was to duplicate rather than move.

A 2008 follow-up tested which mattered more: how predictable the adaptation was, or how often it put the right thing in front of the user. Contrary to the authors' own expectations, accuracy had the stronger effect on performance, use and some satisfaction ratings. In that study the static toolbar never moved; only the separate adaptive area changed.

Read together, the studies suggest that "generated interfaces must be consistent" is only half right. Keep the familiar parts of the product still and give generated content a clearly designated place; once that is true, whether the generated part is right matters more than whether it is predictable, though in the 2008 study predictability still raised satisfaction and accuracy could not fully make up for its loss. These were toolbar studies in office software with small samples, so applying them to generated interfaces is our inference, but the pattern matches newer guidance. Microsoft's Guidelines for Human-AI Interaction include "Limit disruptive changes when updating and adapting the AI system's behaviors."

Do not expect the model to supply that stability. Apple's Human Interface Guidelines for generative AI point out that small changes to inputs, or even the same input given more than once, "often produce very different outcomes". Consistency has to be engineered around the model.

The design system becomes the contract the model generates against

At levels 2 and 3 the design system gains a second reader. A2UI defines a catalogue as a JSON Schema file listing the components, functions and theme an agent may use. Every response is validated against it, failures are reported back to the agent, and the documentation expects that "most production applications will define their own catalog to reflect their specific design system."

The idea is older than large language models. Microsoft's Adaptive Cards, introduced in 2017, set the division that still works: card authors own the content, the host app owns the look and feel, and the format is purely declarative, with no code allowed. OpenAI's UI guidelines for apps in ChatGPT apply the same principle from the host's side: inherit the system font, keep brand colour to accents and primary buttons, allow at most two actions on an inline card.

For a team with a design system, this changes what "complete" means:

• Each component needs a purpose a model can read. A human designer knows when to use a callout instead of a banner. A model knows only what the catalogue says.
• Properties should be closed where they can be. A choice from a fixed list can be validated; an open text field invites the model to invent a variant.
• Composition rules have to be written down. "One primary action per view" lives in designers' heads until a model breaks it.
• There must be a fallback. A2UI's own behaviour is instructive: if no catalogue matches, the agent sends no UI, and if validation fails, the agent can regenerate or fall back to text.

In our judgement, gaps that people paper over with judgement become visible defects once a model composes from the system. If you are unsure how ready yours is, the method in how to audit a design system is a reasonable place to begin.

There is also a security reason to prefer levels 2 and 3. A2UI describes itself as a declarative data format, not executable code. At level 4, or when an interface arrives from a third party, the product runs code nobody on the team reviewed. The MCP Apps extension, which lets tools return interactive interfaces inside hosts such as Claude and ChatGPT, says so plainly: "Running UI from MCP servers means running code you didn't write within your MCP host." Its answer is sandboxed frames, pre-declared templates the host can review, loggable messages, and hosts that can require the user's approval for actions the interface starts. The design question becomes what generated code is allowed to touch.

Accessibility moves from the screen to the catalogue

At levels 1 to 3, roles, names and contrast are built into each component once, and generation cannot remove them; at level 3 the model's arrangement still sets reading and focus order across components, so that order needs checking too. What the model still controls is the words: button labels, link text, alternative text. An automated checker can confirm that an image has alternative text; it cannot tell whether "chart" helps anyone. Those words need review, by people or by a checking step designed for it.

At level 4, every generated screen is new code. A 2025 comparison by Hyunjae Suh and colleagues found that model-written web code was often more accessible than human-written code on colour contrast and alternative text, but struggled with ARIA attributes. Better prompting helped only a little; a loop that fed checker results back to the model did substantially better.

Two WCAG 2.2 criteria deserve a named owner in any generated interface:

• **3.2.4 Consistent Identification** (Level AA): components with the same function are identified consistently. Screen reader users navigate by recognising familiar controls. If the model calls the same action "Save" in one view and "Keep" in the next, the product fails them, so name actions in the catalogue rather than letting the model name them.
• **4.1.3 Status Messages** (Level AA): when the interface reports progress, a result or an error, for example while content is still generating, assistive technology has to be told without focus being moved. In a generated interface, parts of the screen change as content arrives, so this becomes a default requirement rather than an edge case.

Testing a screen that has no single correct version

Snapshot tests assume there is one correct image. When the layout is generated, a different but valid result fails the test, and a test that fails on valid output stops telling the team anything. Testing has to move to the layers that are stable:

1. The contract. Does every output validate against the catalogue? This is mechanical and cheap, and A2UI builds it in.
2. The rendered result. Assert on accessible roles and names, not on position in the page structure.
3. The outcome. Run the same request many times and check that a person could still complete the task, whichever valid layout appeared. Agent researchers measure this as pass^k, the chance a system succeeds on every one of k tries. A screen that works on the first try but not the fifth is not working.

Keep a fixed set of representative requests as the regression suite and run it whenever the model changes. Google reports that generative UI quality "strongly depends" on the underlying model, and Apple advises planning for retesting when moving to a newer base model. Treat waiting time as something to test too: when generation is slow, Apple suggests specific progress messages, such as "Summarizing key themes from your notes", over a generic "Processing…".

What the designer specifies now

Screens do not disappear. They become examples of good output and test fixtures rather than the specification. The specification is:

• The level for each surface: which parts of the product are fixed and which are generated, decided screen by screen.
• The invariants: navigation, the controls people rely on and the names of actions. These are never generated.
• The catalogue: components with readable purposes, closed properties and declared states.
• Composition rules: limits, ordering and what may appear together.
• Fallbacks: what appears when output fails validation, times out or finds nothing suitable.
• Waiting and streaming states, including how updates are announced to assistive technology.
• Correction: edit, undo, retry and dismiss near generated content, as Apple's guidelines recommend.
• Disclosure: generated content marked as generated; Apple's guidelines also ask apps to "clearly identify when and where you use AI".
• The evaluation set: representative requests, pass thresholds and accessibility checks, run on every model change.

Where to start in a product that already exists

Our recommendation for an established product is to start at levels 1 and 2: find the places where users would benefit from generated content inside a designed frame, mark what must never move, and check whether the design system could be read by a model as well as a person. Level 3 earns its place where the combinations people need are too many to design one by one. Level 4 is still best kept for answers people read once.

This article is about the interface a model generates. Interfaces where AI acts on a user's behalf are covered in agentic UX design principles, and where a person should check AI output in human-in-the-loop UX patterns.

The Tcules AI Product UX work covers AI interaction and workflow design, evaluation scenarios and acceptance, and integration into a product's existing roles, state and design system: the decisions above about what a model may generate and how the result is checked.