Design Systems

What it is

A design system is a shared, documented library of components and rules that keeps a product consistent as several people work on it. It is part component code, part visual standard and part agreement about who may change what. The component library is only the visible half; the hard half is governance and adoption.

Why it matters

Consistency decays the moment a second person designs a screen. Buttons drift, spacing drifts, and within a year the product looks assembled from three different products — which readers interpret as unreliability. A system fixes this at the source, and it pays for itself when the same patterns are needed in more than one place and by more than one person. It is also the only way small teams get the speed benefit of reuse rather than the cost of re-deciding everything.

In this track

  1. When a system pays for itself (03-design-ux/32-design-systems/01-when-a-system-pays-for-itself) — the conditions under which the investment returns, and when it does not.
  2. Component API and documentation (03-design-ux/32-design-systems/02-component-api-and-documentation) — choosing the interface of a component and writing down what it is for.
  3. Governance and versioning (03-design-ux/32-design-systems/03-governance-and-versioning) — who may change the system, and how a change reaches every product.
  4. Adoption inside a team (03-design-ux/32-design-systems/04-adoption-inside-a-team) — the work of getting people to use it, which is where most systems fail.

Prerequisites

Go deeper