What can a prototype made of drawings never answer?

For years, I reviewed pictures of interfaces and called it design review. It's a bit like judging a chair by a photograph of a chair.

You could say a lot about proportion, about whether it suits the room and whether the color works. But you couldn't say whether it holds your weight.

We do this all the time in design. In fact, we've built a whole craft around the photograph.

A drawing shows layout, not behavior

A drawing tells us a lot, and I want to be fair about that. It shows layout, hierarchy, rhythm, tone and whether the eye lands where we meant it to. A static design answers all of that cheaply and fast, which is why the discipline organized itself around drawings in the first place.

What a drawing can't answer is the set of questions that decide whether a person can use the result:

• What does the keyboard do, and in what order?
• What does a screen reader say? I mean what it says, and not what we hope it says.
• What happens at 375 pixels, on a phone, on a weak signal?
• Does the spacing we chose exist in the system at all, or did we invent it?

I wouldn't call those aesthetic questions, or edge cases. For a great many people, they are the experience, and none of them is visible in a picture.

WCAG has numbers for some of this, if that helps in a review.

2.4.3 Focus Order is about focus order. 1.4.10 Reflow is about reflow: how a page rearranges itself on a narrow screen. And 4.1.2 Name, Role, Value is about name, role and value.

We can't judge any of them from a picture. So for as long as our main artifact is a picture, we can't see the things we're most responsible for.

Deferred questions come back as findings

The questions don't disappear, though. Someone else answers them later, as a finding: an audit result, a support ticket, or a sprint of fixes with a deadline attached.

By then the answer is expensive, so it gets negotiated. And the layout almost never gets negotiated away. Funny how that works. But the focus order, the announcement and the behavior at a narrow width do.

Now think about the person who meets the result. They're filling in a form on a phone between shifts. Or navigating with a keyboard. Or listening rather than looking.

They have no way to see it as a side effect of a process. To them, it's a product that doesn't work for them, shipped by people who never checked.

Nobody in that chain meant it, and from the inside, it looks like process, not exclusion. Our tools never made the question cheap enough to ask early.

A prototype can be made of the real thing

So I built CCDS (opens in a new tab) to test what changes. It's a prototyping sandbox for product managers and designers, built on the real component package and the real design tokens.

It doesn't imitate the design system. It uses the same material the product is made of, in a Vite and React app that runs on a laptop.

The usual alternative is a prototyping tool that approximates the system, and that approximation is the problem. Anything built in it has to be rebuilt to become real, and every rebuild is a chance to drop the parts that were never visible in the drawing, without anyone noticing.

When the prototype is made of the shipped components, the accessibility questions stop being a separate activity.

Tab through it, and you get the real focus order. A screen reader gives the real announcement, and narrowing the window shows the real behavior. So the person asking the questions can answer them the same day.

That's my whole argument, and it's a small one. I'm not saying designers should become engineers. I'm saying the people making the decisions should be able to run the thing they're deciding about.

None of this needs a sandbox

Most teams don't have one, and we don't need to build one to make the shift.

The first step is getting the real component library running locally. Storybook, a scratch app or a branch will do. Anything works, if it lets us press Tab on the actual component and not on a rectangle standing in for it.

Then ask the four questions in design review: keyboard, screen reader, 375 pixels, and whether this spacing exists. Asked early, all four cost minutes.

I'd also prototype the states nobody draws: empty, loading, error and too-long-name. Accessibility failures gather there, because that's where drawings stop.

An invented spacing value is worth treating as a bug. If it isn't in the system, someone will hand-roll it, and hand-rolled things don't inherit the system's accessibility work.

And sign-off should mean "I ran it". "I reviewed the file" shouldn't be enough.

None of that needs permission. It needs the thing to be runnable, which is a tooling problem our field has been strangely willing to live with.

A drawing is a comfortable place for a default to go unexamined, because it looks finished. So run the thing before the next review. Press Tab, and listen to it once.

Whatever you find is cheap to change today. Next quarter, it would be a finding in someone's report.