Design and Development are the Same System

Ghosts in the system

We talk about “design” and “development” like they’re separate disciplines.

They’re not.

They’re two interfaces into the same product system.

Design (Figma) is one interface.

Codebase (the component library—documented in Storybook or whatever your team uses) is another.

If design creates a state engineering can’t support, things get weird. If engineering adds a prop design didn’t model, reverse weird. You know when something looks right but feels off? That uncanny valley between intent and implementation? Yeah…it's haunted. The component renders, the spacing checks out, the color passes contrast—and yet. Something is wrong. Something you can't file a ticket for.

That's not a bug. That's a ghost.

When design and development aren't one system, the inconsistencies don't scream. They whisper. A misaligned token here. A hardcoded value there. A prop that exists in code and nowhere in Figma. Nobody catches it in review because nobody was looking for it. It lives in the gap between disciplines—and gaps don't have owners.

Design the Behavior. Build the Intent.

Here's the uncomfortable truth most teams sidestep: if your designers are designing screens and your engineers are building components, you don't have a system. You have two parallel monologues dressed up as a conversation.

A real system has a shared vocabulary. The same token name that lives in your Figma variables file lives in your design tokens JSON. The same component variant a designer configures in a frame maps directly to a TypeScript prop. Not approximately. Not spiritually. Exactly.

This isn't aesthetic housekeeping. It's structural load-bearing work.

Design is responsible for modeling behavior—every state, every edge case, every "what happens if the label is 40 characters?" moment. Engineering is responsible for enforcing that model—making the impossible states actually impossible, not just frowned upon in a Notion doc nobody reads.

When those two responsibilities are in sync, you're not handing off a design. You're deploying one.

The Token Is the Contract

The layers covered in The Intent Layer aren't just an organizational convenience—they're a shared language that both disciplines can speak without a translator.

Foundations are physics. Both sides agree on gravity before anything gets built.

Semantic tokens are grammar. When a designer says color.action.primary and an engineer reaches for the same value, nobody's playing telephone.

Components are the contract. Variants in Figma aren't aesthetic options—they're the exact props being surfaced in code. If a button variant exists in Figma that doesn't exist in the component library, it's not a design choice. It's a liability.

Patterns are the clause nobody reads until something breaks. This is where async states, conditional rendering, and validation flows live—and where most systems quietly collapse, because design stopped at "what it looks like" and the rest was improvised.

Improvisation is great in jazz. In a product system, it's technical debt with a jazz soundtrack.

One System, Two Lenses

The goal isn't for designers to write code or engineers to live in Figma (though honestly, a little cross-contamination never hurt anyone.)

The goal is parity of intent. That the mental model a designer has when they're designing a flow is the same mental model an engineer has when they're implementing it. Same constraints. Same boundaries. Same understanding of what's allowed versus what's merely possible.

Entropy is always working. Components drift. Tokens get overridden. Hardcoded values multiply like they're on a deadline. The only thing that holds a system together over time isn't tooling or documentation or even discipline.

It's a shared belief that design and development are describing the same thing.

One system. Two interfaces.

Make sure they're both running the same OS.