Design Tokens for Small Studios: What to Tokenise (And What to Leave Alone)

The Token Hype Cycle

Design tokens have traveled the full hype cycle in the years since Salesforce popularized the concept. Enterprise design systems adopted them eagerly. Tooling proliferated: Style Dictionary, Tokens Studio, Figma Variables, Amazon's token spec. Conference talks multiplied. And somewhere along the way, the message filtered down to small studios: "You need design tokens."

You might. You might not. The answer depends entirely on what problems you actually have, not on what problems enterprise design systems have.

This article is for studios with one to ten people building brand sites, portfolio sites, and small to mid-scale web projects. Not for teams maintaining component libraries used by 200 engineers. The scale difference changes everything.

What Tokens Actually Are

A design token is a named value that represents a design decision. Instead of using #1a1a1a directly in your CSS, you use a name like color-fg-primary that resolves to #1a1a1a. Instead of writing 16px for spacing, you use space-4.

That is all tokens are: named constants. The name communicates intent. The value communicates implementation. Separating the two lets you change the implementation without finding and replacing values across an entire codebase.

CSS custom properties are design tokens. Sass variables are design tokens. Tailwind's theme configuration is a design token system. You are probably already using design tokens whether you call them that or not.

The question is not whether to use tokens. It is how many to create, how to name them, and where the return on investment drops to zero.

What to Tokenise

Colors: always

Color tokens are the highest-value, lowest-effort starting point. Every project benefits from named colors because:

• Colors change during brand refinement. Changing --color-primary in one place is faster than finding every instance of #2b5ea7 across 40 files.
• Dark mode requires swapping color values. Tokens make this a variable reassignment rather than a stylesheet rewrite. This is exactly the approach we described in Dark Mode for Brand-led Sites.
• Accessibility audits flag contrast ratios by color pair. Named tokens make it clear which background-foreground combinations exist and where they are used.

A minimum viable color token set for a brand site:

```

--color-bg: #faf8f5;

--color-bg-alt: #f0ede8;

--color-fg: #1a1a1a;

--color-fg-muted: #666666;

--color-accent: #2b5ea7;

--color-accent-hover: #234b86;

--color-rule: #e0ddd8;

--color-error: #c53030;

```

Eight tokens. That is enough for most studio projects. If you need more, add them as the design requires. Do not pre-create tokens for colors you might use later.

Spacing: usually

Spacing tokens create visual consistency. A constrained spacing scale (4px, 8px, 12px, 16px, 24px, 32px, 48px, 64px, 96px) prevents the gradual drift where one section uses 18px padding, another uses 20px, and a third uses 22px.

If you are using Tailwind, the spacing scale is already defined in the framework. You do not need additional spacing tokens unless you have custom values outside Tailwind's scale.

If you are writing vanilla CSS, define spacing tokens:

```

--space-1: 0.25rem;

--space-2: 0.5rem;

--space-3: 0.75rem;

--space-4: 1rem;

--space-6: 1.5rem;

--space-8: 2rem;

--space-12: 3rem;

--space-16: 4rem;

--space-24: 6rem;

```

Typography: selectively

Font family tokens (--font-sans, --font-mono) are simple and useful. Font size and line height tokens are useful if you have a strict typographic scale and want to enforce it.

But be careful about over-tokenising typography. A token like --text-body-large-line-height is harder to remember than writing line-height: 1.5 directly. The token adds indirection without solving a real problem because body line height rarely changes independently of a full typographic redesign.

Token what changes together. Font size and line height for a specific text style often change together, so a composite approach (a CSS class or a Tailwind utility) is more practical than individual tokens.

We wrote about typographic scale systems in Type Systems: Scale That Survives, which covers the relationship between tokens and type more thoroughly.

Borders and radii: sometimes

If the brand uses a consistent border radius (all rounded corners are 4px, or all are 8px), a single token is useful:

```

--radius-sm: 4px;

--radius-md: 8px;

--radius-lg: 16px;

```

If the brand uses sharp corners everywhere, you do not need radius tokens. Do not create tokens for things that do not vary.

Shadows: rarely

Box shadows are complex values that resist tokenisation. A shadow token like --shadow-md: 0 4px 6px -1px rgba(0,0,0,0.1), 0 2px 4px -2px rgba(0,0,0,0.1) is not more readable than the raw value. It does not change frequently enough to justify the indirection.

If you have exactly two or three shadow levels used consistently across the site, tokens make sense. If shadows are bespoke per-component, skip the tokens.

Breakpoints: no

CSS custom properties cannot be used in media query conditions. You cannot write @media (min-width: var(--bp-md)). This is a fundamental CSS limitation. Breakpoint tokens in CSS custom properties are useless for their primary purpose.

If you need breakpoint tokens, define them in a preprocessor (Sass variables) or in your build tool configuration (Tailwind theme). But for most studio projects, media queries with raw pixel values are perfectly clear.

What Not to Tokenise

Component-specific values

A token called --card-padding is not a design decision. It is a component implementation detail. It does not need to be abstracted because it is only used in one place. If card padding changes, you change it in the card component.

Tokens should represent decisions that apply across multiple components. --space-4 is used for card padding, modal padding, and section padding. That is a design decision worth naming. --card-padding is not.

One-off values

If a value appears exactly once in the entire codebase, it does not need a token. The token adds a layer of indirection with no benefit. You are naming something that has no second use.

Animation values

Animation durations, easing functions, and delays are rarely shared across components in a meaningful way. A button's hover transition and a modal's entrance animation happen to both be 200ms, but they are not the same design decision. Changing one should not automatically change the other.

If you do standardise on a small set of durations (fast: 150ms, normal: 250ms, slow: 400ms), tokens can work. But most studios do not need this level of animation standardisation.

Naming Conventions

Token names should describe what the token does, not what it looks like. --color-primary is better than --color-blue because primary does not break when the brand color changes from blue to green.

The naming hierarchy that works at studio scale:

```

--{category}-{property}-{variant}

Examples:

--color-bg

--color-bg-alt

--color-fg

--color-fg-muted

--space-4

--space-8

--font-sans

--font-mono

--radius-sm

--radius-md

```

Do not use multi-tier hierarchies like --semantic-color-surface-primary-default. That naming convention exists to disambiguate hundreds of tokens in enterprise systems. A studio project with 15 to 30 tokens does not need disambiguation. Shorter names are faster to type, easier to remember, and simpler to scan in a stylesheet.

Token Architecture

Single tier is enough

Enterprise token systems often use three tiers: global tokens (raw values), alias tokens (semantic names that reference global tokens), and component tokens (component-specific references to alias tokens).

For studio projects, one tier is sufficient. Your CSS custom properties are your tokens. They have semantic names and concrete values. Adding a "global" tier underneath doubles the maintenance work without adding value at your scale.

One file for all tokens

Put all your tokens in one CSS file or in the :root block of your global stylesheet. At 15 to 30 tokens, there is no need for separate files per category. One file is searchable, scannable, and simple.

When the project grows past 50 tokens, consider splitting into separate files. But most studio projects never reach that threshold.

The Minimum Viable Token Set

For a new brand or portfolio site, start with this:

• 6 to 10 color tokens (backgrounds, foregrounds, accent, error)
• 8 to 10 spacing tokens (based on a 4px grid)
• 2 to 3 font family tokens
• 2 to 3 border radius tokens

That is 18 to 26 tokens. It fits in a single screen of CSS. It covers the design decisions that actually change across projects. It avoids the complexity that makes token systems a burden rather than a tool.

Add more tokens only when you encounter a specific problem that a token would solve. Not before. Not speculatively. Not because a blog post told you to tokenise everything.

The Anti-Pattern: Token Proliferation

We have inherited projects with 200+ tokens for a 12-page marketing site. Tokens for every conceivable property, variant, and state. The result was a system that nobody on the team could navigate without a reference document. Developers bypassed the tokens and wrote raw values because finding the right token took longer than typing the value.

Token proliferation is the design systems equivalent of premature optimization. It solves problems you do not have while creating a problem you do: complexity that slows the team down.

The discipline is not in creating tokens. It is in restraining yourself from creating tokens you do not need yet.