Design tokens are named, structured values — colors, spacing, typography, radii — that represent design decisions in a form both designers and engineers use.
Design tokens are the atomic named values of a design system — colors, type scales, spacing, radii, shadows, motion timing — expressed in a technology-agnostic format that can be transformed into CSS variables, iOS assets, Android resources, or any other consumer. The concept originated at Salesforce and has become the way modern design systems maintain consistency across platforms. Tokens are what makes 'we have a design system' more than 'we have a Figma library that engineers implement inconsistently.'
A well-structured token system has three layers. (1) Primitive tokens — raw values with no semantic meaning: color.blue.500 = #3b82f6, spacing.4 = 16px. (2) Semantic tokens — meaning attached to primitives: color.action.primary = color.blue.500, color.text.body = color.gray.900. (3) Component tokens — component-specific applications: button.primary.background = color.action.primary. Components consume component tokens; component tokens reference semantic tokens; semantic tokens reference primitives. Changing the brand color updates one primitive and cascades everywhere. Consuming primitives directly in components (bg-blue-500) collapses the system back to what tokens were meant to fix.
Names should describe intent, not appearance. color.surface.subtle is better than color.gray.100 because when dark mode arrives, 'subtle surface' means something in both modes but 'gray 100' doesn't. Categories that hold up: color (background/text/border/icon by role), spacing (numeric scale, not t-shirt sizes for most cases), typography (size/lineHeight/weight pairs by role), radius, shadow, motion (duration/easing), z-index. Adopt a consistent depth (color.background.surface.subtle) and stick to it — inconsistent naming depth is the primary cause of tokens nobody can find.
Dark mode, high-contrast mode, brand variants — all should be theme variations that swap semantic-token → primitive mappings, not entirely separate token sets. The single source of truth is the semantic layer; each theme redefines which primitives semantic tokens resolve to. This makes 'add a new theme' a bounded task instead of 'duplicate everything.' Component code stays theme-agnostic — it references semantic tokens, and the current theme's mapping determines what those resolve to at runtime (CSS variables) or build time (native platforms).
Style Dictionary (Amazon) is the reference token compiler — takes token JSON, produces CSS, SCSS, JS, iOS, Android, and custom outputs. Tokens Studio (Figma plugin) syncs tokens between Figma and code repositories. Design system teams that skip a token compiler end up manually maintaining CSS variables alongside Figma tokens, and the two inevitably drift. Set up the pipeline early: Figma is the design source, JSON is the code source, and one of them is the master.
Who can add tokens matters as much as what tokens exist. A common failure mode: every component team invents their own tokens, and a year later the token file has three versions of 'primary button color.' Governance that works: primitive and semantic tokens require design system team approval; component tokens can be added by teams consuming the system. Reviews take time but keep the token vocabulary coherent. Uncontrolled token growth is functionally equivalent to no token system — you've just moved the inconsistency into a slightly more structured file.
Investor directory · Fundraising library · Articles A–Z · Company funding database