Truthish.

Spend enough time doing design systems work, and you’ll likely come across this one little phrase: “the source of truth.” It’s used to describe something that sets a standard, and acts as a canonical reference for others. For example, a team might say their design system acts as the source of truth for an entire organization’s design patterns. As a result, other teams should look to the system — that source of truth — when defining, designing, and building interfaces for their products. No more custom implementations of that subscription component, friends; the design system already has a subscription pattern, and the design system is our source of truth.

This isn’t the only context in which you might come across the phrase. But generally, I’ve found “the source of truth” often hinders more than it helps. And I think the phrase needs to be rethought, if not discarded altogether.

I’ve written before that design systems often widen the gap between design and engineering teams. In practice, this frequently means each “side” maintains its own workspaces, processes, and documents. I’d go so far as to say most design systems feel like several discipline-specific artifacts stacked underneath a single trenchcoat: inventories and audits conducted by the content team, a component library owned by engineers, a set of visual standards maintained by designers, and so on.¹

Despite this, most design system teams position the component library as the “source of truth” for the entire design system. And the logic here makes sense, honestly. After all, the library contains the components in use in production: it represents the “live” version of the system’s design patterns. From there, other disciplines are expected — implicitly or explicitly — to ensure their artifacts reflect what’s been implemented and deployed.

There’s an interesting tension here. Because practically, this means most design systems contain multiple sources of truth, while formally acknowledging only one. It’s true that a component library may reflect the state of the live, implemented design patterns. But that doesn’t change the reality for other contributors to the system: if they’re unable to work within the component library, their work continues to evolve in their own environments. Designers will iterate on the design system as it exists in the artboards of their visual standards — because for them, that’s the source of truth.

Suggesting otherwise obscures the multiple workflows your teams are trying — and occasionally, struggling — to coordinate. It’s one of the surest ways that hyperobject feeling can creep in. Everyone’s interacting with “their” slice of the design system, but nobody’s able to see the impact of their work across the entire platform.

What’s more, the gaps between the various sources of truth are often instructive. If a component had to change once implemented, what prompted that change? Technical constraints? A change in business requirements? Simply updating a component’s design to reflect its coded state won’t capture that story.

Design systems work is fundamentally lossy, in my experience. The more our mental models, our processes, and, yes, our sources of truth acknowledge that fact, the stronger our design systems will be.