What should a team hand each other instead of a picture?

Nobody stands in a doorway on paper and says it's wide enough. An architect hands over drawings, and everyone on site understands that the drawing isn't the building.

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. We passed it around as though it were the interface, and built our whole review culture on top of it.

To be fair to the picture, it carries layout, hierarchy, rhythm and tone very well.

It says nothing about keyboard order, or what a screen reader announces, or what happens at 375 pixels on a bad connection. It doesn't even say whether its spacing exists in the system.

So those four questions get put off, and they come back later as a finding attached to a deadline. By then the cheap things to renegotiate are the focus order, the accessible name and the behavior at a narrow width.

The person who meets the result isn't in any of these conversations. They're filling in a form on a phone, or navigating with a keyboard, or listening instead of looking.

Intent doesn't survive a picture either. A designer knows that this is a button and not a link, that this heading is level two, and that this control needs a name. The image says none of it, so it travels by conversation or not at all.

I want to look at Claude Design (opens in a new tab) here. I'm not recommending a product (this isn't that kind of post), only using it as an example of a shift that's been coming for a while.

What matters to me is that the design system goes in first, imported from a repository or from the team's design files.

What comes out is built from those colors, that type and those components, not from an approximation of them. It's also shared across an organization, commented on inline, and adjusted live instead of being described in a ticket.

So the object a team passes around is much closer to the thing itself, and the person with the objection can change it in front of the person who made it.

I think that's a real improvement, but all it closes is the translation gap. It doesn't answer any of the four questions. It just makes them cheap to ask.

An artifact generated from the design system inherits the design system. Every property of it, good or bad, now gets reproduced at speed, 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 system is silent on those things, the silence gets multiplied too, faster than any review process was built to absorb.

I've been making the same argument since 2021, that exclusion is the default outcome of unexamined defaults, and this is where it leads.

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's in them, at scale and in front of an organization.

For twenty years, the argument for accessibility in design systems has been made on principle, and principle has lost a great many of those arguments to deadlines. "Whatever is in the system is about to be everywhere" is an easier one to make.

Almost nothing about how generated artifacts get reviewed is settled yet, and most of it is being decided by people who haven't been asked who gets excluded.

So the system is where we intervene. I'd put focus styles and accessible names, roles and states in the components, since nothing inherits a rule that only lives in a document.

I'd add what nobody draws or writes down: the empty, error and loading states, a name three times too long, and rules like the accent marks selection and nothing else.

But I'd open the tokens and grade the palette first, and check the result in as a number, so a change has to argue with a number and not with someone's memory. Whatever turns up is cheaper to change now than in everything built after it.