Digital products ·
A design system begins with a repeated decision
A design system is not a separate file full of buttons. It turns repeated decisions into a shared product language and lets the interface evolve without visual and technical drift.
Repetition comes first
A design system does not begin with a colour palette or a component library. It begins when the same decision has to be made again: which spacing to use, how to show an error, what a button does while loading, or how an empty card behaves. A small product can hold those answers informally. As it grows, memory stops being a reliable system.
The first step is therefore an inventory of the actual interface. Gather screens and states, find similar elements, mark contradictions and distinguish meaningful differences from accidental ones. This creates rules grounded in the product as it exists while revealing where it needs to become more consistent.
Tokens preserve relationships
Colours, type, spacing, radii and shadows can be stored as named tokens shared by design and code. A list of values alone is not enough. Names need to express purpose: primary text, surface background, critical action, compact spacing. A change of theme or scale can then travel through the product without searching for a particular hex value or number.
A useful token set often has layers. A base layer holds raw values, a semantic layer gives them a role, and a component layer narrows their use. The structure asks for discipline, but it makes change predictable. Names such as “grey-3” or “space-18” leave the meaning in individual people’s heads.
A component is behaviour
A button in a library is more than a rectangle and a label. It has size, priority, hover and keyboard focus, loading and disabled states, and a response to long text. An input needs a label, guidance, validation, required state and autofill behaviour. A component becomes useful when it covers a complete scenario rather than a perfect still image.
Not every repetition deserves a universal component. Designing for every imagined variation creates a thicket of options that is harder to use than the original interface. I prefer to extract a component after several real repetitions, when its stable core and genuine exceptions are visible.
Content belongs in the system
Interfaces also drift through language. The same action may be labelled Save, Done and Apply, while error messages alternate between useful guidance and dead ends. A design system should therefore define naming principles, heading limits, the tone of guidance and the structure of messages for common states.
Accessibility and localisation belong here too. Contrast, focus order, assistive labels and enough room for translated copy cannot be bolted on after implementation. They affect the component’s structure. When they form part of its contract, each new screen inherits them by default.
Design and code must meet
A library in a design file and a separate set of code components can easily drift apart. A designer changes an input height while the implementation keeps the old one; documentation introduces a state that the product cannot render. Shared names, explicit states, examples and a clear change process keep the two sides connected.
The system should be tested through a real journey. Compose a screen from library elements, implement it and compare the behaviour as well as the appearance. This quickly exposes missing states and rules that are too abstract. Corrections then return to the source of the system instead of being patched into individual screens.
The system needs an owner
Without ownership, a library slowly becomes an archive. Someone must review new components, resolve exceptions, protect accessibility and decide when an old variant can be removed. It may be one person or a small group, but the responsibility needs to be visible.
Useful documentation answers three questions: when to use an element, how it behaves and when it is the wrong choice. A long catalogue of properties rarely helps anyone make a decision. A short example, an edge case and a link to the implementation are more valuable. Documentation stays close to the work and changes with the component.
When a design system earns its place
A complete system may be excessive for a small campaign page. It becomes worthwhile when a product has many screens, several user roles, frequent change or parallel design and development work. Its effect is measured through faster coherent changes and fewer accidental variants, not by the number of components in a catalogue.
I begin digital product work with its logic and real journeys. When repetition is already slowing development, the Method builds a minimal design system alongside the interface and its code. That keeps the system attached to the product instead of turning it into a decorative project of its own.
From an idea to a digital product
If the task calls for a service or internal tool, we can define the first complete journey and a path to a working release.