Design in the material you ship

Date: October 18, 2026

Designers should understand code the way an architect understands stone: what it can do, not how to cut it. AI now does the cutting.

Two versions of the same reservation card. On the left, the design file: a short English title, a round photo, two neat buttons. On the right, the same card in a browser with real data: the photo failed to load, a long French name and title wrap onto extra lines, the main button breaks onto two lines, and a red error says availability could not load. — The same card in the design file and in the browser with real data. Image by the author.

Early in The Fountainhead, Howard Roark is expelled from architecture school for refusing to design in borrowed styles. The Dean calls him in to explain himself, and Roark gives him a rule instead: “What can be done with one substance must never be done with another. No two materials are alike. No two sites on earth are alike. No two buildings have the same purpose. The purpose, the site, the material determine the shape.”

You don’t have to admire Roark to take the point. He is the architect in the book who spends his time on building sites, among the electricians and steelworkers, learning what the material will and won’t do. His classmates learn to draw facades.

Digital designers have a material too. It is code. For most of the last fifteen years, we have designed in pictures of it. The warning is older than that. John Allsopp asked the web to stop imitating print in 2000, Frank Chimero wrote about working with the web’s grain in 2015, and Jeremy Keith gave its materials a chapter of their own in Resilient Web Design.

The drawing is not the building

A design file is a drawing. It shows one state, at one width, in one language, with the data the designer typed in. The product is every other state.

The name is longer than the box. A short English label can double in length once it is translated. The photo fails to load. The list is empty. The request takes four seconds, or fails. Someone tabs through with a keyboard. The phone is 320 pixels wide. None of those is an edge case to the person it happens to, and none of them exists in the file until someone draws it by hand, which in practice means rarely.

Six small renders of the same event card, each labelled. A title three lines long. A French button label. An empty state with a calendar icon. A red error with a retry button. The card squeezed to phone width with its button wrapping. The button wearing a thick keyboard focus ring. — Six states the design file never showed. Image by the author.

When the file is the source of truth, each of those gaps gets decided by whoever writes the code, after the design is called done, and usually without a conversation. The file and the product drift apart, and the file keeps being presented in reviews as if it were the product.

What changed when the code became the source

When I built 131 variations of one button to study hover feedback, I built them in code. The surprise was what happened to the specification. In a design file, a jelly button is an adjective: tactile. In code, it is a handful of numbers. The pointer starts to count 36 pixels from the edge, the material has a stiffness, and it settles back in under a second. An engineer can build a number. Nobody can build an adjective.

An outlined button whose border dents and bulges like jelly as the cursor pushes into each edge, then settles back into a rectangle. — One of 131 button variations, built in code. Image by the author.

I now work the same way on a product team. The prototype in code is what gets reviewed. The design file still exists, because people like to leave comments on a canvas, but it is regenerated from the code after each pass, never the other way round. Its job is to be a mirror.

Two diagrams. Before: the design file is the source of truth, and drift creeps in on the way to a hand-written spec and again on the way to code. After: code is the source of truth and what ships, and the design file is regenerated from it each pass as a mirror for comments. — Before and after: which artifact is the source of truth. Image by the author.

Roark’s rule applies almost word for word. A responsive layout, a loading state and a focus ring belong to the browser. Drawing them in a canvas tool is doing with one substance what belongs to another.

You no longer have to write it

This is where the old version of the argument went wrong. For a decade, “designers should code” meant designers should learn to write HTML, CSS and JavaScript. Many tried, many quit, and they were right to resent it. It asked them to become a second, slower engineer. Brad Frost later drew a more useful line, between the front of the front end, which sits close to design, and the application logic behind it.

That argument is over, because AI writes the code. I describe the screen, its states and its numbers, and the model writes it. I correct it by looking at the result and saying what is wrong, the way an architect corrects a site, not by laying the bricks again myself.

Reading code is going the same way. It still helps, and I read diffs most days. But AI review tools read them too, and they are improving quickly. In one benchmark this year, the best reviewer caught 84 of 122 real bugs taken from production codebases such as Sentry and Grafana. The vendor that won ran the test, and two thirds is not all of them. So the claim is not that the machine has replaced the reviewer. It is that the designer no longer needs to be the reviewer.

Three columns. Write: the bar is almost entirely AI, done by AI from a plain description. Read: the bar is about half AI, done by AI review and then the engineer who owns the code. Understand: the bar is entirely the person, done by the designer. — Who writes, reads and understands the code. Image by the author.

Engineers reading this will object, and they have a point. In Stack Overflow’s 2025 developer survey, 66 percent named AI answers that are almost right, but not quite, as their top frustration, and 46 percent said they distrust its accuracy. Someone accountable for the system still has to read what goes into it. That person is the engineer who owns it. The designer has a different job.

Understanding is the part you can’t delegate

What Roark took from the building site was not the skill of riveting. It was knowing what steel will do, so that his drawings only asked for things the material could give.

That is the part AI can’t hold for you. It will write whatever you describe, including things the medium handles badly, and it will review the code against the code, not against what the person on the other end needed. Judging that takes someone who knows the material.

You judge the output by running it, not by reading it. Open it at 320 pixels. Paste the longest real name you can find. Set the network to slow. Put the mouse away and use the keyboard. None of those tests needs a line of syntax.

What to learn instead of syntax

How layout flows: what wraps, what stretches, what refuses to shrink.
Which states exist: empty, loading, partial, failed, offline.
The shape of the data, including what a field holds when it holds nothing.
What costs a trip to the server and what is free on the device.
What a screen reader actually announces on your screen.
How to run the product on your own machine, without help.
How to ask the AI to explain a change in plain words.

None of these requires writing code. All of them require spending time with it.

The material determines the shape

Roark’s rule ends where this argument does: the purpose, the site and the material determine the shape. Our material hasn’t changed. It is still code, and it still decides what a screen can be. What changed is that we no longer have to hold the chisel to learn what it can cut.

Design in the material you ship was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

Need help?

Don't hesitate to reach out to us regarding a project, custom development, or any general inquiries.
We're here to assist you.

Get in touch