How to Design Interfaces for GenUI: A Best Practices Guide

Designing for generative UI is not like designing a website or an app. You are no longer drawing every screen. You are designing the parts an AI model will assemble, the rules it follows, and how the interface behaves while it is being generated, when it is wrong and when the user wants something else. Get that system right and generated screens feel like a natural part of your product. Get it wrong and they feel random, off-brand and hard to trust.

This guide sets out the best practices we follow when designing interfaces for GenUI, written for the product, marketing and technology leaders who commission and approve this work. New to the topic? Start with what GenUI is and how it works.

The short version

• Your design system is the AI’s vocabulary. Make it complete, consistent and documented before anything else.
• Prefer controlled or declarative generation for customer-facing products: the AI combines approved components, it doesn’t invent new ones.
• Keep a fixed frame around the generated content so the product still feels like one product.
• Design every state, especially streaming, partial, error and empty states.
• Keep users in control: everything editable, reversible and confirmed before it matters.
• Show sources, test with evaluation sets, and measure task completion, not engagement.

1. Start from the job, not the technology

Define the user’s job and the decision at the end of it before deciding what should be generated. “Help a distributor find a compatible valve and request a quote” leads to a clear component list: a requirements summary, a product comparison, a specification table and an RFQ form. “Add GenUI to the website” leads nowhere. Our guide to GenUI use cases by industry has examples of well-defined jobs.

2. Treat the design system as the AI’s vocabulary

The model can only compose interfaces as good as the components it can choose from. That means:

• Purpose-built components for the content your users need: comparison tables, metric cards, timelines, maps, step forms, product cards, source citations.
• Clear names and descriptions for each component, written for the model as much as for developers: what it is for, when to use it, what data it needs and what it must never be used for.
• Strict data contracts. Each component accepts a defined schema. If the data doesn’t fit, it doesn’t render.
• Design tokens for colour, type and spacing, so generated combinations still look intentional.

Most of the effort in a good GenUI project goes here. It is also why a mature design system is the best preparation for generative UI.

3. Choose the right level of freedom

Match how much the model can invent to the risk of getting it wrong:

• Controlled: the AI picks a pre-designed component and fills it. Use it for transactions, regulated content and anything customer-facing at launch.
• Declarative: the AI describes a layout using your components, through a format like Google’s A2UI, and your app renders it. Use it once the component library is mature and you want more flexibility across web and mobile.
• Open-ended: the AI writes the interface code, in a sandbox. Keep it for internal tools, exploration and prototypes.

Many products mix them: open-ended for an analyst’s scratchpad, controlled for anything that moves money or makes a commitment.

4. Keep a stable frame around generated content

Users need landmarks. Keep navigation, branding, account controls, the input area and primary actions fixed and predictable, and let generation happen inside a clearly defined region. When everything moves, nothing feels reliable. A consistent frame is also what makes generated screens feel like your brand rather than the model’s.

5. Constrain layout with a grid and rules

Give the model a small number of layout patterns (single card, list, comparison, dashboard, step flow) on your grid, rather than free placement. Define rules such as “no more than four metric cards in a row”, “comparisons have a maximum of four columns”, and “every chart has a title and a takeaway sentence”. Rules keep generated screens readable and make them easier to test.

6. Design for streaming and every in-between state

Generated interfaces arrive over seconds, not milliseconds. Design for that:

• Acknowledge instantly. Show that the request was understood, ideally with what the system is doing (“Finding valves rated for 40 bar”).
• Stream structure first. Render the layout skeleton early and fill it as data arrives, so the screen doesn’t jump.
• Reserve space for components that are coming, to avoid layout shift.
• Design partial, error and empty states for every component: what a comparison shows when one product has missing data, what happens when nothing matches, how a failed tool call is explained.

7. Keep users in control

• Everything generated is editable. Users can change a filter, swap a product, adjust a value, without starting over.
• Every change is reversible. Provide undo and a way back to the previous view.
• Confirm before consequences. Orders, payments, bookings, messages and data changes always show a clear summary and a confirm step, designed as a fixed component.
• Offer a way out. A link to the standard page, the full catalogue or a human is always available.

8. Make sources and confidence visible

Trust is the biggest barrier to adoption. Show where numbers and claims come from, link to source documents, timestamp live data, and label estimates as estimates. Where the system is unsure, say so and offer alternatives rather than presenting a guess as fact. In regulated sectors, also log what was shown to whom.

9. Build accessibility into the components

You can’t review every generated screen for accessibility, so make every component accessible by default: semantic structure, keyboard support, focus management when new content streams in, sufficient contrast in every token combination, text alternatives for charts, and announcements for screen readers when the interface updates. Then test generated combinations, not just components in isolation.

10. Always have a text and static fallback

When generation fails, is slow or isn’t appropriate, fall back gracefully to a plain answer, a standard page or a pre-designed screen. A product that only works when the model performs perfectly isn’t ready for customers.

11. Test with evaluation sets, not just usability sessions

A traditional interface is tested screen by screen. A generative one has to be tested across the range of things users will ask. Build a set of real, representative requests (including awkward and adversarial ones), run them on every change to the prompts, components or model, and review the generated interfaces against clear criteria: correct component choice, correct data, readable layout, accessible, on-brand. Combine this with usability testing with real users on the highest-value journeys.

12. Measure outcomes, then iterate

Track whether people get what they came for: task completion, time to answer, how often users edit or undo generated views, fallback rate, error rate, and the business action at the end (quotes, bookings, orders). Watch which components are chosen most and least, and where users drop off. Those signals tell you which components to improve and where to give the AI more or less freedom.

A GenUI design checklist

1. User job and end decision defined
2. Component library covers the job, with names, descriptions and data schemas
3. Level of freedom chosen per journey (controlled, declarative or open-ended)
4. Fixed frame and generation region defined
5. Layout patterns and composition rules documented
6. Streaming, partial, error and empty states designed for every component
7. Edit, undo, confirm and escape routes in place
8. Sources, timestamps and estimate labels shown
9. Components accessible by default; generated combinations tested
10. Text and static fallbacks working
11. Evaluation set built and run on every change
12. Outcome metrics instrumented

How we run a GenUI design project

At Supercode, a typical engagement moves through discovery (jobs, data and risks), the component system and rules, prototypes tested with real users, the production front end, and measurement after launch. We work alongside your engineering and AI teams, or deliver the front end ourselves. Learn more about our GenUI design service, or talk to our team about your first use case.

Frequently asked questions

How is designing for GenUI different from regular UI design?

In regular UI design you design every screen. In GenUI you design the components, rules, states and guardrails, and the AI assembles the screen at runtime. The deliverable is a system, not a set of pages.

Do we need a design system before starting GenUI?

You need a set of well-defined components for the journey you start with. A full design system helps, but many teams build the GenUI component set first and grow it into a wider system.

How do you keep generated interfaces on-brand?

By limiting the model to your own components and design tokens, keeping a fixed frame around generated content, and enforcing composition rules. Open-ended generation is where brand drift happens, so keep it for internal tools.

How do you test a generative interface?

With an evaluation set of representative user requests that is run on every change, reviewed against clear criteria, plus usability testing with real users on the most important journeys.

What tools do designers use for GenUI?

Figma for components and rules, documented in a way developers and models can both use; prototyping with frameworks such as the Vercel AI SDK or CopilotKit; and A2UI or MCP Apps where interfaces must render across platforms or inside AI assistants.