Here is a picture of a Windsor chair. Every part sockets into a solid seat: legs splay down from beneath, spindles and splat rise from above. It has no frame. The joints lock because green wood shrinks onto dry spindles as it dries. You cannot design this chair by drawing it. You design it by making it. The design is a material event, not a picture.
A UI is the same. The medium is code. The UI is the prose; the code is the argument. You cannot design the UI without making it in the material it’s rendered in.
This is a general principle: you only truly know what you make. Vico called this verum factum—the true and the made are convertible into each other.
Here’s a real example. At Vana, the data-connector UI was being rendered three different ways: the production embed, the demo lab, and the error states. Each had a different idea of what state the user was in. So we did not have one interface. We had three approximations of one.
The refactor made the real route the only renderer, made state canonical, and made the lab preview the product itself rather than a fake copy. Only then could I see the actual requirements. Only then could I design a UI that was coherent, consistent, and hard to break.
Before that, the interface could drift into incoherence: a route mismatch here, an async race there, death by a thousand cuts. The refactor established that demo and prod were the same interface, and so they could be driven by the same state model and the same renderer.
I refactored the part that determines whether there is one UI at all. That was the design work.
By knowing what was true of the system, I could design a UI that rendered that truth faithfully.
Most people assume UI design means making a picture of an interface. Choose colours, arrange elements, throw the file over the wall.
But an interface is not a picture. It is sequential and dynamic. It responds, holds state, routes, fails. None of that lives in a static file. A Figma file can describe the medium. But it is not the medium.
Consider the Windsor chair again. You cannot design one by drawing it. The chair holds together because green wood shrinks onto dry spindles as it dries. The joinery is the material behaviour. To design the chair, you had to have made one. The design lives in the wood, not in the picture of the wood.
A UI is the same. A tab not backed by a route is not a navigation pattern, it is a lie the interface tells the user. A page that mixes data fetching, access control, and layout is not a component, it is a mess that will resist every future design change. You cannot see any of this in a mockup. You can only know it in the medium the interface is actually made of.
Design is the structure that makes things work. If the structure lives in code, the design work lives in code.
A decade of static design tools trained people to treat ideation and execution as separate acts. But the interface is downstream of the system. If you do not shape the system, you do not control the interface. You are decorating. No Figma design token ceremony will fix that.
Whether or not a designer writes code, the design work is still in the code.
I wrote the first version of this argument in (2018). Eight years later it hasn’t changed. Ideation and execution are one act. The interface is where they meet.
NB. Refactors that don’t buy product clarity are engineering vanity. The justification is never “cleaner code” but that the change makes the interface easier to reason about, extend, and keep consistent for users. If it doesn’t do that, it’s just moving furniture.