Design systems have become a standard deliverable, and like most standard deliverables, many of them exist mainly to be delivered. A library of components is handed over, admired, and slowly abandoned as teams find it faster to build what they need than to find it.
Start with the decisions, not the components
A button is not the interesting part. The interesting part is the decision behind it: how many kinds of action a screen can have, which one is primary, what happens when an action is destructive or unavailable. Once those rules exist, the button almost designs itself.
We begin a system by collecting the decisions a product keeps making inconsistently. Spacing, type sizes, form behaviour, empty states, error messages. Each one becomes a rule before it becomes a component.
Tokens connect design and code
Design tokens are named values for colour, type, spacing, radius and motion, shared between design files and code. When a brand colour changes, it changes in one place and flows everywhere.
The names matter more than the values. A token called "blue 500" says what the colour is. A token called "text on primary action" says what it is for, which is what a designer or developer needs to know when choosing it.
Document the reasons
A component without guidance invites misuse. Every entry in a system should say when to use it, when not to, and why. The why is what lets someone make a good call in a situation the system did not anticipate.
Real examples help more than rules. A pair of screens, one right and one wrong, settles most arguments faster than a paragraph.
Build it in code, not only in Figma
A system that exists only in a design tool is a picture of a system. The real one is the code that ships. When design components and code components match in names, properties and behaviour, designers and developers speak the same language and handoff becomes a conversation instead of a translation.
Accessibility belongs at the source
Contrast, focus states, keyboard behaviour and screen reader labels are easiest to get right once, in the system, than repeatedly on each screen. A team using accessible components gets most of that work for free.
Plan for how it changes
Products change, and a system that cannot change becomes a constraint people route around. Someone needs to own it, there needs to be a simple way to propose additions, and changes need versions and release notes like any other software.
A design system is working when teams choose to use it because it is the quickest way to build something good.
