Design Principles That Improve Design Tokens

Many product teams treat design tokens like they’re a designer problem. They’re not. They’re a systems thinking problem that impacts shipping velocity, brand consistency, and whether your engineers want to strangle someone when they need to update a button colour across 47 components.

Design tokens don’t sound exciting. They sound like the sort of technical minutiae you can safely ignore until you’ve got “real problems” to solve. That’s exactly backwards. Design tokens are the foundation that determines whether your team can move fast or gets bogged down in consistency chaos.

Why Design Tokens Are Crucial Right Now

Here’s what changed: design systems used to be nice-to-haves for big companies with dedicated teams. Now they’re table stakes for any product that exists on more than one platform. Your web app, iOS app, and Android app all need to look like the same brand, respond to the same user interactions, and update at the same time when you rebrand or add dark mode.

Without design tokens, you’re manually syncing design decisions across platforms. With tokens, you define it once and it cascades everywhere. The difference between these approaches is the difference between shipping a rebrand in two weeks versus six months. And even more important when you ship faster with AI.

The brief version: design tokens are named variables that store design decisions—colours, typography, spacing, shadows, everything visual. Instead of hardcoding #1E40AF in your stylesheet, you use a token like colour-primary-600. When you inevitably need to adjust that blue, you change it in one place and every instance updates.

This sounds obvious, but most teams implement it badly or not at all. They either go too granular (300 tokens for 30 UI elements) or too vague (token names that mean nothing to anyone). Both approaches fail.

Implementation Approach

Best Practices That Actually Work

The conventional wisdom is to start with atomic tokens, the smallest possible units, and build up. Pure colours, raw spacing values, individual font sizes. Then create semantic tokens that reference atomic tokens: colour-primary references blue-600. Then create component-specific tokens: button-background-primary references colour-primary.

That’s technically correct and practically useless for most teams. Here’s why: you’ll build this beautiful hierarchy and then nobody will use it because it’s too abstract to understand quickly. Designers will keep hardcoding values because looking up the right token takes longer. Engineers will create one-off overrides because the token they need doesn’t exist.

Imagine builing a comprehensive four-tier token system based on best practices from design system articles. Six months later, only 40% of the components actually use it. The rest has inline styles or custom CSS because the token system was too complex to navigate. It’s optimised for theoretical purity over practical adoption.

Here’s what works better: start with the tokens you’ll use most frequently. Not the most atomic, the most frequent. For most products, that’s:

• Colour tokens for interactive states: primary, secondary, disabled, error, success. These appear everywhere and need to be consistent.
• Spacing tokens for layout rhythm: your 4px/8px/16px scale (or whatever your designers prefer). These determine whether your UI feels deliberate or random.
• Typography tokens for hierarchy: heading sizes, body text, captions. These make content scannable.

That’s it initially. Thirty tokens, maybe forty. You can expand later, but starting lean means people actually adopt it.

The specific nomenclature matters less than you think, but consistency matters enormously. Pick a naming convention—whether it’s colour-primary-600 or blue-600 or action-primary—and stick with it religiously. The teams that struggle aren’t the ones with imperfect names; they’re the ones where every designer names things differently.

Tooling and Process

The design token tooling landscape in 2026 is better than it’s ever been, which means you’ve got choices and choices mean you can pick the wrong tool for your context.

Here’s what matters: seamless sync between design and code. If designers update a token in Figma and engineers have to manually copy the new values into stylesheets, your token system will drift out of sync within weeks. You need automation.

The two approaches that actually work in production:

Style Dictionary or similar build tools that transform token definitions (usually JSON or YAML) into platform-specific code. You maintain one source of truth, run a build step, and it generates CSS variables, iOS Swift code, Android XML, whatever you need. This is mature, stable, and works.

The downside: it’s a build step. Designers can’t update tokens directly — they need to edit JSON or ask an engineer to do it. For some teams, that’s fine. For others, it kills momentum.

Design tool plugins that export directly to code repositories. Figma’s Variables API made this properly viable in the last couple of years. Designers update tokens in Figma, plugin pushes changes to Git, CI pipeline deploys. When this works, it’s brilliant—designers have autonomy and changes propagate automatically.

The downside: it only works if your design and engineering workflows are properly integrated. If your engineers don’t review design changes before they go live, you’ll ship unintended modifications. If your Git workflow is chaotic, automation just propagates chaos faster.

Add a simple approval workflow: design token changes creates PRs that requires sign-off.

Scaling What Works

Growth Considerations

What makes sense at five people creates bottlenecks at fifty. The challenge isn’t just the number of people, it’s the number of platforms, products, and brands you’re supporting.

I’ve watched this evolution multiple times. Initially, you’ve got one product on one platform. Your token system can be simple, maybe just CSS custom properties in a single stylesheet. Then you launch a mobile app and suddenly need tokens that work in Swift and Kotlin. Then you acquire another company and need to support their brand alongside yours. Then you add white-labelling for enterprise customers.

Each expansion point tempts you to create one-off solutions. “We’ll just maintain a separate token file for iOS.” “We’ll just hardcode the acquired brand’s colours.” These shortcuts compound. Within a year, you’ve got five different token systems that are nominally synced but actually diverge constantly.

The time to invest in proper infrastructure is before you need it. Once you’ve got three platforms with three different token implementations, retrofitting a unified system is painful. Teams resist because migration is work with no immediate user benefit.

Here’s the specific threshold I’ve observed: once you’re on two platforms (web + mobile, or two web properties), invest in a proper token pipeline. Not “we’ll get to it eventually.” Now. The return on investment is immediate—you ship cross-platform features faster because styling is already solved.

Maintaining Quality

The hidden challenge with design tokens isn’t setting them up. It’s preventing them from degrading into chaos over time.

You launch with a clean token system. Six months later, someone needs a slightly different shade of grey. Creating a new token feels like overkill for one use case, so they use rgba(0, 0, 0, 0.15) directly. Another designer does the same thing with rgba(0, 0, 0, 0.16). Now you’ve got two, almost identical, greys that aren’t semantic tokens and will never get updated when you refine your colour palette.

Multiply this by 50 small decisions and your design system is Swiss cheese. Official tokens surrounded by a wasteland of undocumented overrides.

The solution isn’t more enforcement (design system police don’t work). It’s making the token system easy enough that using it is less effort than working around it. Specifically:

Make token lookup instantaneous. If finding the right token requires searching through documentation, people won’t do it. Figma plugins that surface relevant tokens as you design, IDE autocomplete for developers, searchable token libraries—these aren’t nice-to-haves. They’re essential for adoption.

Create a clear process for requesting new tokens. Not “ask in Slack and maybe someone will add it eventually.” A specific form or ticket template where designers justify why existing tokens don’t work. This creates a moment of reflection, often people realise they can use an existing token—and it creates an audit trail so you understand why your token system evolved the way it did.

Run regular token audits. Once a quarter, check for tokens that aren’t used anywhere (delete them), overrides that appear more than once (extract them to tokens), and tokens with confusing names (rename them). This is boring maintenance work, which means it won’t happen unless someone owns it explicitly.

The Development Context

Technical Considerations

The relationship between design tokens and your technical architecture matters more than most PMs realise. I’ve seen well intentioned token systems fail because they assumed technical capabilities that didn’t exist.

Example: CSS custom properties (CSS variables) are brilliant for web design tokens. They cascade, they can be scoped, they update dynamically. Perfect. But they don’t work in emails because most email clients don’t support them. If your product sends lots of templated emails that need to match your brand, your token system needs to compile to old-school hex values for email contexts.

Similarly, if you’re supporting older browsers (yes, some enterprises are still on IE11 for legacy reasons), CSS variables won’t work. You need a build step that transforms tokens into static CSS or uses a JavaScript polyfill.

The technical consideration that trips up most teams: how do tokens interact with dark mode, colour blindness modes, and other accessibility variants? The naive approach is to define separate token sets: colour-primary-light and colour-primary-dark. This technically works but doubles your token count and makes it easy to define token pairs that don’t actually work together.

Better approach: define semantic tokens that reference different underlying values depending on context. colour-text-primary might be grey-900 in light mode and grey-100 in dark mode. The component using the token doesn’t need to know—it just references colour-text-primary and the system handles the rest.

This requires slightly more sophisticated tooling but massively reduces cognitive load. Designers and engineers work with semantic tokens that make sense—“text primary,” “background secondary”—rather than maintaining parallel token sets in their heads.

Team Dynamics

The hardest part of design tokens isn’t technical. It’s getting product, design, and engineering to agree on what consistency means and how much flexibility individual teams should have.

The mistake most teams make is trying to enforce total consistency or allowing total flexibility. Both extremes fail. You need clarity about what must be consistent and what can vary.

Key Takeaways

Let’s get practical:

• Start with frequently used tokens, not comprehensive atomic tokens. Thirty tokens that everyone uses beats 300 tokens that nobody can navigate. You can expand later, but lean systems get adopted.

• Automate token sync between design and code, but add approval workflows. Manual syncing creates drift. Uncontrolled automation creates chaos. The sweet spot is automated pipelines with human checkpoints for significant changes.

• Invest in proper token infrastructure once you’re on two platforms. Delaying this creates technical debt that gets exponentially harder to fix as you add more platforms and products.

• Make token lookup effortless or people won’t use tokens. Autocomplete, searchable libraries, Figma plugins—these aren’t polish, they’re essential for adoption. If using a token takes longer than hardcoding a value, people will hardcode.

• Define clear governance about what must be consistent versus what can vary. All-or-nothing approaches fail. Explicit two-tier systems (core + contextual) give teams autonomy without sacrificing brand coherence.

Getting Started This Week

Look at your most recent design handoff. How many times did the designer specify a colour value? A spacing value? A font size? Those are all potential tokens.

Pick five values that appear most frequently. Name them semantically (what they mean, not what they are). Document them somewhere your whole team can access. Start using them in one component. See if it makes the next iteration of that component faster to implement.

That’s it. You don’t need a comprehensive design system. You need five tokens that make tomorrow’s work easier than today’s. Once you’ve proved the value, expanding becomes obvious.

Have questions or thoughts? Get in touch - I’d love to hear from you!