A design system is the set of decisions you have already made, written down where other people can reach them. Components and patterns sit on top; underneath are the foundations — one type scale, one spacing scale, a colour ramp, motion — usually expressed as tokens like color-surface-raised. Skip the foundations and the components agree about nothing.
It is a contract between designers and engineers, so it has to exist on both sides: the same tokens and the same component names in the drawing file and in the code. One team on one surface can hold that agreement in their heads. Four teams shipping web, iOS and Android cannot — that is when a system starts to pay.
Build it from what ships, not from what you imagine shipping. Promote a pattern the third time someone needs it somewhere new — three uses by one team is that team's habit, three uses across three teams is a pattern. Components invented ahead of demand get maintained by everyone and used by nobody.
Give it an owner and a version. Owning it means reviewing what other teams contribute, publishing a changelog with each release, and retiring a component on an announced date with a named replacement rather than deleting it. An unowned system rots in a recognisable way — the shared library and the production code drift apart, and designers quietly detach instances because the drawn button no longer matches the real one. A system people have stopped trusting costs more than it saves.
- Design Handoffs — article
- Build a Design System - Full Course — video