Design systems are sold as inevitable and are often premature. Built too early they are overhead; built too late every screen looks like it came from a different company. The skill is recognising the moment.
The signals that you need one
- The same button exists in five slightly different sizes across your product.
- A colour change requires hunting through files nobody can enumerate.
- New hires ask which of three patterns is correct, and nobody is sure.
- Design and engineering argue about spacing in every review.
One of these is normal. Three of them means the inconsistency is now costing more than the system would.
What a useful system actually contains
Tokens first. Colour, spacing, type scale and radius as named values rather than raw numbers. This layer delivers most of the benefit and takes the least effort. Changing a brand colour becomes one edit instead of an archaeology project.
Components second, and only the ones you use repeatedly: buttons, inputs, selects, cards, modals. Building a component nobody has needed yet is speculative work.
Rules third. Not a hundred pages of philosophy, but the handful of decisions people keep relitigating: how forms report errors, how loading is shown, how destructive actions are confirmed.
Why most systems are abandoned
The usual failure is that the system becomes a separate product with its own backlog, drifting away from what shipping teams actually need. The moment it is easier to build a one-off than to use the system, it is dead.
The second failure is documentation as the deliverable. A beautiful site describing components that engineers do not import is decoration. The system has to live in the codebase people work in.
Start smaller than feels right
Extract tokens from what you already have, then convert the three most-used components. Ship it. Add the next component when a real screen needs it. A system grown from real usage survives; one designed in advance from an imagined component library does not.
Bilingual is a system concern
If you serve Arabic and English, direction belongs in the system, not in individual screens. Components built on logical properties mirror correctly everywhere at once. Retrofitting this later means touching every component you own, which is precisely the cost a system exists to avoid.
Frequently asked questions
Should we adopt an off-the-shelf system?
For internal tools, often yes; the consistency matters more than the distinctiveness. For a customer-facing brand, an off-the-shelf system makes you look like everyone else using it.
Who should own it?
Someone with shipping responsibility, not a dedicated team insulated from delivery. Systems maintained by people who use them daily stay useful.
