What is a Design System in the Age of AI?

AI gives designers and developers more ways to produce and change interfaces. For me, that makes the agreement behind a design system more important. What standards should we apply, and who can make changes?

What a design system actually is

The most useful design systems marry design and development. When I’ve established design systems myself, I’ve always started by talking with the developers. I want to understand what they need from design, what constraints they’re working within, and how we can work together. Those conversations help us decide what we’re agreeing to and who’s responsible for what.

This is how I think about a design system: a shared contract between design and engineering. It sets standards for how a product looks, behaves, and is built, and how those standards are maintained and updated.

Design owns

• Visual rules
• Patterns
• States and behavior
• Interaction intent

Both own

• Accessibility
• Review
• Changes
• Communication

Development owns

• Code
• Architecture
• Security
• Implementation

Agree. Document. Share.

Making that agreement work means deciding how much to invest, who is responsible for which decisions, and how changes are shared with the people building the product.

Components, tokens, code, and documentation give that agreement a usable form. They help people apply decisions without reopening the same conversation every time they build something. They also need to reflect what the team has actually agreed to.

If we agree that a component uses 8px of spacing and an implementation uses 6px, that difference needs to be resolved. Shipping the 6px version doesn’t automatically make it the new standard. We might decide to change the specification, or we might correct the implementation. Either way, the decision should be deliberate.

Design and engineering are the primary owners of that agreement. Other participants include business analysts, who shape what the system needs to support the company’s goals, and product managers, who help guide priorities and tradeoffs. The system needs room for that input, but the people who build and use it every day to enhance their work remain the key individuals responsible for the agreement.

What the company is willing to invest

Establishing that agreement takes time, and the company has to be willing to invest.

At one company, I pitched a design system knowing it would require upfront work and take time away from some of my less immediately needed tasks. Most of my stakeholders had never heard of a design system. I explained what it did and why I expected it to save us time and money. They were skeptical and wanted to see real value.

A useful way to demonstrate that value is to show how a library of approved parts helps us turn wireframes into high-fidelity designs. We can assemble designs using decisions we’ve already made, then spend our time on what the particular experience needs. That gives stakeholders something concrete to assess against the upfront investment.

Who owns which decisions

In practice, the division of responsibility has usually been more intuitive than it sounds on paper. On teams I’ve worked with, developers generally know when a menu design needs a designer’s input. Designers know when the code stack or the security of an input needs engineering’s judgment. Accessibility brings both sides together through work like designing focus states and implementing keyboard navigation.

Keeping people informed

Knowing who owns a decision still leaves the question of how everyone learns about it.

I once changed an icon within my design responsibilities. After it went live, a developer came to me because they thought the change was unintended. They hadn’t been notified, and it made them wonder what else had changed, whether something was missing, and why.

I took that concern seriously. We began previewing changes before pushing them, which developed into a weekly show and tell. We shared what was changing and our reasoning. We also used that time to seek approval where it was needed and ask for input where we wanted it.

We didn’t need engineering’s explicit approval for every decision our team owned.

Making that part of our routine strengthened the process.

What AI changes

AI makes it easier to work across the boundaries between design and engineering. A designer can use it to modify code, and a developer can use it to produce an interface.¹ That makes the agreement about responsibilities relevant to more of the work we do.

We have all seen agents make changes beyond what we asked for.

In one dashboard I was working on, each card had a control bar that let you customize what it displayed. I asked an AI agent to change something in that control bar and show me a preview. It made the requested change correctly. It also changed the unrelated dropdown menu attached to the profile icon.

When I asked why, it gave me a familiar response: “You’re right, that component is completely unrelated, and I shouldn’t have touched that.”

Clearer instructions might have prevented that extra change. That’s part of the work: deciding what the agent needs to know, making the relevant standards available, and checking that the result stays within the task. A design system gives us a shared agreement. We still have to make that agreement usable by the agent.

An agent needs to understand which parts of the interface it can change for the task, which standards it must preserve, and where it needs further direction. Approved components are only part of that.

The review and coordination we already need apply here too. AI gives us another way to produce work within the system. We still need to decide whether that work follows the agreement and how any proposed changes should be introduced.

What the system communicates

The conversations driving a design system still matter when AI is doing some of the work. We need to be clear about what we’ve agreed to and who is responsible, then keep people informed as it changes.

The system needs to communicate which standards apply, where variation is allowed, and who can decide to change them. People and agents need access to the relevant guidance while they work. That agreement can also make engineering’s expectations explicit, so AI-generated work can be reviewed and refined against the standards the team already uses.

A system used primarily by agents may take a different form. It still needs to carry the decisions and responsibilities we’ve agreed on.

In my next post, I’ll look at how to make a design system usable by both people and AI, including how to share maintained guidance, make the relevant rules available, and check that the work follows the agreement.

References

1. Yarden Katz, “Building frontend UIs with Codex and Figma,” OpenAI Developers, February 26, 2026. https://developers.openai.com/blog/building-frontend-uis-with-codex-and-figma (opens in a new tab)