A design system is not a Figma file with nice names

We get handed a lot of "design systems" that are really just a well-organized Figma file: a button component, a color palette, some named text styles. That's real work and it's a genuine improvement over nothing, but it's not a design system, because nothing about it prevents drift. Six months later there are four slightly different button styles again, because the file described a standard without anything enforcing it.

The distinction matters because the two things get sold interchangeably. A design library is a set of assets. A design system is a set of assets plus a mechanism that keeps production matching those assets over time. Most teams pay for the first and assume they got the second.

The Figma file should describe intent, but the actual source of truth needs to live somewhere the production code reads from directly, usually a design tokens file (color, spacing, type scale as structured data) that both Figma and the codebase reference. When a color value changes, it changes in one place and propagates, instead of requiring someone to manually update it in two systems that inevitably fall out of sync.

We've inherited codebases with a brand primary color hardcoded as a hex value in over sixty different components. Updating the brand's blue by a couple shades, a routine rebrand request, meant a search-and-replace across the entire codebase and hoping nothing got missed. With tokens defined once and referenced everywhere, that same change is a single value update that propagates automatically to every component using it.

Someone needs to own the system: reviewing new component requests, deciding when a one-off pattern becomes a real addition to the system versus a one-time exception, and periodically auditing production for drift from what the system actually specifies. Without an owner, a design system decays at exactly the rate new features ship, which for a growing product is fast.

This doesn't need to be a full-time role for most teams. It can be a standing hour a week where whoever owns the system reviews new component pull requests and flags anything that duplicates existing functionality with slightly different styling. What it can't be is nobody's job, because "everyone owns it" reliably means no one does, and drift accumulates silently until a redesign becomes the only way to fix it.

The systems that actually get adopted start with the handful of components used on nearly every page (buttons, form fields, cards, the type scale) fully specified and enforced, then expand only when a real recurring pattern justifies it. A sprawling 200-component system built speculatively before anyone needed most of it is why so many design systems get built once and then ignored.

We typically start a new client's system with somewhere between fifteen and twenty-five core components, covering roughly eighty percent of what a typical page actually uses. Everything past that gets added only after the same custom pattern shows up in three or more places, which is a much stronger signal of genuine reuse than a designer guessing what might be needed later.

Design tokens and a component library solve the technical half of the problem. The behavioral half is catching drift before it ships, and that means a lightweight review step, either a linter that flags hardcoded color and spacing values outside the token system, or a human reviewer checking new UI against the system before merge. Teams that skip this step end up with a technically excellent token system that nobody's actual pull requests reference.

We've had good results with a simple rule: any new UI pattern that isn't built from existing system components needs a one-line justification in the pull request description. It's a small amount of friction, and that friction is exactly what stops a one-off exception from becoming the fourth slightly different button style.

Even with tokens and governance in place, the handoff between a designer updating a component in Figma and a developer implementing that update in code is a common failure point. Tools like Figma's own dev mode and token-syncing plugins have gotten meaningfully better at closing this gap over the past couple of years, but they don't replace an actual process for who updates what, in which order, when a component changes.

We set an explicit rule with clients: Figma changes to a system component aren't considered final until they're reflected in code and both are checked against each other in a scheduled review, not whenever a developer happens to notice the Figma file changed. Without that explicit checkpoint, Figma and production drift within weeks, and everyone's staring at a slightly different version of the same button.

A design system that was built once, two years ago, and never governed since is usually not worth resurrecting wholesale. We audit what's actually still true to production versus what's drifted, keep the parts that match, and treat the rest as a rebuild rather than trying to patch documentation to match reality retroactively. It's faster, and it avoids inheriting bad assumptions baked into a system nobody's checked against real usage in a long time.

The audit itself is usually a week of work: screenshot every unique component actually rendered in production, compare each one against what the old Figma file claims should exist, and sort the results into three buckets, still accurate, drifted but salvageable, and abandoned entirely. That third bucket is usually bigger than clients expect, often a third or more of the original system, and it's better to know that up front than to discover it component by component months into trying to re-adopt a system that quietly stopped matching reality a long time ago. The output of that audit becomes the new system's actual starting inventory, which tends to be smaller, more honest, and considerably easier to keep governed than whatever the original file claimed to cover.