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 great deal about proportion, about whether it suits the room and whether the color works. You couldn't say whether it holds your weight.

We do this constantly in design, and we've built a whole craft around the photograph.

A drawing shows layout, not behavior

A drawing tells us a great deal, and I want to be fair about that. It shows layout, hierarchy, rhythm, tone and whether the eye lands where we intended.

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 large number of 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 is about focus order. 1.4.10 is about reflow, which is how a page rearranges itself on a narrow screen, and 4.1.2 is about name, role and value.

We can't evaluate any of them from a picture. So for as long as our primary 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. Someone else answers them later, as a finding: an audit result, a support ticket or a remediation sprint with a deadline attached.

By then the answer is expensive, so it gets negotiated. 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.

The person who meets the consequence is 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 process artifact. To them it's a product that doesn't work for them, shipped by people who never checked.

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

A prototype can be made of the real thing

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 approximate 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.

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.

If we tab through it, we get the real focus order. A screen reader gives the real announcement, and narrowing the window shows the real behavior. 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 are 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 runnable 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 representing it.

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

I'd also prototype the states nobody draws, which means 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, and that's 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.