From Screenshot to Style System: A 5-Day Design Token Playbook Clients Actually Adopt | Blanche

Most design token projects don’t stall because teams don’t understand tokens. They stall because the work starts too big.

A typical agency scenario looks like this:

The UI is a patchwork of “just ship it” decisions across marketing pages, product UI, and campaigns.
Multiple designers interpret the same brand differently.
Frontend has a mix of Tailwind utilities, ad-hoc CSS, and a half-finished component library.
The client wants “a design system,” but what they really need is consistency they can maintain.

The fix isn’t a 12-week design system initiative. It’s a minimal, shippable token set that can be adopted in days, not quarters—and a workflow that makes bloat hard and progress obvious.

Callout: The goal of tokens isn’t perfect taxonomy. It’s reducing decision-making and inconsistency while increasing delivery speed.

Why most design token projects stall (and how to avoid it)

1) They start with a blank canvas

If you begin token work by inventing a pristine token architecture, you’re already behind. Real clients don’t have pristine UIs—they have screenshots, legacy CSS, and “that one button style from last year’s campaign.”

Takeaway: Start by extracting what exists, then tighten.

2) They confuse “primitives” with “semantic” tokens

Teams often jump straight to semantic tokens like button.primary.background, but they haven’t stabilized the underlying palette, typography scale, or spacing rules.

Takeaway: Lock primitives first, then map semantics.

3) They create tokens for everything

Token bloat happens when you tokenize every edge case:

color-blue-487
padding-card-compact-v2
shadow-modal-legacy

It feels thorough, but it’s unmaintainable.

Takeaway: Tokenize decisions, not artifacts.

4) There’s no governance

Without an owner, tokens become a dumping ground. Without versioning, every change becomes a fire drill.

Takeaway: Governance is not bureaucracy—it’s what makes adoption safe.

The 5-day extraction workflow: from audit → primitives → components

This is designed for agencies: fast, adoptable, and resilient to handoffs.

Day 1: Audit the UI like a detective (not a perfectionist)

Inputs:

15–30 key screens (or page templates) across product + marketing
Existing CSS (if available)
Figma files (if they exist)

What you’re looking for: repetition and drift.

Do a “screenshot inventory”

Create a board (FigJam, Miro, or even Figma) with screenshots grouped by UI area:

Buttons
Forms
Navigation
Cards
Alerts/toasts
Typography blocks
Data display (tables, badges)

Then annotate what’s inconsistent:

How many blues are used for links?
How many corner radii exist?
How many shadows appear?

Tooling that helps:

Figma: selection color/typography inspection
Chrome DevTools Coverage + CSS search
Stylelint or PostCSS stats (if you have a codebase)

Deliverable by end of Day 1:

A list of candidate primitives (colors, type, spacing, radii, shadows)
A list of top 10 “high pain” components (usually buttons, inputs, cards)

Rule: You’re not auditing everything. You’re auditing what drives 80% of UI output.

Day 2: Extract primitives into a minimal “v0” token set

Primitives are your raw materials. Keep them boring and stable.

Start with the smallest set that can ship

A practical v0 usually includes:

Color: neutral scale + 1–2 brand scales + semantic status colors
Typography: font families, base sizes, line heights, weights
Spacing: a step scale (e.g., 4, 8, 12, 16…)
Radii: 2–3 options max
Shadows: 2–4 levels max
Borders: 1–2 widths

Example (primitives):

color.neutral.0…900
color.brand.50…900
space.1…12
radius.sm | radius.md | radius.lg
shadow.1…4

Avoid the most common color trap

Clients often have “brand blue” plus 14 slightly different blues. Don’t encode all of them.

Instead:

Pick a brand scale (50–900) that can handle hover/active states.
Map legacy blues to the nearest scale values.
Create a temporary “legacy” bucket only if needed, and plan to delete it.

Callout: If you can’t delete a token later, it’s not a token—it’s a permanent compatibility layer.

Deliverable by end of Day 2:

A primitives token file (JSON) + a Figma variables collection draft

Day 3: Create semantic tokens that reflect product intent

Semantic tokens are what designers and developers should reach for day-to-day. They encode meaning:

color.text.default
color.surface.canvas
color.border.muted
color.action.primary
color.action.primaryHover

A naming convention that survives handoffs

A durable pattern is:

Category (color, space, radius, type)
Role (text, surface, border, action)
Intent (default, muted, primary, danger)
State (hover, active, disabled, focus)

Examples:

color.text.default
color.text.muted
color.surface.default
color.surface.raised
color.action.primary.default
color.action.primary.hover
color.action.primary.disabled

How to avoid token bloat

Use these constraints:

Every semantic token must map to a primitive. No raw hex values.
Every token must have at least two consumers. If only one component uses it, it’s probably a component token.
Prefer composition over proliferation. For example, use color.border.default broadly rather than creating color.border.card, color.border.table, color.border.modal.

Deliverable by end of Day 3:

Semantic token layer defined and mapped to primitives
A short “token usage rules” doc (1 page)

Day 4: Wire tokens into components (Figma + code) with a thin adoption layer

This is where token projects become real.

Pattern 1: CSS variables as the source of truth in production

A pragmatic approach:

Store tokens in JSON (for portability)
Generate CSS variables (for runtime theming)
Optionally generate TypeScript types (for safety)

Tools teams actually use:

Style Dictionary (classic, flexible)
Tokens Studio (great for Figma ↔ tokens workflows)
Panda CSS / Vanilla Extract (typed styling)
Tailwind (can consume CSS variables and map to utilities)

Example output (conceptual):

--color-text-default
--color-surface-default
--radius-md
--space-4

Then components reference variables rather than hard-coded values.

Pattern 2: Theming with fallbacks

If you need light/dark or multi-brand:

Define semantic tokens per theme
Keep primitives stable
Use fallbacks to avoid breaking pages

A safe rule:

Primitives rarely change
Semantic tokens can change per theme
Component tokens change the most (and should be treated carefully)

Pattern 3: Component library alignment

If you have a component library (React, Vue, Web Components), implement tokens at the lowest level:

Base Button uses color.action.primary.*
Input uses color.border.default, color.text.default, color.surface.default

Takeaway: If components don’t consume tokens, tokens are just documentation.

Deliverable by end of Day 4:

Tokens flowing into CSS variables
3–5 core components refactored to use tokens end-to-end

Day 5: Governance, versioning, and client-proof documentation

This is the part agencies skip—and the part that determines whether clients actually keep using the system.

Handoff + governance: versioning, docs, and ownership

Decide who approves token changes

A simple RACI works well:

Owner (Accountable): Design System Lead (agency or client)
Approvers (Responsible): 1 design + 1 frontend representative
Contributors: any designer/dev via PR
Informed: product/marketing stakeholders

Callout: If everyone can add tokens, token count only goes up.

Version tokens like a product

Treat tokens as a package:

Use SemVer (major/minor/patch)
Publish a changelog
Require a PR template: “what changed, why, screenshots, migration notes”

Rules of thumb:

Patch: fixing a typo, adjusting documentation, no visual change
Minor: adding tokens, non-breaking
Major: changing/removing tokens, visual changes likely

Document decisions, not just values

Clients don’t need a 40-page design system site to start. They need:

Token inventory (table)
Usage guidelines (when to use what)
Decision log (why you chose a scale, what you deprecated)
Migration notes (what to update in code)

Where to host it:

Zero-friction: README in the tokens repo
Better: Storybook + MDX docs
Enterprise: Backstage, Confluence (but keep the source close to code)

Deliverable by end of Day 5:

Governance doc (1–2 pages)
Versioned token package/repo with changelog
“How to request a token change” workflow

Implementation patterns that keep tokens fast to adopt (and hard to break)

Pattern A: The “two-layer token model” (primitives + semantics)

This is the sweet spot for most agency clients.

Primitives stabilize the visual language
Semantics stabilize usage across teams

You can add component tokens later if the library matures.

Pattern B: Deprecation instead of deletion

When you must change a token:

Mark old tokens as deprecated
Keep them for one minor version cycle
Provide a codemod or search/replace guidance
Remove in the next major version

Takeaway: Deprecation is how you keep trust while improving the system.

Pattern C: “Compatibility tokens” for legacy UI

If the client has legacy pages that can’t be refactored immediately, create a small compatibility layer:

legacy.color.link → maps to color.action.primary.default

Then gradually migrate consumers to the new semantic tokens.

Takeaway: Compatibility tokens are a bridge, not a destination.

Before/after metrics (what clients actually care about)

Tokens are only valuable if you can prove impact. Track these:

Delivery speed

Time to build a new landing page section
Time to implement a new component variant

Consistency

Count of unique hex values in production CSS (should drop)
Count of unique font sizes/line heights (should drop)

Maintainability

Number of “one-off” overrides per page/template
Frequency of design QA issues related to spacing/color/type

Rebrand readiness

Time to update brand color and propagate across surfaces
Number of files/components touched for a brand update

A realistic win after adopting a minimal token set:

Fewer UI regressions because components reference stable semantic tokens
Faster iteration because designers stop debating “which gray”
Rebrands become controlled variable changes, not a scavenger hunt

Callout: The ROI isn’t tokens. The ROI is fewer decisions and fewer inconsistencies.

A client pitch template you can reuse

Use this structure in your next kickoff or QBR.

1) The problem (in their language)

“Right now, new pages and features ship with small visual differences that add up—different grays, inconsistent spacing, slightly different button styles. That slows down delivery and makes rebrands expensive.”

2) The proposal (small, fast, safe)

“In 5 days, we’ll extract a minimal token set from your existing UI and connect it to Figma and your codebase using CSS variables. This isn’t a redesign—it’s a consistency layer.”

3) The deliverables

Token set (primitives + semantic)
Figma variables aligned to code
CSS variable implementation
3–5 core components refactored
Governance + versioning workflow

4) The success metrics

Reduce unique colors by X%
Reduce unique type sizes by Y%
Cut time-to-build for new sections by Z%
Reduce QA inconsistencies per release

5) The next step

“After v0 adoption, we’ll expand coverage component-by-component, prioritizing the surfaces you ship most.”

Conclusion: ship the smallest token system that can’t be ignored

A token system clients actually use is not the most comprehensive one. It’s the one that:

Starts from reality (screenshots, legacy UI, messy CSS)
Ships quickly (a week, not a quarter)
Has names that survive handoffs
Works across Figma, CSS variables, and components
Includes governance so it doesn’t decay

If you lead an agency team, the competitive advantage isn’t “we do design tokens.” It’s we can make your UI consistent without slowing you down.

Want a fast-start token plan for your client?

If you share (1) 10–15 screenshots and (2) a link to the repo or compiled CSS, we can outline a v0 token set, naming scheme, and a 5-day delivery plan tailored to your stack (Webflow, React, Next.js, Tailwind, Storybook, etc.).