Should designers code?

The question that doesn’t go away

A decade ago this question got framed as a binary: coding is either the jail of creativity or the key to a perfect result, and a designer either learns to build their own work or hands it off and loses control of the details. That framing was already too simple then, and it’s more clearly wrong now, because the actual boundary between design and code has moved — not toward one side winning, but toward a layer that didn’t really exist yet: the design system.

Design tokens made the argument mostly moot

A design token — a named, single-source-of-truth value for a color, a spacing unit, a type scale step, a border radius — is the piece of infrastructure that used to force the choice the original article described. Without tokens, “getting the design right in code” meant a designer either hand-tuning CSS values themselves or hoping a developer’s interpretation of a Figma comp matched pixel-for-pixel. With tokens, that translation step mostly disappears:

{
  "color.accent.default": { "value": "#2e6f6a" },
  "space.3": { "value": "1.5rem" },
  "radius.md": { "value": "0.5rem" }
}

A designer changes color.accent.default in the token source, and every component that references the token — in the design tool and in the shipped product — updates together, because both are reading the same value rather than a developer re-deriving it from a screenshot. The argument about whether a designer needs to know CSS to get pixel-perfect results is much less pressing when the values themselves are shared infrastructure rather than something translated by hand at the handoff.

A design system is a shared language, not a hand-off point

The bigger shift is that “design” and “code” increasingly aren’t sequential steps on the same artifact — sketch it, then build it — they’re two representations of one system of components, states, and rules. A designer working inside a mature design system (Radix, its internal equivalents, or a company’s own component library) is already working with the same primitives — button variants, spacing scale, typography scale — that show up in the codebase, expressed in a design tool instead of in source files. That’s a meaningfully different relationship to code than “designer learns to write CSS so they can build their own comps.”

This doesn’t eliminate the original question so much as relocate it. The useful version isn’t “should a designer be able to write production code,” it’s “how much of the shared system’s vocabulary does a designer need to fluently read and reason in” — and the honest answer is: a lot more than a decade ago, because that vocabulary is now doing the work that hand-offs used to do.

What AI tooling changed about the boundary

The newest shift, and the one the original article obviously couldn’t anticipate, is how much of “turn a design into working code” AI-assisted tools can now do directly — generating a reasonable first-pass component from a design file or a description, wiring it to an existing token set and component library. That doesn’t remove the need for either discipline, but it changes what’s valuable to know:

• Knowing enough code to evaluate the output matters more than knowing enough code to type it from scratch. A designer who can look at a generated component and recognize that it ignored the existing spacing tokens, or hardcoded a color that should reference the palette, adds real value even without writing the fix themselves.
• The floor for “acceptable first draft” rose, which raises what differentiates good design work. Interaction detail, accessibility under real content (not lorem ipsum), and consistency with the rest of the system are where a designer’s judgment still isn’t replaceable by a generator working from a single screen in isolation.
• The original worry — “designers will just make what they can code, and lose ambition” — inverts somewhat. The risk with generation tools is closer to the opposite: producing something that looks plausible without anyone having verified it holds up structurally, which puts more weight on a reviewer (designer or engineer) who actually understands the system well enough to catch it.

Where this leaves the original question

Should a designer be able to write code? For a solo generalist building something end to end, yes, clearly, for the same reasons the original article gave — no dependency, no loss of intent in translation. In a team with a real design system, the more useful skill isn’t “can write production CSS,” it’s fluency in the shared vocabulary of tokens and components that both design and code now express, plus the judgment to tell when a generated first draft respects that system and when it quietly doesn’t. The jail-versus-key framing from a decade ago assumed design and code were still two separate crafts joined by a hand-off. Increasingly, for teams that have invested in a real system, they’re two views onto the same one.

---

Originally published in 2015 and updated for 2026.