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

For most of our field's 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 we built our whole review culture on top of it.

Architects never made that mistake. 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.

To be fair to the picture, it carries a lot. Layout, hierarchy, rhythm and tone, it carries 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 with a deadline attached.

By then, the only things still cheap to change 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, because this isn't that kind of post. It's 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 shared across an organization, commented on inline and adjusted live, instead of described in a ticket.

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

That's a real improvement, but all it closes is the translation gap. It doesn't answer any of the four questions. What it does is make them cheap to ask.

Here's the catch. An artifact generated from the design system inherits the design system. Every property of it, good or bad, now gets copied at speed, by people who never had to think about it.

If the system encodes contrast that clears 1.4.3 Contrast (Minimum), every generated artifact clears it. If the system is silent on those things, the silence gets copied too. Faster than any review process was built to absorb.

I've been making the same argument since 2021: exclusion is the default outcome of unexamined defaults. 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 case 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 case to make.

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

So the system is where we step in. I'd put focus styles, accessible names, roles and states in the components, because 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 first, I'd open the tokens and grade the palette. Then I'd check the result in as a number, so a change has to argue with a number, not with someone's memory.

Whatever turns up is cheaper to change now than in everything built after it.