-
AuthorCélio Pires
-
Published2026
-
CategoryDesign Systems
Design systems for humans and agents
Your design system now has a second audience. Agents read your tokens, use your components and follow your rules. If they can't understand it, they'll invent their own.
A new kind of user
For years I designed systems for two audiences: designers and engineers. Figma on one side, code on the other, documentation in between.
Now there's a third. When an agent builds a screen, it doesn't open Figma or read your docs site. It reads what's in front of it: the token file, the component props, the written rules. Whatever isn't written down doesn't exist for it.
The first time I watched an agent build a "card" from scratch next to the card component we already had, I understood. The system wasn't wrong. It just wasn't readable.
One source of truth
OnEnsinova the tokens live in a machine-readable design spec: colour, type, spacing, radius. People and agents read from the same file.
That sounds obvious, but most teams have three versions of their tokens: the Figma one, the code one and the one in someone's head. Humans can live with a bit of drift. They ask a colleague. Agents can't. They pick whichever value they find first.
If you want consistent output, there can only be one source.
Real components, not lookalikes
I mirrored the component library into Claude's design environment with its real TypeScript contracts.
That one decision changed the quality of everything. AI-generated designs stopped producing things that looked like our buttons. They used our buttons, with the props and variants that actually ship.
A mockup built from real components is a step toward production. A mockup built from lookalikes is a translation job someone has to do later.
Write the rules, not just the parts
Components tell an agent what exists. Rules tell it when to use what.
A good designer knows that a dialog on desktop should become a drawer on mobile. They know both themes need to pass AA contrast. They know the tone of voice is formal Portuguese, with inclusive titles, and the same in three languages. None of that lives in a component. It lives in experience.
So I wrote it down:
• responsive behaviour as rules, not case-by-case decisions
• contrast requirements for light and dark themes
• copy rules for every locale, treated as part of the system
• the reasoning behind each decision, so it can be applied to cases I didn't predict
The surprise: writing for agents made the system better for people too. New contributors don't have to guess either.
Governance that runs itself
Design system governance used to mean reviews. Someone checks the work, spots the hardcoded colour, leaves a comment.
Now I have a UI-governance agent that enforces the design system on every change, and a shadcn auditor that checks how the component foundations are used. Same standards, every time, without anyone having to remember.
That doesn't replace design review. It frees review up for the questions that need a human: is this the right flow, does this feel calm, is this what the user actually needs.
Adoption, again
I've written before aboutdriving adoption andhandling resistance. With people, adoption is about trust. You listen, you include them, they start defending the system.
With agents, adoption is about clarity. They don't resist. They just quietly go around you when the system is ambiguous.
The fix is the same in both cases: make the right thing the easiest thing to do.
What I learned
A design system was always a way of writing down judgment so other people didn't have to rediscover it. Agents just raised the bar for how clearly you write it down.
If an agent can read your system and build something you'd approve, a new designer probably can too. If it can't, the gaps were always there. You just had people quietly filling them in.
Design for the reader who can't ask questions. Everyone else benefits.
Latest Articles
Insights and learnings from building design systems across different products and teams.View all articles
