Colour decisions in product design look deceptively simple until your rebrand lands, someone switches to dark mode, and your carefully chosen palette turns into a contrast disaster that fails WCAG AA at about twelve different points. I’ve watched this happen to teams who thought they had a proper colour system, only to discover they had a colour list with a system-shaped name badge on it. There is a meaningful difference, and design system colour tokens UK teams are increasingly using to close that gap are finally mature enough to be worth writing about seriously.
What a real semantic colour token system actually looks like
The core idea is layered naming. You have primitive tokens at the bottom: raw values like blue-500: #2563EB. Above that sit semantic tokens that describe function rather than appearance: colour-interactive-default, colour-surface-elevated, colour-feedback-error. The primitive never goes directly into a component. The semantic token does. The layer in between is where the magic happens, because when a rebrand requires swapping blue-500 for teal-600, you change one reference and everything that consumes colour-interactive-default updates automatically.
This three-tier approach, often called primitive, semantic, and component-level tokens, has been championed by Salesforce’s Lightning Design System for years, but UK product teams have been slower to adopt it fully. Part of that is legacy: many British SaaS companies built their design systems before design tokens were a coherent concept, and the technical debt of retrofitting a flat Sass variable file into a structured token architecture is real. The other part is that tooling only recently caught up.
Why naming conventions matter more than most teams realise
Here’s where I’d argue most colour system conversations go wrong. Teams spend weeks debating whether blue-500 should be #1D4ED8 or #2563EB, and approximately twenty minutes on naming conventions. Then they ship tokens with names like primaryBlue, brandGreen, and accentColor1, which are essentially useless the moment a new designer joins or the brand team decides teal is the new blue.
A robust naming convention is schema-first. The structure I’ve seen work best in UK teams follows: [namespace]-[category]-[property]-[variant]-[state]. So ds-colour-text-primary-hover instead of textHoverMain. The namespace scopes the token to your system and prevents collisions if you’re working in a monorepo with multiple products, which plenty of UK B2B companies are. Category and property describe what the token affects. Variant and state handle the stuff that trips everyone up: default versus disabled, rest versus hover versus focus.
The W3C Design Tokens Community Group published their format specification to standardise how tokens are stored and transferred between tools. It’s not a finished standard yet, but it’s close enough that Figma’s variables implementation and Style Dictionary both align with it reasonably well. If you’re building a token system in 2026 and not at least glancing at that spec, you’re probably building something you’ll have to rebuild in two years.
Contrast grids: the tooling that makes WCAG compliance tractable
WCAG 2.1 AA requires a contrast ratio of 4.5:1 for normal text and 3:1 for large text and UI components. WCAG 2.2, which the UK public sector accessibility requirements point to for public sector digital services, doesn’t change those ratios but adds a clearer expectation that you’ve done the work systematically. The problem is that checking every foreground-background combination manually is genuinely tedious. A palette with twelve colours has 66 unique pairs. If you’re also considering dark mode, you’ve effectively doubled your matrix.
Contrast grids, popularised by Eightshapes’ free tool, solve this by visualising the entire foreground-background matrix at once. You input your palette, and the grid shows every combination colour-coded by whether it passes AA, AAA, or fails entirely. This is enormously useful not just for compliance checking but for making design decisions. When you can see that your neutral-700 passes AA on both your surface-primary and surface-secondary but fails on surface-tertiary, you can encode that constraint directly into your token documentation rather than waiting for it to surface in a QA pass.
Several UK product teams I’m aware of have started integrating automated contrast checking into their CI pipelines using tools like @accessibility-checker/contrast or custom scripts built on the wcag-contrast npm package. The idea is that a token file change that introduces a failing combination gets flagged in the pull request before it ever reaches a designer’s screen. That’s the right direction. Catching contrast failures at the system level rather than the component level is much cheaper to fix.
Dark mode is where token systems either prove themselves or collapse
Dark mode is the stress test every semantic colour token system has to pass eventually. If you’ve built a flat system where components reference primitive values directly, implementing dark mode means touching every component. If you’ve built a properly layered system, dark mode is just a second theme file that remaps your semantic tokens to different primitives.
In practice, this looks like having two sets of semantic token values: one for light mode, one for dark. colour-surface-primary maps to neutral-100 in light and neutral-900 in dark. A CSS custom property implementation handles the swap via prefers-color-scheme or a data attribute on the root element. Style Dictionary can output both token sets as separate CSS files or as a single file with media query scoping.
Where teams go wrong is assuming their colour palette works symmetrically in both modes. It almost never does. A contrast grid for your dark mode token mappings is not optional; it’s a separate exercise from your light mode grid, because the contrast ratios change when you flip surfaces. I’d recommend running both grids simultaneously when you’re building out a dual-mode system, and locking the acceptable pairings into your token documentation so that designers can’t accidentally use colour-text-secondary on colour-surface-overlay just because it looks fine in one mode.
This connects directly to work happening at the component level too. If you’re already thinking carefully about how CSS container queries are reshaping component architecture for UK frontend teams, it’s worth considering how your colour token layer interacts with component-scoped theming. A component that can respond to its container’s size should probably also respond to a locally-scoped theme token rather than relying solely on document-level custom properties.
Surviving a rebrand with a token system intact
Rebrands are where semantic token systems pay back every hour of upfront investment. The UK financial services sector goes through brand refreshes constantly, and I’ve seen what happens to design systems that were built around hex values rather than token references. It’s not pretty. Months of find-and-replace work, inevitably inconsistent across products, with rogue legacy values lurking in edge cases until someone files a bug six months later.
A token system handles this cleanly. Your primitive tier changes. Your semantic tier doesn’t. Your components certainly don’t. If your new brand blue is #1A56DB instead of #2563EB, you update one value, run your contrast grid to confirm nothing broke, and ship. That’s the whole thing.
Teams building more complex multi-brand or white-label products need to go one level further. Rather than a single primitive-to-semantic mapping, they maintain multiple primitive tiers (one per brand) that all map to the same semantic layer. This is the approach used in sophisticated public sector design systems, and it scales well into the kind of multi-tenant SaaS architecture where a single codebase serves several clients with different brand guidelines.
The toolchain that makes this tractable in 2026 is roughly: Figma variables for design-side token management, Style Dictionary for transformation and output to CSS, JSON, Swift, Kotlin or whatever your platforms need, and a contrast grid check baked into your release process. None of these tools are particularly new. The difference is that they now work well together, and the naming conventions are stable enough that a token defined in Figma actually means the same thing when it emerges from Style Dictionary on the other side.
If you’re also thinking about how design system decisions affect the designer-developer handoff, the current state of Figma’s Dev Mode is relevant here; token visibility in dev mode has improved substantially, and a well-structured token system makes the handoff cleaner regardless of which side of the gap you’re on.
The teams doing this well right now are not necessarily the largest UK product organisations. Some of the most rigorous colour token work I’ve come across is happening at mid-size British fintechs and healthtech companies where the contrast requirements are non-negotiable and the rebrand cycle is fast. Necessity, as always, is doing most of the architectural work.