Generative UI and Interactive Motion: Keeping Generated Interfaces Usable
How motion works when an AI model assembles the interface: approved components, state logic, accessibility and a fixed frame around generated areas.
Core Takeaway
Generative UI lets a model assemble part of the interface for each request. Motion should come from approved, pre-built components rather than from generated code, so states, timing and accessibility are tested once. Keep a fixed frame around the generated area, pass semantic tokens, and validate the result before it renders.
What changes when the model builds the screen
In a fixed interface, designers decide every screen in advance. In a generative interface, the model chooses which components to show and what data to put in them. Google describes generative UI as a model producing not only content but a visual, interactive experience for a prompt. That shifts the design problem from drawing screens to defining the components, rules and constraints the model can use. Motion is part of those constraints.
Let the model compose, not invent
The safest pattern is an approved catalog. The model picks a card, table, chart, form or comparison component and fills it with data. It does not write raw CSS or invent a new animation. A2UI, an open protocol from Google, works this way: an agent sends a declarative component description and the client renders it with its own widgets. Vercel's AI SDK describes a simpler version where a tool call returns a component. In both cases, the interactive behaviour is owned by the client, not generated on the fly.
Motion belongs to the component
A generated interface still needs enter, loading, success and error states. Those should be designed once inside the component and reused. The model can choose to show a progress component, but it should not decide the spring stiffness or invent a new spinner. This keeps timing consistent across prompts and prevents a generated screen from feeling like a different product each time.
- Enter and exit motion comes from the component, not the prompt
- Loading and error states are part of the component contract
- Reduced motion is handled by the runtime, not by the model
- The model chooses content and composition, not physics
Keep a fixed frame
Navigation, the input, settings, undo and stop controls should stay outside the generated area. People need a stable place to return to. If the model can remove or restyle the frame, the interface becomes disorienting. Mark generated regions clearly and offer a plain, predictable view for anyone who wants it.
Validate before you render
Run checks on the generated output before it reaches the screen: known components only, required fields present, contrast, heading order, labels, focus order, touch target size and reduced-motion support. If a check fails, fall back to a simple list or text answer. A broken generated layout is worse than a plain one.
Where the motion file helps
If the generated UI uses interactive components, those components need a runtime the client controls. The component should own its states, springs and inputs, and the app should choose which one to render without letting the model rewrite its motion. That can be a well-governed code component library or a file-based runtime. The point is a trusted catalog, not a particular vendor.
Key Principles to Remember
- Generative UI shifts design work from screens to approved components and rules
- Let the model compose vetted components instead of writing raw UI
- Keep motion inside the component so timing stays consistent
- Leave navigation, input, undo and stop outside the generated area
- Validate accessibility and fall back to a plain layout when checks fail
Frequently Asked Questions
Sources
- Generative UI research — Google Research
- A2UI — a2ui.org
- Generative user interfaces — Vercel AI SDK