Design Systems That Survive Contact With Engineering

I've inherited enough half-abandoned design systems to notice the pattern: they're built as a design artifact first, and the gap between "looks right in Figma" and "renders correctly in production" is where they die. This is the same discipline we bring to every UI/UX design engagement — the system has to survive contact with engineering, not just look good in a deck.

The handoff isn't the problem — the process before it is

By the time a component gets handed to engineering, most of the damage is already done if design and engineering haven't been talking. A component that looks like a simple button in Figma might hide four different padding values, three border-radius tokens, and a hover state nobody specified — because it was built by eye, not by system.

We build components in Figma using the same token structure they'll have in code from day one: spacing scale, color roles (not literal hex values), and type scale, all named identically to how they'll appear in the codebase. If a designer reaches for a value outside the token set, that's a signal to either add the token or reconsider the design — not to ship an undocumented one-off.

Documenting states, not just the happy path

The components that cause the most rework aren't the ones that look wrong — they're the ones where nobody specified what happens on error, empty state, loading, or at the character limit. We require every component in the system to document five states before it ships to engineering: default, hover/focus, loading, empty, and error. Skipping this is the single biggest source of "wait, what should this look like" Slack threads mid-sprint.

Where the token system actually lives

Tokens live in code first — a shared set of design tokens (CSS variables or a Tailwind config, depending on the stack) that both the Figma library and the component library pull from. When a token changes, it changes in one place, and both design and engineering see the update. This is the difference between a design system that drifts within two sprints and one that stays in sync a year later.

What "survives contact with engineering" actually means

A design system succeeds when an engineer can build a new screen using existing components and not need a design review to know it's correct — because the system already encoded the decisions. That only happens when:

1. Every token in Figma has a 1:1 counterpart in code, named the same way.
2. Every component's states are documented before implementation starts, not discovered during QA.
3. Design and engineering review new components together, not in sequence.

The systems that fall apart are the ones treated as a deliverable instead of an ongoing agreement between two teams. Ours gets revisited every sprint, not shipped once and left to rot.