How to build a lightweight component token system in css and figma that a single designer can maintain

I’ve been refining lightweight design systems for years, and one recurring truth keeps surfacing: when a single designer owns the UI library, simplicity wins. You don’t need a sprawling token platform or a dedicated engineering team to get consistent, flexible components. What you do need is a small, well-documented set of tokens that live in both Figma and CSS — easy to update, easy to understand, and easy to ship. In this piece I’ll walk through a practical approach I use to build a component token system that a single designer can maintain.

Why a minimal token system?

Design tokens are powerful, but they can also become an overhead. When I start a new product or refactor an existing one, I ask: what’s the smallest set of tokens that solves most consistency problems without becoming a chore to update? The answer usually includes color, spacing, typography, and a few component-specific tokens (like radius and elevation). Keep tokens focused on decisions you reuse — not every micro-variation.

Principles that guide my approach

Single source of truth: Figma for visual design and tokens, CSS for runtime. Changes in one place should be easy to reflect in the other.

Minimalism: Start small. Add tokens only when a pattern emerges.

Human-friendly names: I avoid cryptic token names. Names should describe intent, not pixel values.

Gradual adoption: Ship with fallback CSS variables when tokens are updated, so you don’t break production.

Core token categories I use

Color: primary, secondary, background, surface, text-high, text-low, error, success, and semantic accent tokens.

Typography: font-family, scale tokens (type-xs, type-sm, type-md, type-lg), line-height tokens, and weight tokens.

Spacing: a simple scale (spacing-2, spacing-4, spacing-8, spacing-16...).

Radii & Elevation: border-radius-sm/md/lg and elevation tokens (elevation-1..3) expressed as shadows or overlay values.

Component tokens: button-padding, input-border, card-gap, etc. Only add these after multiple components share the same property.

Naming tokens for a single maintainer

Names should communicate intent. I prefer semantic names like bg-surface over gray-100. Why? When you’re the only person touching the library, you’ll thank yourself later when a color role changes — you can change bg-surface without hunting down every usage of gray-100.

Examples I commonly use:

--color-bg-surface

--color-text-primary

--type-md

--spacing-8

How I structure tokens in Figma

Figma’s styles are excellent for storing tokens. I create a single “Tokens” page in my file and group styles by category: Colors, Text, Effects, and Grid/Spacing. For maintainability:

I keep color styles named with an intentional prefix: Color / Surface / Default, Color / Text / Primary.

Text styles map to token names: Type / md / 16px / 24 which corresponds to --type-md.

Use Figma variables (if available in your plan) to model color and numeric tokens. This makes it easier to export and map to CSS variables.

Translating Figma tokens to CSS

The process I follow is straightforward and script-light. I prefer a workflow that scales manually without heavy toolchains, but also lets me script exports when needed.

Export color palette or use Figma’s variables export to JSON.

Create a base CSS file with variables. Example (conceptual):

/* CSS variables */
--color-bg-surface: #ffffff; --color-text-primary: #111827; --type-md: 16px;

Store this CSS in a single file (e.g., tokens.css) that gets imported into your component styles. This makes updates atomic.

Practical CSS patterns I rely on

I use CSS custom properties and a utility layer. Here are patterns that help keep the system minimal and easy to maintain:

Fallbacks: When introducing a new token, keep a fallback so older browsers or components still work. Example: color: var(--color-text-primary, #111827).

Derivation through calc and color-mod: When possible, derive values rather than copy them. For spacing, use multiples: --spacing-16: calc(var(--spacing-8) * 2). For color tints/shades, use a single source and tools like Sass or postcss-color-mod if your stack allows it.

Component-level names: Allow a small set of component tokens to override global roles, e.g., --button-bg falls back to --color-bg-primary.

Example mapping: Figma -> CSS -> Component

Figma	CSS Variable	Usage
Color / Primary / Base	--color-primary	button background, link color
Type / md	--type-md	body, small headlines
Spacing / 8	--spacing-8	component gap, padding

Keeping Figma and CSS in sync

Two practical approaches work depending on how much automation you want:

Manual sync (for solo designers): Update the token file in Figma, export a quick JSON or copy hex/values, paste into tokens.css. Takes a few minutes and keeps you in control.

Light automation: Use a Figma plugin (like “Design Tokens” or “Figma Tokens”) to export tokens to JSON, then a small script turns that into a CSS variables file. I use this when the product matures to reduce human error.

Versioning and backward compatibility

When you’re the only maintainer, it’s tempting to refactor tokens frequently. I recommend a simple versioning policy:

Keep a changelog in the tokens repo or file. Note intent: “Changed primary color to warmer tone — updated --color-primary; kept alias --color-link for backward compatibility.”

Introduce aliases rather than renaming tokens. Add --color-link that points to --color-primary for a release cycle before fully switching usages.

When to add component-specific tokens

Only add them when two or more components share the same tweak. For example, if buttons, chips, and badges all need a specific small radius, promote that radius to --radius-sm. If just one component uses it, keep it local to the component CSS until a pattern emerges.

Documentation that actually gets read

Long READMEs are tempting but rarely consumed. I keep documentation practical and short:

One-page “Tokens” doc in Figma with examples (button, card, form) and a copy-paste section that shows how to import tokens.css.

A short change log and a “when to add tokens” guideline — this prevents token bloat.

Visual examples in Figma where changing one color style shows how multiple components update — it’s the quickest proof of value.

Maintenance routine for a single designer

My weekly routine is simple and sustainable:

Scan for inconsistencies in the UI Kit or product. If I spot repeated overrides, consider promoting to a token.

When I change a token, update Figma style, tokens.css, and a single-line note in the changelog.

Use feature branches for larger refactors and small automated tests (visual diffs) if the project supports them.

Building a lightweight component token system isn’t about exhausting coverage — it’s about creating a dependable backbone that reduces decision fatigue and speeds up delivery. Keep tokens semantic, minimal, and well-documented in both Figma and CSS. With the right habits, a single designer can maintain a robust system that scales with the product without turning into a full-time job.