Most design systems look their best on the day they're presented. Six months later, after the agency has gone and the team has doubled, half the components have been forked and nobody trusts the Figma library. We've inherited a few of those, and we've built a few that held up. The difference is rarely the quality of the components.
These four rules come from building a system for a product team of about forty engineers, and from watching it survive the handover.
Rule one: start from the product, not the library
We never begin with a list of components. We begin with the ten screens that matter most and pull out what they actually share. That usually means a few dozen components, not two hundred.
Everything else waits until it's needed twice. A system that only contains what the product uses is small enough to learn in a week, and small enough that people keep it up to date.
On the forty-engineer project, the first release had just over thirty components. A year later it has around fifty, and every one of them is used somewhere in the product. The number matters less than the habit behind it: nothing gets added on speculation.
Rule two: name things the way engineers search
If a developer can guess a token's name without looking it up, the system gets used. If they can't, they hard-code a hex value and move on. So we name tokens by role, not by appearance:
:root { --color-text: #141210; --color-surface: #f1ece4; --color-accent: #ff5b2e; --radius-control: 6px; --space-2: 8px;}"Accent" survives a rebrand. "Orange-500" doesn't. The same goes for components: a Banner that announces something is easier to find than a YellowBox.
Components follow the same idea. Props describe intent, such as tone="warning" or size="compact", rather than raw values, so a designer can change what a warning looks like without touching a single screen. And we keep the token list short on purpose: eight colours with clear jobs get used correctly; forty shades of grey get used at random.
Rule three: one source of truth, in code
The design file describes the system. The code is the system.
Figma and code will drift apart unless one of them is in charge. We put code in charge: tokens are generated from one file, components are documented next to their source, and the Figma library is updated from the coded version rather than the other way round.
- Tokens live in the repo and are exported to Figma
- Every component has a live example and a short "when not to use this"
- Visual regression tests catch accidental changes
- Deprecations come with a date and a replacement
None of this needs special tooling. A token file, a docs page per component and a screenshot test in CI cover most of it.
Rule four: hand over the people, not just the files
Documentation helps, but systems survive because someone inside the team feels responsible for them. Before we leave, we pair with two or three of the client's engineers and a designer until they've shipped changes to the system on their own.
We also leave a short contribution guide: how to propose a component, who reviews it and how long that should take. Without one, every new component turns into a negotiation, and people quietly build their own.
The best sign that a handover worked is a boring one: a pull request to the system from someone we've never met, reviewed by someone we paired with, merged without us.
The short version
Start from real screens, name things the way people search, make code the source of truth, and hand the system to people rather than to a repository. A design system survives handover when it's small, obvious and owned.