12 Design Token Categories for Consistent Digital Interfaces
Twelve categories of design tokens, from colour and spacing to motion and breakpoints, how to name them in tiers and what the 2025 token format standard covers.
Which design token categories does an interface need?
Most products need tokens for colour, typography, spacing, sizing, border radius, borders, shadows (elevation), opacity, motion (duration and easing), breakpoints, layering (z-index) and icon sizes. Organise them in tiers: primitive tokens hold raw values, semantic tokens describe purpose (such as "text-error") and point to primitives, and component tokens, where needed, apply semantic tokens to specific components.
This list is for designers and front-end developers setting up or tidying a design system. The Design Tokens Community Group's format specification, version 2025.10, defines standard types including colour, dimension, font family, font weight, duration, cubic Bézier and number, and composite types for border, shadow, transition, gradient, typography and stroke style. For when a design system is worth the effort, see design systems for teams that move fast.
Primitives, semantic tokens and component tokens
Naming in tiers is what makes tokens maintainable. A primitive token names a raw value (blue-600). A semantic token names a purpose (action-primary-background) and refers to a primitive. Components use semantic tokens. When the brand blue changes, or you add a dark theme, you change what the semantic tokens point to rather than editing every component. The specification supports this through aliases, where one token references another.
The 12 categories
1. Colour. Primitives for the palette, and semantic tokens for text, backgrounds, borders, actions and status (success, warning, error, info). Semantic colour tokens are what make dark mode and theming manageable. Check contrast for each pairing. See accessible UI/UX design.
2. Typography. Font families, weights, sizes, line heights and letter spacing, often combined into composite styles such as heading-large or body-small. The specification has a composite typography type for this.
3. Spacing. A scale (for example 4, 8, 12, 16, 24, 32) used for padding, margins and gaps. A small, consistent scale removes most "is this 13 or 14 pixels?" debates.
4. Sizing. Fixed sizes for controls, avatars, touch targets and containers. Include minimum touch target sizes for mobile.
5. Border radius. A few steps, such as none, small, medium, large and full, applied consistently to buttons, cards and inputs.
6. Borders. Widths and styles for dividers, inputs and focus outlines. Treat focus ring tokens as their own semantic set so keyboard focus stays visible across themes.
7. Shadows and elevation. A small set of elevation levels (raised card, dropdown, modal) defined as composite shadow tokens, rather than ad hoc shadows per component.
8. Opacity. Values for disabled states, overlays and scrims, so disabled controls look the same everywhere.
9. Motion. Durations and easing curves (the specification's duration and cubic Bézier types), and transitions combining them. Name them by purpose, such as quick feedback or panel entrance, and respect users' reduced-motion settings.
10. Breakpoints. The screen widths at which layouts change, shared by design and code so responsive behaviour matches the designs.
11. Layering (z-index). Named levels for dropdowns, sticky headers, modals and toasts, so components do not compete with arbitrary numbers like 9999.
12. Icon sizes. A few sizes aligned with the type scale and touch targets, so icons sit consistently next to text.
Setting up a design system?
ZSpace Labs designs token-based design systems in Figma and implements them in code, so design and development share one source. See our UI/UX design service.
Category reference
| Category | Example semantic token | Spec type (2025.10) | Watch for |
|---|---|---|---|
| Colour | text-error | color | Contrast in every theme |
| Typography | heading-large | typography (composite) | Line height on small screens |
| Spacing | space-4 | dimension | Too many steps |
| Sizing | control-height-medium | dimension | Minimum touch targets |
| Border radius | radius-medium | dimension | Mixed radii on one screen |
| Borders | focus-ring | border (composite) | Focus visible in all themes |
| Shadows | elevation-modal | shadow (composite) | Shadows invisible in dark mode |
| Opacity | opacity-disabled | number | Disabled text contrast |
| Motion | duration-quick, ease-standard | duration, cubicBezier, transition | Reduced-motion preference |
| Breakpoints | breakpoint-tablet | dimension | Design and code disagreeing |
| Layering | layer-modal | number | Arbitrary large values |
| Icon sizes | icon-small | dimension | Alignment with text |
Practical advice
- Start with colour, typography and spacing; add other categories when inconsistency appears.
- Name semantic tokens by purpose, never by value ("action-primary", not "blue").
- Keep one source of truth, exported to design tools and code by a build step.
- Document when to use each semantic token, with examples.
- Review token changes like code changes, since one change affects every screen.
- Check that your tools support the 2025.10 format before relying on it; support varies.
Worth noting
Tokens make consistency easier but do not create it on their own. Components, documentation and review still decide whether the interface stays consistent. See design handoff for how tokens reach developers.
Conclusion
Twelve categories cover most of what an interface needs to stay consistent: colour, typography, spacing, sizing, radius, borders, shadows, opacity, motion, breakpoints, layering and icon sizes. Name them in tiers, keep one source of truth and start small. For using tokens and variables inside Figma, see Figma for product design.
Sources
Design Tokens Community Group, Design Tokens Format Module 2025.10 (types, composite types and aliases). Accessed 28 October 2026.
Common questions.
Named values for design decisions, such as a brand colour, a spacing step or an animation duration, stored once and used by both design tools and code. Changing a token changes every place that uses it.