The UX-Engineering Collaboration Gap: Why Design Systems Still Need a 'Single Source of Truth' in 2026

General
1

Three months ago, we killed a feature two weeks before launch. Not because of bugs. Not because of performance. Because when engineering delivered what design had spec’d, nobody recognized it.

The button colors were wrong. The spacing was inconsistent. The mobile experience barely functioned. And yet—engineering had followed the Figma files exactly. The disconnect? Those Figma files were two iterations old, the design tokens hadn’t been updated, and nobody had synced the component library. Classic design-engineering handoff failure.

The “Single Source of Truth” Mythology

Everyone talks about needing a single source of truth for design systems. But in 2026, I’m not convinced that’s the right mental model anymore. Here’s why:

Where could “truth” live?

  • Figma files? They drift from implementation within days
  • The code repository? Designers can’t read it, can’t contribute to it
  • Design tokens? They’re just JSON until someone builds tooling around them
  • Documentation sites? Dead the moment they’re published

The real answer I’ve learned: there is no single source. There’s a pipeline, and the question is whether that pipeline has integrity.

The Airbnb Data Point Everyone Should Know

When Airbnb built their Design Language System, they didn’t just create pretty component libraries. They cut design-to-development handoff time by 34% and reduced design inconsistencies by 68%.

How? Not by picking Figma over code or code over Figma. By treating design tokens as the Rosetta Stone between the two worlds.

The Framework I’m Using Now

After that failed launch, I’ve started thinking about design systems through this lens:

  1. Git is the source of record (not truth—record). Design tokens live in version control. Everything else derives from them.

  2. Figma Variables are the design workspace. Designers work in Figma Variables, which can now support multi-mode theming and semantic tokens.

  3. Tokens Studio is the sync mechanism. Two-way sync between Figma and Git. Not perfect, but it’s the bridge we need.

  4. Style Dictionary is the compiler. Transforms tokens into whatever format each platform needs—CSS variables, iOS tokens, Android XML, you name it.

  5. Documentation is a build artifact. Auto-generated from the tokens. If it’s manually written, it’s already wrong.

The Real Problem: Temporal Breakdown

But here’s what I’ve realized—tools don’t fix the fundamental problem. The real issue is what researchers call temporal breakdown: designers check out too early, engineers get pulled in too late.

By the time engineering sees the “final” designs, design has mentally moved on. When engineers discover edge cases or technical constraints, design is already three projects ahead. The handoff is asynchronous by default.

Question for This Community

I’m curious how others are thinking about this in 2026:

  1. Where does “truth” live in your design system? Figma? Code? Tokens? Somewhere else?

  2. How do you prevent the temporal breakdown? Do you have embedded design engineers? Weekly syncs? Something else?

  3. What’s actually working? We have better tools than ever (Figma Variables, Code Connect, W3C Design Tokens spec), but I still see handoff failures constantly.

The cynic in me thinks this is an organizational problem disguised as a tooling problem. But I’d love to be proven wrong with a great workflow.

2

Oh wow, this hits close to home. :sweat_smile:

My failed startup (RIP 2023) had this EXACT problem, and I didn’t even realize it was one of the reasons we died until reading your post, David.

We had beautiful Figma files. We had a talented engineering team. But we had no pipeline integrity. Design would finish mocks, toss them over the wall, and move on to the next feature. By the time engineering built it, we’d already mentally redesigned it twice. Sound familiar?

What I’m Doing Differently Now

I lead design systems at a consultancy now, and here’s the workflow that’s actually working for us:

1. Git IS the truth (you nailed this, David)

Not Figma. Not the docs site. Git. Everything flows through version control.

2. Tokens Studio + Figma Variables = the bridge

We use Tokens Studio for Figma to sync design tokens bidirectionally with our Git repo. Designers work in Figma Variables (which got MASSIVELY better with the multi-mode support in late 2025), and those variables map to JSON tokens in the repo.

3. Style Dictionary compiles everything downstream

CSS variables for web, Swift tokens for iOS, XML for Android. One source, multiple outputs.

4. Semantic versioning for tokens

This was the game-changer. We version our design tokens like code: v2.3.1. When we bump a major version, everyone knows breaking changes are coming. Engineering can plan for it.

The W3C Design Tokens Spec Changed Everything

In October 2025, the W3C Design Tokens Community Group published their first stable spec. That sounds boring, but it’s HUGE. It means design tokens are finally portable across tools.

Before that, every tool had its own token format. Tokens Studio had one structure, Style Dictionary had another, Figma plugins had their own thing. The W3C spec gives us a common language.

We’re not all the way there yet—adoption is still spotty—but the direction is clear.

The Hard Truth: There’s No “Single” Source

I appreciate your framing, David: “There’s a pipeline, and the question is whether that pipeline has integrity.”

That’s exactly right. The “single source of truth” framing is a lie. It’s a comforting lie, but it’s wrong.

What we actually have (when we do it right):

  • Design tokens in Git (the source of record)
  • Figma Variables (the design authoring environment)
  • Component libraries (React, Swift, etc.) consuming the tokens
  • Documentation auto-generated from the tokens
  • A CI/CD pipeline ensuring all of this stays in sync

That’s not “single.” That’s a distributed system with eventual consistency. And like any distributed system, it breaks when the network connections fail.

Where Accessibility Gets Lost

Here’s something nobody talks about enough: when the design-to-dev handoff is broken, accessibility is the first casualty.

Accessible color contrast ratios? Lost in translation.
Focus states for keyboard navigation? Designer forgot to spec them, engineer didn’t think to ask.
Screen reader labels? Not in the Figma file, not in the code.

A token-driven approach FORCES you to think about these things upfront:

  • Color tokens include contrast ratio metadata
  • Component tokens specify all interactive states (hover, focus, active, disabled)
  • Semantic tokens carry ARIA role information

When accessibility is baked into the tokens, it flows through the entire pipeline automatically.

What I Want to See More Of

I love that you’re asking these questions, David. Cross-functional discussions like this are so rare. Product leaders don’t usually engage with design systems at this level.

More of this, please. Design systems fail when they’re treated as a designer problem or an engineering problem. They succeed when they’re understood as an organizational problem with product, design, AND engineering stakeholders.

Would love to hear from others: what’s your token workflow? Are you using the W3C spec? How are you handling accessibility in your design systems?

3

David and Maya—both excellent perspectives. Let me add the Fortune 500 enterprise angle.

At our fintech company, we’ve learned that the “single source of truth” conversation is actually masking a deeper organizational issue: who owns the design system?

The Ownership Problem

In our case:

  • Design team thinks they own it (they created it)
  • Engineering team thinks they own it (they maintain it)
  • Product team thinks they own it (they prioritize it)
  • Nobody actually owns it

Result? Design tokens drift. Component libraries fall out of sync. Documentation rots. Classic tragedy of the commons.

Our Solution: The Design Engineer Role

About 18 months ago, we created a dedicated “Design Engineer” role. Not a designer who codes a little. Not an engineer who designs a little. A genuine hybrid who:

  1. Understands both Figma Variables AND React component APIs
  2. Manages the Tokens Studio → Git → Style Dictionary pipeline
  3. Reviews both design specs and pull requests
  4. Acts as translator between design and engineering

This person is embedded with the design systems team but reports to engineering leadership. Their job is literally to maintain pipeline integrity.

The “Temporal Breakdown” Problem Maya and David Identified

You’re both absolutely right—designers disengage too early, engineers engage too late.

Our design engineer bridges that gap by:

  • Joining design critiques to flag technical constraints early
  • Pairing with engineers during implementation to ensure design intent
  • Running weekly “design systems office hours” where anyone can ask questions
  • Maintaining the token sync pipeline so design changes propagate to code automatically

It’s not perfect, but it’s working. Our design-to-dev handoff cycle went from 2-3 weeks to 5-7 days.

The Challenge: Legacy Systems

Here’s what Maya’s token-first approach doesn’t address (not a criticism, just reality): what do you do with a 10-year-old codebase that predates design tokens?

We have React components. We have Angular components. We have old jQuery code that’s “too expensive to rewrite.” They all need to consume the same design system.

Our pragmatic approach:

  • New components: token-first, built with Style Dictionary outputs
  • Legacy components: gradual migration, starting with color and typography tokens
  • Ancient code: CSS variable fallbacks, even if it’s not “pure”

Perfect is the enemy of good. We’re making progress, not achieving perfection.

Question for Smaller Teams

One thing I’m curious about: how do smaller teams (pre-Series B, say) afford a dedicated design engineer role?

We have 40+ engineers and 12 designers. We can justify a full-time design engineer. But when you’re a 10-person startup, do you just live with the handoff friction? Or is there a lighter-weight solution I’m missing?

Would love to hear how smaller teams are solving this without dedicated headcount.

4

Luis, you asked the exact right question: “Who owns the design system?”

At my EdTech startup (80 engineers, grew from 25 in the last year), we learned this the hard way. Let me share what’s working for us.

Design Systems as a Product Team

We don’t have a “Design Engineer” role (yet—we’re considering it after reading Luis’s comment). Instead, we treat the design system itself as a product.

What that means:

  • The design system has a product manager (rotates every 6 months)
  • It has a roadmap (versioned releases, deprecation timelines)
  • It has customers (our internal product teams)
  • It has SLAs (how fast do we respond to component requests?)
  • It has metrics (adoption rate, handoff cycle time, consistency scores)

This shift in mindset changed everything. When you treat the design system as a product:

  • Someone is accountable for it (the PM)
  • Teams understand there’s a support channel (not just hoping design or eng will help)
  • There’s a budget for it (we allocate 15% of eng capacity to design systems work)
  • Leadership sees it as strategic, not “overhead”

The Culture and Process > Tools Argument

David, you said: “The cynic in me thinks this is an organizational problem disguised as a tooling problem.”

You’re not cynical—you’re right. :100:

We have Figma Variables. We have Tokens Studio. We have Style Dictionary. We have all the tools Maya described. But the tools only work if you have the cultural and process foundation to support them.

Our cultural changes:

  1. Weekly design-eng pairing sessions (Tuesdays, 1 hour, non-negotiable)
  2. Shared Slack channel for component changes (#design-system-updates)
  3. Design can’t mark work “done” until eng reviews feasibility (prevents the temporal breakdown)
  4. Eng can’t close a feature PR without design sign-off (prevents “we’ll fix the polish later” which never happens)

These aren’t tool changes. These are process and culture changes. And they’re harder to implement than buying Figma licenses.

Where Inclusive Design Gets Lost

Maya mentioned accessibility—I want to double down on that because it’s critical.

When design-to-dev handoff is broken, inclusive design suffers. Not just accessibility (though that too), but:

  • Internationalization (RTL languages, character overflow)
  • Performance on low-end devices (design specs assume everyone has the latest iPhone)
  • Diverse user contexts (dark mode, high contrast, reduced motion)

Our approach: inclusive design requirements are baked into design tokens from day one.

Color tokens include:

  • WCAG contrast ratios (AA and AAA)
  • Dark mode variants
  • High contrast mode overrides

Typography tokens include:

  • Minimum sizes (never below 16px base)
  • Line height for readability
  • Font loading strategies (no layout shift)

Spacing tokens include:

  • Touch target minimums (44x44px for mobile)
  • Responsive scaling (not just desktop-first)

When these constraints live in the tokens, they flow through the entire pipeline automatically. No one has to remember to “make it accessible” at the end—it’s accessible by default.

Answering Luis’s Question: Smaller Teams

Luis asked how smaller teams afford a dedicated design engineer. Here’s what we did before we could afford dedicated roles:

1. Rotation model
Every quarter, one engineer and one designer co-own the design system. They’re still on their regular team, but they commit 20% of their time to design systems work. It’s part of their job, not a side project.

2. Design systems office hours
Every Friday afternoon, 1-2 hours. Open Zoom, open Figma file, open code repo. Anyone can drop in with questions. No agenda, just support.

3. Documentation as a first-class deliverable
When a designer finishes a component, the deliverable isn’t “Figma file.” It’s:

  • Figma file with all states
  • Tokens exported to JSON
  • Written handoff doc explaining edge cases
  • Loom video walkthrough (5 min max)

When an engineer finishes a component, the deliverable isn’t “React component.” It’s:

  • Component code
  • Storybook examples
  • Accessibility test results
  • Design sign-off in the PR

This way, even without dedicated headcount, everyone knows what “done” means.

The Real Unlock: Executive Support

Here’s what nobody talks about: all of this requires executive-level support.

If your CTO or CPO doesn’t understand why design systems matter, you’ll never get the time or budget to maintain them properly. It’ll always be “nice to have” work that gets deprioritized when deadlines loom.

At my company, I had to make the business case:

  • Airbnb’s 34% handoff time reduction = faster time-to-market
  • 68% reduction in inconsistencies = better user experience = higher conversion
  • Reusable components = faster feature development = more efficient engineering

Once leadership saw design systems as a force multiplier, not overhead, we got the resources we needed.

This is a fantastic thread. Would love to continue the conversation—especially hearing from folks at smaller startups about what’s working for you.

5

Keisha—“design systems as a product team” is EXACTLY the mindset shift that was missing at my failed startup. :sob:

We treated the design system as a “nice to have” side project. No PM. No roadmap. No metrics. Just “the designers will maintain it when they have time” (spoiler: they never had time).

What I’m Stealing from This Thread

Luis’s Design Engineer role: I’m pitching this to leadership next week. We’re big enough now (3 product teams consuming the design system) that we can justify dedicated headcount.

Keisha’s rotation model: Before we get approval for dedicated headcount, this is brilliant. I’m going to propose quarterly rotations starting next sprint.

David’s framework: The “Git as source of record” framing is how I’m going to explain our token pipeline to non-technical stakeholders. Way clearer than my previous attempts.

Practical Tip: Version Your Tokens Like Code

Since people are asking for tactical advice, here’s the workflow that saved us:

Semantic versioning for design tokens:

  • v1.0.0 → v1.1.0 (added new color token) = minor version, backward compatible
  • v1.1.0 → v2.0.0 (changed primary brand color) = major version, BREAKING CHANGE

We document this in a CHANGELOG.md right alongside the token JSON files in Git.

When engineering sees a major version bump in the design tokens package, they know to allocate extra time for migration. No more surprise “hey we changed the colors, hope your app still works!”

The Figma Variables + Style Dictionary Pipeline (Tactical How-To)

Since folks asked, here’s our actual pipeline:

  1. Designers work in Figma Variables

    • Organized by category: color, spacing, typography, elevation, etc.
    • Semantic naming: color/primary/base not color/blue/500
    • Multi-mode support for light/dark themes

  2. Tokens Studio plugin syncs to Git

    • Bi-directional sync (design → code, code → design)
    • JSON files committed to tokens/ directory
    • PR created automatically when designers push changes

  3. Style Dictionary compiles tokens

    • Runs in CI/CD on every commit
    • Outputs: CSS variables, SCSS variables, JS constants, iOS Swift, Android XML
    • Each platform gets tokens in its native format

  4. Component libraries consume compiled tokens

    • React components import CSS variables
    • iOS components import Swift tokens
    • Android components import XML resources

  5. Docs site auto-generates

    • Token documentation is a build artifact
    • Shows token name, value, usage examples, accessibility notes
    • Never manually written, never out of date

This isn’t perfect, but it’s working. The key is automation—every step except “designers work in Figma” is automated.

Responding to Luis’s Legacy Code Question

Luis asked about 10-year-old codebases. Here’s what we did at my consultancy for a client in that exact situation:

Gradual migration strategy:

  1. Start with CSS variables at the root
  2. Legacy code can reference CSS vars even if it’s old jQuery spaghetti
  3. As you touch legacy components, wrap them in a “design system adapter” that maps old styles to new tokens
  4. Set a deprecation timeline (e.g., “old color classes deprecated Q3 2026”)
  5. Eventually delete the legacy styles

It’s not glamorous, but it works. You don’t have to rewrite everything at once.

What This Thread Shows

This is exactly the kind of cross-functional conversation I wish I’d had when I was building my startup.

Product leader (David) asking strategic questions about where truth lives.
Design systems lead (me) sharing tactical token workflows.
Engineering leaders (Luis, Keisha) explaining organizational structures that make it sustainable.

None of us has the full picture alone. We need all three perspectives to make design systems actually work.

Thanks for starting this discussion, David. And thanks to Luis and Keisha for the practical insights. I’m taking notes. :memo::sparkles: