Keeping a system alive — abstraction and governance

Choose your track

Read this module through your lens

Systems rot socially, not technically

By now you can build components, variants, properties, and tokens — the technical craft of a design system. Here is the uncomfortable truth of mastery: that craft is rarely why systems fail. They fail socially. The library is well made, but under a deadline someone copies a button and tweaks it locally, someone else cannot find the right component so they rebuild it, a third detaches an instance to “just make it work,” and three months later the library and the shipping product have quietly diverged. Nobody decided to abandon the system; it eroded one reasonable shortcut at a time.

So the master-level skill is not another feature. It is judgment and stewardship: deciding what deserves to be a component at all, and doing the unglamorous work that keeps a team actually using the library. A perfect component that no one adopts is worth nothing.

The two-sided abstraction mistake

Knowing when to turn a pattern into a component is a senior judgment, and you can err in both directions. Over-abstraction is the eager beginner’s error promoted to the system: making a component for something used once or twice, or adding props for hypothetical futures. Every premature abstraction is permanent maintenance cost and clutter that makes the real components harder to find — and it often guesses the wrong shape, because you abstracted before you understood the pattern.

Under-abstraction is the opposite: an obvious, repeated element — an input field on nine screens — left as copies because no one took the time. That is the copy-paste debt at system scale.

The practical heuristic is the rule of three: abstract a pattern when it has appeared about three times and looks stable, not before. Three uses prove it is real and reveal its true variations; stability means you are not abstracting a moving target. Before three, the more senior move is often to wait. Mastery includes the discipline to not build the component yet.

Build for adoption

A component becomes part of a system only when people can find it, trust it, and use it faster than rebuilding. That is an adoption problem, and you solve it with three unglamorous practices.

Documentation: each component needs a short note on what it is for, when to use it, and — crucially — when not to. The “when not to” prevents misuse more than any guardrail. Without docs, teammates guess, and guessing produces drift.

Versioning and communication: when you publish library changes, consumers get update prompts, but a silent breaking change erodes trust fast. Clear, small, well-noted releases keep people willing to accept updates instead of pinning old copies.

Friction reduction: people take shortcuts when the right thing is slower. If the library is well-organised, searchable, and the components are flexible enough via properties, using the system is the path of least resistance — and adoption takes care of itself. Watch the warning signs: a rise in detached instances or local copies is the system telling you it has friction somewhere.

Hands-on exercise

Take the components you have built and assemble a tiny library: publish at least one component, give it a real version, and write its documentation — purpose, properties, and an explicit do/don’t. Then make the senior decision in the other direction: identify one thing in your files you chose NOT to componentise, and justify it with the rule of three. The capstone deliverable is a small, documented, adopted-ready system plus that one written “we deliberately did not abstract this, because…” — proof you can wield restraint, which is what separates a master from a component factory.

Second case · a 'special' marketing card

The same lesson, a different object

Common failures · spot them fast

The failure gallery

Each of these is caught by a quality gate — keep the cheatsheet open while you work.

Worked example

See the journey

Cheatsheet

Reflection