Design systems should help teams ship, not decorate files

The Figma-system trap

The most common failure mode of design systems is also the most invisible one — the system that exists beautifully inside a Figma file and almost nowhere else. The colour palette is documented. The type scale is documented. The button component has every state. The dropdown has every variant. None of it is wired into the codebase the team actually ships from.

The result is a system that looks like infrastructure and behaves like decoration. Designers reference it. Developers re-implement it. The two artifacts drift. Within six months the codebase has buttons that do not match the Figma buttons, type sizes that do not match the Figma scale, and a team that has stopped trusting the system to be accurate.

Design systems exist to help teams ship faster and more consistently. A system that does not change the speed or consistency of shipping is not a design system. It is a style guide pretending to be one.

Design systems are product infrastructure

The useful frame is to treat the design system as part of the product's foundation, not as a separate deliverable. The components are not a catalogue. They are the building blocks of every screen the user will ever see. The decisions encoded in the system are decisions the team has agreed not to remake on every new feature.

That framing changes what the system needs to do. It needs to be installable in the codebase. It needs to be the source of truth, not a description of one. It needs versioning, so the team can update components confidently without breaking pages downstream. It needs documentation that lives next to the code, not in a separate file that goes stale.

Most teams discover this the hard way. The Figma library was the easy part. The codebase implementation is where the system either becomes useful or becomes a museum.

The components that earn their place

Not every UI element belongs in a design system. The discipline is to include components that are used often, behave consistently, and benefit from being decided once and reused. Buttons. Inputs. Selects. Modals. Cards. Layout primitives. The handful of typography styles the product actually uses.

The discipline is also to exclude things that look like good system candidates and are not. Bespoke marketing components that appear on one page. Decorative sections that change every quarter. Icons that are used once. Animations specific to a single flow. Each of these can be inside the codebase without being in the system, and that distinction matters because every system component carries a maintenance cost.

A small, sharp design system that covers eighty percent of the product's UI is more useful than a sprawling one that covers everything and is half-broken at any given time. The cut is part of the work.

The maintenance reality

The largest hidden cost of a design system is keeping it accurate as the product changes. Every new feature has a chance of introducing a new button variant, a new card layout, a new spacing rule. The team has to decide: does this become part of the system, or does it stay local to the feature.

That decision is constant, and the system's health depends on how it is handled. If every new variant gets absorbed into the system without scrutiny, the system bloats — every component has fifteen variants and the file becomes harder to navigate than no system at all. If no new variants get absorbed, the system drifts — every feature ships with one-off styling and the codebase becomes inconsistent.

The teams that maintain healthy systems have a regular conversation about what belongs in and what stays out. It is not a glamorous meeting. It is one of the more important ones.

Ship-then-systematise vs systematise-then-ship

Teams approach systems in two directions, and one of them is dramatically more effective.

The systematise-then-ship approach builds the system first, then builds the product against it. The system is comprehensive, the documentation is thorough, and almost nothing has been used in anger. By the time the product hits real users, half the system needs to change because the assumptions baked into it turned out to be wrong. The investment was upfront, and most of it gets rebuilt.

The ship-then-systematise approach builds the product first, gets feedback, then notices patterns in what the product actually needs and extracts a system from those patterns. The system arrives later but is shaped by reality. The components are the ones the team has used three times, not the ones the team thought they might use someday.

The second approach is harder to sell internally because it feels less rigorous. It produces better systems almost every time, because the system is documenting decisions the team has already made and validated, rather than predicting decisions they might want to make later.

A pragmatic test

Before adding anything to a design system, we ask the same three questions.

Has this pattern shown up at least three times in production? If no, it is not yet a system component. It is a feature-specific element.

Will it be used by more than one designer or developer in the next quarter? If no, the system is not the right home for it.

Is the variation it covers genuine, or is it accidental? Two buttons that differ only because no one decided are not two variants. They are one button rendered inconsistently. The system fixes that, not encodes it.

These questions feel restrictive. They are. The restriction is the point. The teams with the most useful design systems are not the ones with the most components. They are the ones with the right components, maintained well, used everywhere.

The shape of a system that works

The design systems that hold up over years tend to look similar in retrospect. A small set of foundational tokens — colours, type, spacing, radii, shadows — used everywhere. A focused set of components — twenty or thirty, not a hundred — that cover the product's actual needs. Tight implementation in the codebase, with the design file mirroring it rather than leading it. Versioning and changelogs so updates can be adopted deliberately. Documentation that explains usage and intent, not just appearance.

What is missing from that description is glamour. None of these systems are impressive to demo. They are impressive to use, six months in, when a new feature gets shipped in half the time it would have taken without them, because half the decisions were already made.

That is the real test. A design system is working when the team forgets it exists during the build and is grateful it exists at the launch.