design-systemslisted

# Design Systems > A design system is a product whose users are other engineers > and designers. Treat it like one: roadmap, deprecation policy, > documentation, SLA on bug fixes, telemetry on adoption. Do less > than that and it becomes a maintenance graveyard the platform > team is too embarrassed to admit was a strategic mistake. ## Purpose A design system is the load-bearing infrastructure of consistent product experience: design tokens (the atoms — colour, type, space, motion, elevation), components (buttons, inputs, navs, modals — the molecules and organisms), patterns (canonical solutions for common problems), and the documentation + governance that keeps them in sync across web, mobile, marketing, internal tools, and partner integrations. Done well, a design system collapses cross-team coordination cost, accelerates new feature development, makes accessibility automatic, and keeps brand expression coherent across years of organisational change. Done poorly, it becomes a fork — your design system or the shipping product, choose one. This skill names the architecture (tokens → components → patterns), the API design discipline for components, the multi-platform theming model, the governance + contribution patterns, the versioning + deprecation lifecycle, the documentation that makes the system usable, and the adoption telemetry that turns "we shipped a design system" into "the product is built on it." NOT in scope: research methods that surface what to design (see `