Design Systems as Craft Infrastructuretokens, components, patterns

A design system is collective craft: craft that has been externalised, structured, and made available to practitioners who were not part of the decisions that produced it. The question moves from how this designer makes something well to how any designer on the team can, consistently, without rediscovering everything that has already been learned.

The vocabulary of design systems (tokens, components, patterns) maps onto a hierarchy of abstraction older than product design itself. Brad Frost’s formulation, building on Christopher Alexander’s concept of design patterns, sets out the levels: atoms (the smallest design decisions, colour values, type scales, spacing increments), molecules (combinations of atoms with a specific function), organisms (complex assemblies), then templates and pages.¹

Alexander’s pattern is a recurring solution to a recurring problem in a specific context, a relationship of context, problem, and solution that becomes a shared language once it is named.²

Alexander was specific about this: a pattern that exists only in a practitioner’s mind dies with their tenure. A pattern that has been named can be discussed, compared, and improved by anyone who inherits the system. Without the name, each practitioner rediscovers the solution alone, which is exactly the failure that design systems exist to prevent.

Tokens are where the design system’s craft accountability lives most clearly. A token is a value with a label that carries its meaning. “spacing-04” holds 16px (or 1rem) and places it at step 04 of a defined scale. Call it that, and a developer reading it six months later can see why the space is there. Call it “button-left-margin” instead, and that same developer sees only the value, with no way to know whether it is still right.