Author: Sophie Davis

Managing brand tokens across six client accounts simultaneously is, to put it plainly, a nightmare without the right tooling. Colours drift between Figma files and code, spacing scales get hard-coded into components by a developer who never saw the original spec, and then a rebrand lands and you’re hunting through three separate codebases trying to find every instance of #1A73E8. I’ve been there. Most UK agency frontend teams have. The fix, as of 2026, is a properly configured Style Dictionary pipeline, and this walkthrough covers exactly how to set one up in a way that actually survives contact with real client work.

What Style Dictionary actually is (and why it’s not just a JSON file)

Style Dictionary, built by Amazon and maintained as an open-source project, is a build system that takes your design tokens, defined as structured JSON or JavaScript objects, and transforms them into whatever output format a given platform needs. That means CSS custom properties for your web builds, Swift variables for an iOS team, XML for Android, Sass maps if your project is still on that, and so on. All from a single source of truth.

The critical word there is transform. Style Dictionary’s real power isn’t storage, it’s the transform pipeline. You define what your tokens mean at an abstract level, then the tool handles the mechanical conversion to whatever format a developer, app team, or platform actually consumes. For a UK agency juggling, say, a fintech rebrand alongside a heritage retail brand and a B2B SaaS product, this is the difference between a design system that scales and one that quietly collapses under the weight of one-off overrides.

Structuring your token files for multi-client agency work

The folder structure is where most teams go wrong out of the gate. The temptation is one flat JSON file per client. Resist that.

A structure I’ve settled on, after several iterations across agency projects, looks like this:

tokens/
  global/
    color.json
    spacing.json
    typography.json
  clients/
    acme-corp/
      color.json
      brand.json
    northfield-retail/
      color.json
      brand.json
config.js

The global layer holds your primitive tokens, raw values like blue-500: #2563EB or space-4: 16px, that have no semantic meaning yet. Client folders hold semantic tokens that reference those primitives: color.brand.primary: {value: "{color.blue-500}"}. This layering means that when Acme Corp decides their primary colour is now teal, you change one line in one file. Nothing downstream breaks unless you want it to.

Style Dictionary’s reference syntax, the curly-brace notation, handles that aliasing natively. It resolves chains of references, so button.background can point to color.brand.primary which points to color.blue-500, and the final build output will resolve all the way down to the hex value. Tidy.

Configuring the build for Figma handoff and CSS output

The config.js file is where you wire everything together. Here’s a stripped-down but real example for a web-first client project:

module.exports = {
  source: [
    'tokens/global/**/*.json',
    'tokens/clients/acme-corp/**/*.json'
  ],
  platforms: {
    css: {
      transformGroup: 'css',
      prefix: 'acme',
      buildPath: 'dist/acme-corp/',
      files: [{
        destination: 'tokens.css',
        format: 'css/variables'
      }]
    }
  }
};

Running style-dictionary build against this spits out a CSS file full of custom properties prefixed with --acme-, which you then import into your component library or bundle. Dead simple on the surface, but that prefix is crucial in an agency context because you can import multiple clients’ token files in a demo or shared environment without collisions.

For Figma specifically, the handoff story has improved considerably in 2026. The Figma Tokens plugin and its successor integrations can read from a GitHub-hosted JSON file, meaning your single source of truth in the repo stays synchronised with what designers see in Figma. When a designer updates a spacing value in Figma’s token panel, a pull request is opened. When a developer merges it, the CSS rebuild runs. That’s the loop you want. I’d strongly recommend reading up on the current state of Figma’s Dev Mode before setting this up, because how your tokens surface in Dev Mode inspects has changed meaningfully this year.

Custom transforms for UK-specific needs

Out of the box, Style Dictionary’s CSS transform group handles most scenarios. But UK agency work throws up a few edge cases worth building custom transforms for.

Fluid typography is a common one. If you’re using clamp() values for your type scale (which you should be, if you aren’t already), you’ll want those as computed strings rather than raw pixel values. You can register a custom transform that takes a min, max, and viewport range from a token’s attributes and outputs a proper clamp() string. Something like:

StyleDictionary.registerTransform({
  name: 'size/fluid',
  type: 'value',
  matcher: token => token.attributes.fluid,
  transformer: token => {
    const { min, max, minVw, maxVw } = token.original.attributes;
    return `clamp(${min}px, calc(${min}px + (${max - min}) * ((100vw - ${minVw}px) / (${maxVw - minVw}))), ${max}px)`;
  }
});

That’s one registration, and every fluid type token across every client build uses it consistently. This kind of thing compounds nicely, especially once you have four or five custom transforms covering your agency’s standard patterns.

Colour token naming is another area where getting the structure right early pays off enormously. If you’ve read our piece on colour token naming and contrast grids, you’ll know the semantic layer matters more than the primitive layer for day-to-day developer use. Style Dictionary makes enforcing that semantic naming convention in your JSON schema straightforward, because the dot-notation in your token paths maps directly to CSS custom property names.

Running this across multiple clients without losing your mind

The multi-client setup needs a build script, not just a single Style Dictionary config. I use a small Node script that iterates over a clients/ directory, dynamically generates a config for each client by merging global tokens with client-specific overrides, and runs a build. The output is a dist/ folder with one subdirectory per client, each containing their own token CSS file, ready to be consumed by whatever frontend stack that project runs on.

This scales. I’ve run this against eight simultaneous client configs in under four seconds on a modest laptop. For a UK agency doing quarterly brand refreshes and annual rebrands, that turnaround matters.

Version control is non-negotiable here. Every token change goes through Git, with a meaningful commit message, so you have a full audit trail of when a colour changed and why. This is useful not just for debugging but for client conversations: “your brand primary changed on 14 March, here’s the commit.” Clients, especially those in regulated industries, appreciate that level of traceability.

For a sense of the broader landscape that UK product teams are operating in, the government accessibility requirements for websites and apps are worth keeping in your peripheral vision, particularly when your token system needs to account for WCAG contrast compliance across multiple brand palettes.

Connecting your token system to the wider product workflow

A token pipeline doesn’t live in isolation. It touches your component library, your Storybook instance, your CI build, and your Figma workflow. Getting those connections right is as important as the Style Dictionary config itself.

One pattern I’ve seen work well at UK agencies is hooking the Style Dictionary build into a GitHub Action that fires on any change to the tokens/ directory. The action builds the tokens, commits the updated CSS to a dist branch, and optionally publishes to npm if the component library consumes tokens as a package. The whole thing runs in under thirty seconds. Developers get updated tokens without touching the config themselves, and designers don’t need to manually sync anything.

If your agency also runs paid media for clients alongside the design work, the same discipline around structured, auditable systems applies. Agencies like dijitul Marketing bring that kind of systematic rigour to campaign management, which is a useful parallel: structured inputs, predictable outputs, traceable decisions.

The token system also connects naturally to your test data story. If you’re prototyping UI states with realistic data, as covered in our walkthrough on using Faker.js and seed scripts to replace lorem ipsum, having your design tokens already resolved means your component demos use real brand colours and spacing, not placeholder guesses. The whole system starts to feel coherent rather than cobbled together.

The things that will still trip you up

A few honest gotchas, because no walkthrough should pretend this is frictionless.

First, circular references. If token A references token B which references token A, Style Dictionary will throw an error at build time. That’s the right behaviour, but it means you need to be disciplined about your token graph. Primitives never reference semantics. Semantics reference primitives. Components reference semantics. One direction only.

Second, token naming conventions need team buy-in. If one designer names something color.ui.button.primary and another names it button.primary.color, your JSON will become incoherent fast. Document your naming convention in your repo’s README on day one. Enforce it in code review.

Third, the Figma plugin ecosystem for token sync is still more fragmented than it should be in 2026. Test your chosen plugin against a real client file before committing to it as your agency standard. Some plugins handle nested token groups cleanly; others flatten everything and lose the hierarchy that Style Dictionary depends on.

None of these are deal-breakers. They’re friction points that good setup decisions eliminate early. Get the folder structure right, document the naming convention, and the pipeline genuinely does become the boring, reliable infrastructure it should be.

Frequently Asked Questions

What is Style Dictionary and how does it work with design tokens?

Style Dictionary is an open-source build system that takes design tokens defined as JSON and transforms them into platform-specific outputs, such as CSS custom properties, Swift variables, or Sass maps. You define tokens once and the tool handles the conversion, meaning one source of truth serves every platform your product ships on.

How do I manage multiple client brand systems with a single Style Dictionary setup?

The recommended approach is a layered folder structure: a global layer for primitive tokens (raw colour values, spacing scales) and per-client folders for semantic tokens that reference those primitives. A build script iterates over client directories and generates a separate token output for each, so there’s no collision between brand systems.

Can Style Dictionary output tokens that Figma can read?

Yes. Style Dictionary’s JSON output can be consumed by Figma token plugins, with several integrations supporting a GitHub-hosted JSON file as the sync source. When a designer updates a token in Figma, the change opens a pull request; when merged, the Style Dictionary build runs and updates the CSS. It’s not entirely frictionless yet, but it works reliably for most agency setups.