Design systems in the age of AI: who owns the decisions?

A design system can look organised inside its library and still be difficult to use in a real product.

A designer cannot find a suitable pattern. An engineer needs clarification about an interaction. A team introduces a variation because the existing component does not quite fit.

Each decision may make sense in isolation. Together, they can leave people unsure about what to reuse, what to change and who to ask.

Figma's article, How to lighten design system upkeep with the Figma agent, prompted me to think about how teams could respond when some of that upkeep becomes easier.

My perspective here is based on the article, rather than a hands-on evaluation of the agent.

What the Figma agent changes

According to Figma, the agent can assist with component documentation, naming consistency, token checks and aligning designs with existing library components.

Figma also describes adding guidelines to published libraries so the agent has context about the system's intended use.

For product leaders, I would use this development as a reason to examine the foundations of the system.

Are the rules understandable? Do teams agree on them? Can someone explain why an exception exists?

Those answers would shape how I approached adoption.

Consistency needs context

Imagine a product with three forms.

Customers use one to register. Administrators use another to invite colleagues. Support teams use a third to recover account access.

They share familiar elements: fields, labels, validation and buttons. But the tasks carry different responsibilities.

The customer needs a clear introduction to the service. The administrator needs to understand permissions. The support agent needs to verify that an account change is appropriate.

A review might identify inconsistent spacing across all three forms. It might also reveal different confirmation steps.

I would investigate those findings differently.

Spacing differences may have no purpose. An additional confirmation may protect someone from a consequential mistake.

Before standardising a pattern, I would ask:

• What is the person trying to accomplish?
• Why does this difference exist?
• Who would be affected if it disappeared?
• Should the solution become a shared pattern?

Consistency becomes useful when it preserves the differences that matter.

Make ownership explicit

A library needs a clear way to resolve questions.

When two teams propose different solutions, who decides? When a component no longer fits a workflow, how does someone request a change?

I would establish three responsibilities.

Pattern ownership

Someone maintains the intended purpose of a shared pattern and helps resolve competing requirements.

Exception ownership

Someone records why a variation is necessary and when it should be reconsidered.

Release ownership

Someone coordinates the review of design changes and their implementation before wider adoption.

These responsibilities can sit with the same person in a small team. In a larger organisation, they may be distributed.

The important part is that people know how to move a decision forward.

What to automate and what to review

This is how I would divide the work when evaluating an assisted maintenance process.

This is a proposed division of responsibilities, not a report of tested results.

I would expect to refine it as the team learns where assistance is reliable and where more context is needed.

Accessibility needs attention

I would include accessibility in the acceptance criteria from the beginning.

Using approved components does not answer every question about the complete experience. The way components are combined, labelled and sequenced also deserves review.

For the three-form example, I would check:

• Can people understand what information is required?
• Are instructions and errors clear?
• Can someone recover without unnecessarily repeating work?
• Does keyboard focus move in a useful order?
• Does the implemented flow work with relevant assistive technology?

These checks belong in the workflow alongside visual and behavioural review.

A consistent interface still needs to be evaluated as an experience people must use.

Start with one workflow

I would begin with a contained area of the product that the team understands well.

An onboarding journey or a frequently used settings flow could be a useful candidate.

1. Record the current situation. Document known inconsistencies, review effort and recurring handoff questions.
2. Examine the recommendations. Record what the team accepts, modifies or rejects. Include the reason.
3. Review with engineering. Check that proposed design changes reflect the intended implementation and behaviour.
4. Update the guidance. If a recommendation exposes an unclear rule, clarify the rule before extending the process.
5. Decide whether to expand. Use the results to choose the next workflow and the level of oversight it needs.

A small pilot would make the trade-offs easier to understand before changing how the wider team works.

How to know it's working

I would evaluate the complete process, including the work required to correct or clarify the output.

Useful measures would include:

• Review effort: time spent checking the workflow.
• Correction effort: time spent fixing unsuitable recommendations.
• Handoff clarity: questions that remain unresolved after review.
• Adoption: whether teams use the agreed patterns.
• Product quality: issues found during implementation and testing.

I would avoid setting a percentage improvement before establishing a baseline.

The pilot should tell us whether the approach is useful, where it needs supervision and what the team should improve next.

Frequently asked questions