Design systems that stop the drift.

• Build a design system when more than one person builds the interface.

  Two designers, two developers, or an agency and an in-house team. The moment consistency depends on people remembering conventions rather than reading them, a system pays for itself.

• Build one when the product will keep growing.

  If screens will still be added in two years, the system is what makes those screens cheap. If the product is finished at launch, the case is much weaker.

• Skip it when the site is small and static.

  A handful of pages built once by one person does not need governance, contribution rules or a component catalog. Tokens and a short set of conventions are the proportionate version.

• Start with UI/UX design when the screens themselves are wrong.

  A system makes an interface consistent, not correct. Where the structure and the flows are the problem, design those first and extract the system from the result.

Four layers and their documentation: tokens holding each raw decision, components with every state defined, patterns combining those components, and rules stating which to use when. Around them sit accessibility criteria, responsive behavior, content and labeling conventions, and a named owner who keeps the whole thing current.

The list below is the usual inventory rather than a fixed package, and the scope is set by what the product actually contains. A system for a marketing site and a system for an application with roles, tables and dense filters are different sizes of job, and pretending otherwise is how a system ends up half-built.

• Typography: the scale, weights, line heights and measure, with a rule for each level.
• Color: roles rather than swatches — surface, body, muted, border, accent, status — each with verified contrast pairings.
• Spacing and layout: one spacing scale, the container widths, the grid and the breakpoints.
• Controls: buttons, inputs, selects, checkboxes, radios and switches, with every state each one has.
• Surfaces and structure: cards, dialogs, navigation, tabs and tables.
• States: hover, focus, active, disabled, loading, empty, error and success.
• Accessibility criteria per component: focus visibility, labeling, target size and contrast.
• Motion: duration and easing tokens, plus the reduced-motion behavior for each effect.

Design tokens are named values that hold a design decision in one place: a color role, a type size, a spacing step, a radius, a duration. Components reference the name rather than the value, so changing the value changes every place that uses it and none of them can drift.

The important word is role. A token named for its purpose — a body text color, a border color, a raised surface — can be reassigned when the design changes. A token named for its appearance cannot, and a system full of those is a palette with extra steps.

Tokens are also what makes theming and brand alignment tractable. If a marketing site and a product both reference the same named roles, aligning them is a values change rather than a redesign.

By deciding who owns it, how somebody adds to it, and how the product consumes it — before it is built. Most abandoned systems were not bad systems. They were unowned ones: nothing updated them when the product moved, so building from them became riskier than copying the last screen.

Three things keep a system alive in practice. It has to be genuinely easier to use than to bypass, which is a documentation and ergonomics problem rather than a discipline problem. It has to have a route for adding the component somebody needs today, or that component gets built outside the system and never comes back. And somebody has to be accountable for it, with the time to be.

We agree those three before the first token, and hand over the process alongside the components. A system delivered without them is a snapshot, and snapshots age.

Usually not, and a system sold into that situation is overhead. A handful of pages built once by one person needs a token set and a short list of conventions, not governance and a component catalog. The threshold is more than one builder, or a product that will keep being extended.

The honest version of the argument is about where the cost lands. A design system is paid for up front and returns its cost across screens built later. If there are no later screens and no second builder, the return never arrives, and the proportionate deliverable is a token file plus interface designs.

Where that is the right answer, we say so and scope the smaller job. It is the same reasoning that puts a UX audit ahead of a redesign: the cheaper intervention first, where the cheaper intervention is what the situation actually needs.

• Design systems
• Design tokens
• Component systems
• Pattern libraries
• System documentation and governance

A design system is layered, and each layer is assembled from the one below it. That is what makes the work compound: a decision taken once at the bottom is inherited by everything above it, rather than being re-taken on every screen.

• The next screen is cheaper than the last

  Assembly replaces invention. The cost curve of adding to the product bends downwards instead of upwards, which is the entire commercial case for a system.

• One change, everywhere

  A decision held as a token is changed in one place. Without tokens, a brand color change is a search through a codebase and a set of screens, and some of them get missed.

• Consistency survives new people

  A developer or designer joining in month eighteen has something to build from. Consistency stops depending on who remembers the conventions.

• Accessibility is decided once

  Focus treatment, contrast and target sizes live in the component rather than in each use of it, so the accessible version is also the default version.

• A product that grew past its own conventions

  Several years of features, several designers, and an interface that has stopped agreeing with itself. The work is to extract the system that is implicitly there and then fix what it reveals.

• A long build starting now

  Where a product will be built over months and extended for years, tokens and components come first so the later screens are assembled rather than negotiated.

• Several products, one company

  A marketing site, an application and a customer portal built by different people at different times. A shared token layer is what makes them read as one organization.

• Tokens as plain CSS custom properties, so they work in any framework and add no runtime cost to the page.
• Components specified by behavior and state, not only by appearance, because appearance is the part that survives a handover unaided.
• Semantic markup inside every component: real buttons, real links, real labels, real tables, real headings.
• Responsive behavior defined per component, so a page is not a special case at each breakpoint.
• Accessibility criteria attached to the component: focus visibility, contrast pairing, target size and labeling.
• Motion held as duration and easing tokens rather than chosen per animation, and always respecting a reduced-motion preference.
• This site is built the way this page describes: design tokens as CSS custom properties in one file, and a fixed inventory of reusable blocks that every page is assembled from.