Resources
Component systems and design tokens
A component system gives an organisation one single definition per interface element: a button, a colour value, a type scale. It saves time, and above all it holds consistency over time.
One value, one place
A design token names a decision — the accent colour, the base spacing, a corner radius — and declares it once. Everything using it refers to it by name. The day the accent changes, it changes everywhere, in one edit. Conversely, the same colour copied into several components produces a family of near-identical shades that reads like a printing error: the system exists precisely to make that divergence impossible.
- One token per decision: colour, spacing, radius, type scale
- One component per interface element, with all its states documented
- Documentation showing the intended use and the matching code
- A semantic name rather than a raw value, everywhere the component is used
- A single source for design and for development
What the system brings to each craft
To the designer
Time spent on structure rather than on redefining a button already drawn three times.
To the developer
A mock-up written in token names transposes directly, with no colour-picking measurements.
To the brand owner
A brand update ships in one edit and is verified across every surface.
To the whole team
A shared vocabulary. Reviews then focus on choices rather than on styling discrepancies.
Building a system in four stages
- 01
Inventory what exists
Listing the buttons, colours and spacings actually in use gives the measure of the job.
- 02
Name the decisions
Each retained value gets a name stating its role, never its appearance: accent, surface, border.
- 03
Build the library
One component at a time, with its states and a usage example. Documentation is born with the component.
- 04
Lock it with a check
An automated check forbids reintroducing a raw value: that is what makes the system hold.
Questions about the system
At what size does a system become useful?
As soon as the same interface element exists on two screens designed by two different people. A system starts perfectly well with ten tokens and five components: what matters is the single source, not the library's size.
Who keeps the library current?
Whoever adds a component documents it at the same time: documentation is born with the component rather than after it. Design review checks that point, exactly as code review checks the tests.
How should a token be named?
By its role in the interface — accent, surface, border, secondary text — never by its value. A name stating the role survives a brand change, whereas a name stating the colour becomes wrong the day the colour changes.
Explore next
- Writing for the webWeb writing techniques: information first, headings that answer, short sentences, the words readers use, clear calls to action.
- Search visibilityKeyword research, answering content, technical optimisation and internal linking: the organic search method applied to a small company.
- Online advertisingAuction mechanics, audiences, ad creative, daily budget, attribution and acquisition cost: running a measurable campaign.
- Community managementEditorial line, realistic calendar, phone-shot content production, moderation, handling sensitive situations and a measured monthly report.
- Customer journeySegmentation, targeting, positioning and value proposition: building an accurate message and placing it at the right moments in the purchase journey.
- AI and decisionsFraming a use case, estimating an AI project's full cost, defining real-usage indicators and setting an internal policy: the decision-maker's skills.