Design systems — why consistency is a feature

A design system is a shared, reusable set of design decisions and the components that implement them — a defined color palette, a type scale (this domain's typography lesson), a spacing scale, and a library of consistent components (buttons, form fields, cards) used everywhere instead of being rebuilt slightly differently each time. It's the accumulated answer to "what should a button look like" and "how much space goes between sections," decided once and reused, rather than re-litigated on every new screen.

Design tokens are the atomic values everything else is built from — a named color (--color-danger: #A93B32) instead of a hardcoded hex value scattered across dozens of files, a named spacing value (--space-md: 16px) instead of a magic number repeated everywhere. Using tokens instead of raw values means a single, deliberate change (adjusting the danger color slightly) propagates everywhere automatically, instead of requiring a find-and-replace across an entire codebase and inevitably missing a few spots.

A product where every button looks and behaves the same way everywhere lets users transfer what they've learned from one screen directly to the next — they don't have to relearn "how do buttons work here" on every new page. This predictability is a real usability benefit, not just a matter of visual polish, directly connecting to the previous lesson's affordances and feedback: a consistent design system means those signals (what's clickable, what confirms success) work the same way everywhere a user goes.

A design system isn't only a design artifact — it's a real engineering efficiency win. A shared <Button> component with variants already handles accessibility (focus states, keyboard support), all the interaction states from the feedback lesson (hover, active, disabled), and consistent spacing — solved once, reused everywhere, instead of every new feature re-implementing (and re-testing, and re-debugging) its own version of the same button from scratch.

A well-designed system anticipates realistic variation — a primary button, a secondary button, a destructive (delete-style) button — as defined, intentional variants within the system, rather than every new screen inventing a bespoke one-off style whenever a slightly different look feels needed. The discipline worth holding onto: before creating a new one-off style, check whether an existing variant already covers the actual need.

A design system doesn't need to launch as a comprehensive, polished library — starting small (a handful of color and spacing tokens, one or two shared components extracted from real, already-built screens) and growing it organically as genuine repetition emerges is both realistic and effective. Over-investing in a large, speculative system before a product has enough real screens to know what it actually needs risks building the wrong abstractions — directly the same "not everything needs this much investment" caution the Software Engineering Fundamentals domain raises about RFCs and ADRs, applied here to design infrastructure instead of technical decisions.