Design systems developers actually use (and why most die in Figma)

Most design systems follow the same arc. A designer spends a quarter building a beautiful component library in Figma. There's a kickoff deck, a naming convention, a launch announcement in the team channel. Eight months later the Figma file holds 200 polished components, production uses about 25 of them, and every new feature ships with hand-typed hex values because the deadline was Thursday.

The system didn't fail because the design was weak. It failed because it only existed in Figma, and Figma doesn't ship.

Why design systems die in Figma

A Figma library and a production codebase are two sources of truth, and two sources of truth always drift. Designers evolve the library. Developers copy the component that's already in the repo, tweak it, and move on. Two quarters in, "on brand" means one thing in design review and a different thing in code review, and nobody can prove which one is right.

The test of a design system was never whether designers use it. They built it, of course they use it. The test is whether a developer under deadline pressure reaches for the system because it's the fastest path to done. Every other adoption metric is decoration.

We'll say it plainly: if your tokens don't exist as CSS variables in production, you don't have a design system. You have a mood board with a naming convention. That gap is where brand consistency goes to die, and in B2B it isn't cosmetic. Brand is a revenue problem, because buyers read visual drift as organizational drift.

Tokens first, components second

The build order most teams follow is backwards. They start with components, buttons and cards and modals, then extract tokens later, if ever. Start with the token layer instead, and put it in the one place neither discipline can ignore: CSS custom properties.

Two tiers. Primitives are raw values with scale names: brand-600 is #2563eb, coral-700 is #c73c12, neutral-200 is #e2e8f0. Semantic tokens are roles that point at primitives: background, foreground, muted, border, accent. Components reference semantic tokens for surfaces and text, never primitives. That single rule is the difference between "retheme the product" being a token edit and being a six-week migration.

Tailwind CSS 4 made this nearly free. The @theme block turns token definitions into utility classes directly, so the variable layer and the class layer can't diverge. If your design tooling and your codebase live in separate universes, Style Dictionary or Tokens Studio will sync Figma variables into CSS. Watch the sync direction, though. Code is the source of truth for what ships, because it's the only layer your users ever see.

The component-parity contract

Tokens keep colors honest. Parity keeps components honest. The contract fits in one sentence: a component exists when it exists in Figma and in code under the same name with the same variants, or it doesn't exist.

"Button / Secondary / Small" in Figma maps to <Button variant="secondary" size="sm" /> in code. Same names, same options. When the names match, design review and code review finally speak the same language, and handoff shrinks from a meeting to a link.

Parity also imposes a healthy cap. You don't need 200 components. Most B2B products need 25 to 40 that are real in both worlds. Everything else is an orphan, a Figma frame nobody built or a code component nobody designed, and both kinds of orphan are drift with a timestamp. Keep the inventory public. A Storybook instance or a live style-guide page is the contract's public record. If a component isn't in the live inventory, it's a proposal.

Dark mode is a constraint, not a theme

Teams treat dark mode as a feature to bolt on later, and later is exactly when it gets expensive: an audit of every hardcoded color in the codebase. In a token-first system, dark mode is a second set of values for the same semantic tokens. CSS light-dark() plus a data-theme override handles the switching. We shipped it across our own site in a branch, not a quarter.

Dark mode also keeps your naming honest. "White" is not a token, because in dark mode it isn't white. "Background" is a token. If you can't name a color by its role, you haven't understood the role yet.

And it forces contrast decisions into the tokens, where they belong. Our own coral-500 measures 2.84:1 against white text, well under the WCAG AA floor of 4.5:1, so buttons use coral-700 and coral-500 stays decorative. A token-first system encodes that decision once. A system that lives only in Figma re-argues it on every screen, and loses often enough that an accessibility scan turns into a commercial risk.

Governance that survives a Thursday deadline

Design-system governance usually means a 40-page document nobody reads and a committee nobody can schedule. That version dies the first time a launch date meets an edge case. Governance that survives deadline pressure is small and mechanical:

• A lint rule that flags raw hex values in component files. The build says no so a person doesn't have to.
• One owner, not a committee. A new token or variant gets approved or rejected by one person in under a day.
• A written escape hatch. Sometimes the one-off is justified. Log it, ship it, revisit it monthly. The alternative isn't zero exceptions; it's unlogged exceptions everywhere.
• The system must be the fastest path. If reaching for a token is slower than typing a hex value, the hex value wins every Thursday from now on.

None of this works if designers and developers report into separate worlds and meet only at handoff. It's why we staff design and engineering as one team instead of a relay race, and why our 16-week MVP builds start with tokens in week one.

What shipping the Octet Grid taught us

This year we rebuilt DGTL's own identity around a mark we call the Octet Grid: eight cells in a three-by-three grid with the center removed. The eight cells are our eight practices. The empty center is the client they surround.

The interesting part wasn't the mark. It was the rollout. Our site is about 140 static pages across English and Spanish, light and dark, plus generated OG images, favicons, and a web manifest. The entire visual identity resolves to one @theme block in one CSS file: 40 custom properties, roughly 60 lines. When the Octet Grid landed, restyling the whole site was an edit to that block. Logo, buttons, charts, and social images picked up the change because they had nowhere else to get their colors from.

That's the lesson we'd put on every brand project: consistency isn't discipline, it's architecture. Discipline runs out on deadline week. Architecture doesn't care what week it is.

If your product looks different from your website, and your website looks different from your deck, the fix isn't stricter brand policing. It's a token layer, a parity contract, and a governance model that fits on one page. That's the work our Studio practice does, and we run our own brand the same way in public: the tokens, contrast pairings, and usage rules live on our brand page for anyone to inspect.

Related: B2B Brand Design and Conversion → · Cross-Practice Teams → · The 16-Week MVP →