Somewhere between the approved design and the live website, the brand blue has acquired three cousins.
The main button is right. The contact form is close. The footer appears to have pursued an independent creative career.
This happens when design decisions travel as individual values copied into different places. A designer updates the palette, a developer changes a stylesheet and a page editor picks the nearest-looking swatch. Nobody has done anything particularly outrageous. The website still ends up arguing with itself.
Give design decisions one shared home
Design tokens offer a practical way to connect those decisions. They give colors, typography, spacing and other repeatable choices shared names and values that tools and code can use.
On October 28, 2025, the Design Tokens Community Group published its first stable specification, version 2025.10. That creates a common exchange format for tools implementing it. It is a community-group report, not a W3C Recommendation, and it does not automatically connect a design file to a WordPress theme.1
The interesting opportunity is what a team builds around that shared language.
Name the job, then choose the value
A color named “blue-500” describes a palette entry. A name such as “primary-action-background” describes a job. Both can be useful, with the functional name pointing to the appropriate palette value.
That distinction matters during a rebrand. Perhaps the business changes its primary action from blue to orange. Updating a raw blue value everywhere could also change information panels or decorative illustrations that should stay blue. Updating the action role gives the team a more precise decision.
Custom WordPress themes are our bread and butter. See our WordPress services.
The same thinking applies to spacing. A section gap, card padding and button height are different choices, even when two happen to share a measurement today. Treating every matching number as the same design decision can turn a small adjustment into a surprisingly sociable problem.
I would begin with the values that repeat across the actual site. A small business website usually needs a useful vocabulary before it needs an encyclopedia.
Bring the tokens into the WordPress theme
For WordPress, theme.json can hold shared settings and styles for the editor and front end. A custom theme can use those presets, while custom blocks and other components need to be built to consume the appropriate values. An ACF field that lets an editor choose a button style should map to those defined roles, rather than introduce another unrestricted color picker.3
That mapping takes implementation work. A DTCG-format token file and theme.json serve different purposes. They need a deliberate conversion or build process, or a clearly maintained manual mapping. Renaming a file does not establish a design system, although it is satisfyingly quick.
There are also states to account for. A button needs readable text, an obvious focus treatment and appropriate hover and disabled appearances. Sharing its default background color alone leaves most of its behavior undecided.
If this was useful, try A custom WordPress theme needs a small design system.
Check a real page before calling it done
Before calling the connection finished, compare a real page in the editor with its published version. Include a form, an error message, a long heading and a smaller screen. The goal is agreement where people actually use the website.
The payoff is a calmer relationship between design and development. A brand adjustment has an identifiable home, components know which values to use, and editors get sensible choices.
The specification helps tools exchange the ingredients. A thoughtful theme still has to cook dinner. Ideally, without each button bringing its own blue.