What should a team hand each other instead of a picture?
For as long as I have worked in this field the unit of design communication has been an image, and I am no longer sure it can carry what we need it to.
An architect hands over drawings, and everyone on site understands that the drawing is not the building. Nobody stands in a doorway on paper and pronounces it wide enough.
Our field never quite agreed on that. For most of its history the thing a design team hands each other has been a picture of an interface, passed around as though it were the interface, and we built our whole review culture on top of that substitution.
What does a picture fail to carry?
Everything that is not visible.
A static design communicates layout, hierarchy, rhythm and tone very well. It carries nothing about keyboard order, nothing about what a screen reader announces, nothing about what happens at 375 pixels on a bad connection, and nothing about whether the spacing in it exists in the system at all.
So those questions get deferred, and deferral has a shape. They come back later, as a finding, attached to a deadline, at which point the cheapest thing to renegotiate is never the layout. It is the focus order, the accessible name, the behavior at a narrow width.
The person who meets the result is not in any of these conversations. They are filling in a form on a phone, or navigating with a keyboard, or listening rather than looking.
There is a second loss, quieter than the first. Intent does not survive a picture either. This is a button and not a link. This heading is level two. This control needs a name. A designer knows all of it and the image says none of it, so it travels by conversation, or it does not travel.
What is actually changing?
I want to look at Claude Design (opens in a new tab) here, not as a product recommendation but as an example of a shift that has been coming for a while.
The part that matters is not that a model can produce a layout. It is that the design system goes in first. A team imports its system from a repository or its design files, and what comes out afterwards is built from those colors, that type, those components rather than an approximation of them. Artifacts have also become collaborative: shared across an organization, commented on inline, adjusted live rather than described in a ticket.
Put those together and the object a team passes around stops being a picture of the thing and becomes something much closer to the thing. It can be opened. It can be argued with. It can be changed by the person who has the objection, in front of the person who made it.
That is a real improvement in how design gets communicated, and I want to be careful about how far I push the claim. It closes the translation gap. It does not by itself answer a single one of the four questions above.
What does generation multiply?
Here is what I would have our field pay attention to.
When the artifact is generated from the design system, it inherits the design system. Every property of that system, good and bad, is now reproduced at speed, across an organization, by people who never had to think about it.
If the system encodes contrast that clears 1.4.3, every generated artifact clears it. If the tokens carry focus styles, every artifact has them. If the components name their controls properly, every artifact does.
And if the system is silent on those things, then silence is what gets multiplied. Not once, not in one designer's file, but in everything anyone generates from it, faster than any review process was built to absorb.
I have been making the same argument since 2021, and this is where it arrives. Exclusion is the default outcome of unexamined defaults. A system-aware generator is a machine for taking whatever is in a design system and putting it everywhere.
We both believe design teams do not intentionally exclude people. But a team that has never audited its own tokens is about to find out what is in them, at scale, in front of an organization.
What goes into the system first?
If generation inherits the system, then the system is the intervention. Roughly in order of how much they repay:
- Grade the palette before anyone generates from it. Every foreground and background pair, against its target, checked in as a number a change has to argue with rather than a memory.
- Put focus styles in the components, not in a guideline. A rule in a document is not inherited by anything.
- Give every component its accessible name, role and state. These are the things a picture could never carry, and a real component carries them for free.
- Write down the judgment that lives in people's heads. The accent marks selection and nothing else. A generator cannot infer a rule nobody wrote.
- Include the states nobody draws. Empty, error, loading, a name three times too long. If they are absent from the system they will be absent from everything built out of it.
- Keep asking the four questions of the generated artifact. Keyboard, screen reader, 375 pixels, does this value exist. A runnable artifact makes them cheap to ask, which is exactly why there is no excuse left for not asking.
The opening this gives us
For twenty years the argument for accessibility in design systems has been made on principle, and principle has lost a great many arguments to deadlines.
The argument is now different, and better. Whatever is in the system is about to be everywhere. That makes auditing it the highest-leverage work available to a design team, and it makes the case in a language organizations already respond to.
The conventions for this are still soft. How generated artifacts get reviewed, what a design system owes a generator, whose job it is to check what came out. Almost none of it is settled, and most of it is being decided by people who have not been asked who gets excluded.
Open your own tokens and grade the palette. Whatever you find is about to be multiplied, and it is cheaper to change now than in everything built after it.