Getting Your Design System Ready for AI-Built Screens

Design systems have always been about consistency. When a customer moves from your website to your app, the buttons, forms and messages should look and work the same way, and it should feel like the same brand.

Get the design system right and teams ship faster, because they're not rebuilding the same things, and designers and developers work from one shared set of decisions. The biggest payoff, though, has always been for the people using what you build: one consistent experience, whichever screen they're on.

That's as true for a water utility as it is for a bank, an insurer or a retailer. Since the start of 2026, progress in generative UI has started to change how those screens get made, and to give users a hyper-personalised experience. With generative UI, an AI agent builds the screen a customer needs at the moment they need it. It builds from components (reusable parts of a page, like a button, a form field or a menu) the brand has already approved. It can only do that from a design system the agent can read, and most design systems were built for people to read.

Generative UI builds each screen when a customer needs it

Today, a screen is designed in Figma (the design tool nearly every design team uses), built in code and released. Customers see the same version of that screen, whether it's on your website or in your mobile app. With generative UI, an AI agent (software that can work through a task on its own, as well as answer questions) works out what the customer needs and puts the screen together on the spot.

Generative UI works at three levels, depending on how much freedom the agent is given:

• Choosing a screen. Designers build the screens in advance and the agent picks which one to show. An airline might design its flight card once, and the agent decides when a customer needs to see it.

• Assembling a screen. The agent puts a new screen together from approved parts. A sales manager asks for a dashboard, and the agent builds one from the brand's own charts, tables and filters.

• Building from scratch. The agent creates something new in a safe test space. It's slower and less predictable, and suits one-off tools nobody would design in advance.

When the agent is choosing or assembling, it can only use what the design system gives it. I think assembling is where brands will feel the change first, and it's where the design system matters more than anywhere else.

Open standards let AI agents build screens from your design system

For this to work across different AI tools and different apps, everyone needs to agree on how an agent describes a screen and how an app draws it. Three open standards are being built for that, and they're designed to work together:

• A2UI, from Google. The agent sends a description of the screen, and the brand's own app draws it using only the components the brand allows. It works with React, Angular and Flutter, which are common frameworks for building web and mobile apps.

• MCP Apps, from the community behind MCP (the Model Context Protocol, a common way for AI tools to connect to other software). A brand's app shows up as a working, branded panel inside ChatGPT, Claude or Gemini, in place of a block of text.

• AG-UI, from CopilotKit. It connects an AI agent to whatever front end a brand already has, whether that's a website, a mobile app or Slack.

All three have the agent build from components the brand has approved, which is the part that matters for design teams. Google's team behind A2UI says: "You already have a design system. You already have a front end. You don't need to change that."

It's early: Google's standard was still short of version 1.0 in mid-2026, and Google is open that it isn't easy for developers yet.

Most design systems were built for people to read, and an AI agent needs something different

A typical design system today is a Figma library, a documentation site and a lot of knowledge that lives in designers' heads. That setup works for people, because a designer who isn't sure which component to use can ask a colleague.

An agent can't ask. It works from what's written down and what it can reach, and it fills any gap itself. The result is a screen that looks right and drops the decisions behind it. Those decisions include which fields a form needs and what an error message says. They also include whether the screen works with a screen reader (software that reads the screen aloud for people who are blind or have low vision).

Making a design system readable by AI is still uncommon. Of the ways design system teams said they use AI, delivering their documentation through MCP servers or chatbots came last, at 12% (zeroheight Design Systems Report, 2026).

An AI agent needs four things from a design system to build on-brand, accessible screens

Each of these is work a mature design system already does, written down in a form an agent can use.

1. A catalogue of approved components, in working code. Every component is listed with its name, who owns it, which platforms it's available on and where its code lives. An agent can't reuse what it can't find, and a Figma file on its own doesn't tell it which working component to use.

2. Written rules for each component. When to use it, when not to and how it behaves when something goes wrong or there's nothing to show yet. A designer picks these rules up over months on the job, so an agent needs them written down to reach the same answers.

3. One source for the brand's colours, spacing and type. These values are called design tokens (named values like "primary blue" or "large spacing"). They need to live in one place that design and code both take from. 60% of design system teams still keep their tokens matched to code by hand (zeroheight Design Systems Report, 2026). An agent working from a copy that has drifted builds screens that are slightly off-brand.

4. Design decisions recorded where they can be found. Why a component works the way it does, what was decided along the way and what "finished" means, including for accessibility. Without that record, an agent can reopen a decision designers settled months ago.

Designers still decide what reaches a customer, through tests and review

Designers stay in charge of what the agent produces. They set the rules it follows, and every new or changed component is tested and reviewed by a person before it reaches the shared design system or a customer.

Until the four things above are in place, I'd keep AI to tasks a person checks every time, like drafting documentation or comparing components. I wouldn't let an agent add to the design system itself until then, because a person checking each piece of work is what keeps the screens accessible and recognisably the brand's own.

Four questions test your design system's readiness for generative UI

• Could someone new find every approved component, and where its working code lives, without asking anyone?

• Are the rules for using each component written down, or held in designers' heads?

• Do design and code take the brand's colours, spacing and type from one source?

• Are past design decisions, including accessibility requirements, recorded where they can be found?

Generative UI builds from the design work in your design system

Generative UI will change how screens get made, and the design system is what it builds from. The work designers have already put into components, rules and decisions becomes more valuable once an agent is using it. Getting that work into a form an agent can read is the step to take now, so your customers get the personalised experience generative UI promises, and it still looks and works like your brand.