Reference · Design systems
Design tokensValues with a purpose.
A color is a value. A token gives it a job. Connect your palette to the surfaces, text and actions people use, check every pairing in every mode, then carry the same decisions into each framework you ship.
- Tokens
- 177
- Layers
- 3
- Modes
- 2–4
- Export formats
- 10
Design token studio
A system you can shape.
Pick a brand color and the studio builds ramps, roles and components for every mode. Trace any alias through the graph, read every pairing in a contrast matrix, review what you changed, then export the same source to your stack.
Foundations
Every token below is generated from these settings. Your edits in the token editor sit on top and survive a change here.
Open the swatch for HEX, RGB, HSL, OKLCH and the eyedropper where supported.
Presets
Typography
Space and shape
Perceptual ramps
Eleven steps per family in OKLCH, mapped into sRGB; the seed keeps its nearest step. Tags show which roles point at a step in the current mode. Select a step to edit it.
Token graph
Primitives feed roles; components read roles. Select a token to trace everything it depends on and everything that depends on it.
Select a token in the graph.
Contrast matrix
Every text and accent role on every surface in the current mode. Outlined cells are pairs the system relies on; the rest are there to explore.
AAA 7:1 or more AA 4.5:1 UI 3:1, large text and controls Fail below 3:1. The second figure is APCA Lc.
WCAG 2 ratios use unrounded values. Text follows your AA / AAA target; focus rings and boundaries need 3:1. High-contrast modes need 7:1 for text and 4.5:1 for controls. Recheck every pairing in your product.
Token editor
Primitives hold values; roles and components hold references. Role edits apply to the current mode; component edits apply to every mode.
Add a custom primitive Seven supported types
Review
What to fix before you export, what changed, and snapshots to compare against.
Autosaved on this device
Up to six snapshots are kept in this browser, and each can be compared with the current workspace above. Download Workspace JSON for a portable copy. Reset clears the current workspace; saved snapshots stay available.
Export
One source, every consumer. Names and references update together in every format.
Use letters, numbers, hyphens or underscores.
Continue in the design engine with your seed, contrast target and naming. The engine generates a separate system and adds native platform exports; studio overrides stay in this workspace.
Continue in design engineStart with the interface
A workflow you can repeat.
Build the smallest useful system first. A card, a text field and a primary button reveal more missing decisions than a long list of colors.
- 01
Collect the decisions
Inventory repeated colors, type sizes, spacing and radii. Separate brand values from the jobs they perform.
- 02
Name the roles
Give surfaces, text, actions and focus indicators stable names. Map each role to a primitive in each mode.
- 03
Test real pairings
Check labels on buttons, text on every surface, hover states and focus rings in every mode, and under simulated color vision.
- 04
Review and export
Fix what the health check finds, read the diff, then generate framework files from the same source.
The architecture
Three layers, three jobs.
A small system can begin with primitives and roles. Add component aliases when a component needs its own contract.
The available values
color-brand-700: #4338ca and space-4: 16px define the inventory. They say what exists without promising where it belongs.
The intent of a value
color-primary → color-brand-700 means “primary action.” In a dark mode it can point to color-brand-300 while its consumers keep the same name.
A local contract
button-primary-bg → color-primary lets the button evolve independently. Keep the alias when the role is shared; add a component value only when its behavior differs.
Aliases are references to other tokens. Resolve every reference, preserve its type and reject circular chains before generating code. The studio only lets a token point down a layer, so a cycle cannot form.
A shared vocabulary
Name the job.
Use a predictable order: category, role, variant, state. Keep a ramp step for a primitive, and an intent for a role.
| Instead of | Use | Why |
|---|---|---|
blue-button | button-primary-bg | The action can change color. |
light-text | color-text-muted | The hierarchy holds in every mode. |
padding-big | space-6 | A scale has a defined value. |
red | color-danger-text | Status and usage are explicit. |
Choose kebab-case, camelCase, snake_case or PascalCase for your codebase. Use a prefix such as acme when several systems share a page. Document units, supported modes and the background each text role belongs on.
Treat a token name as an API. Renaming or removing one breaks consumers; changing a value still needs visual and contrast checks. Deprecate old names through aliases during a migration, and keep the changelog with the commit.
Change values, keep intent
Modes are role maps.
A dark mode is a second set of decisions about hierarchy, surfaces and emphasis. A high-contrast mode is a third.
Keep primitives available to every mode. Reassign semantic roles inside a mode, then have components read those roles. The studio chooses ramp references for each mode from measured contrast; if you edit a value or an alias, the matrix and the health check show the result.
surface → neutral 0
text → neutral 950
primary → a dark brand stepsurface → neutral 950
text → neutral 0
primary → a light brand stepsurface → neutral 0
text → neutral 1000
borders → 4.5:1 or moresurface → neutral 1000
text → neutral 0
borders → 4.5:1 or moreSet data-theme on a wrapper with the CSS export: light, dark, light-hc or dark-hc. Declare component aliases in each scope too, or inherited custom properties keep the value resolved on an ancestor. The light-dark() export follows the reader’s color scheme with no script, and its high-contrast roles follow prefers-contrast: more.
- Pair action fills with on-action labels; test default and hover together, and keep hover visibly different.
- Check muted text on every surface where it appears.
- Test focus rings and necessary control boundaries against adjacent colors.
- Use labels or icons alongside status colors, and check them under simulated color vision.
Use the contrast workflow for checks beyond the studio, the dark UI theme and the light UI theme for a measured example of each mode, and accessible UI patterns for keyboard and screen reader behavior.
One source, several consumers
Export for the code you ship.
The studio exports full foundations and mode-aware adapters. The engine adds native targets. Keep the source tokens under version control and regenerate the files when decisions change.
| Target | Use it for | Mode handoff |
|---|---|---|
| CSS / SCSS | Custom properties consumed with var(). | One scope per mode on data-theme, components redeclared in each. |
CSS light-dark() | Sites that follow the reader’s color scheme. light-dark() on MDN | Color roles switch with color-scheme; data-theme forces one. High contrast follows prefers-contrast or data-contrast="more". |
| Tailwind v3 | Extend colors, spacing, type, radii and shadows in theme.extend. v3 configuration | Utilities map to role variables; load the CSS export too. |
| Tailwind v4 | Define utilities with @theme. v4 theme variables | Uses @theme inline with the scoped roles. |
| JSON / TypeScript | Consume values in applications, build scripts or documentation. | Pick a mode’s role map in your application; an object does not switch a mode by itself. |
| DTCG | Exchange typed tokens and aliases across a compatible token pipeline. | DTCG 2025.10 types; one group per mode. Confirm your importer accepts that version. |
| Figma variables | Create the system in a Figma file through the Variables REST API. | Two collections: primitives, and a theme collection with one mode per mode. Needs an Enterprise plan. |
| Workspace JSON | Keep the editable source, settings and custom tokens. | Import back into the studio, or share a link containing the workspace. |
| Native platforms | The engine exports Android XML, SwiftUI, Flutter and Jetpack Compose. | Wire the generated values into platform theme handling and verify units and resolved colors. |
The engine’s “Figma / W3C” target uses an older token shape with hex color strings. Check your importer’s expected format; it is different from the typed DTCG 2025.10 export and from the Figma variables request here.
Put it to work
From brief to commit.
Carry your seed and naming into the design engine for a different brief or native exports.
Set the brief
Choose a seed, a contrast target and whether you ship high-contrast modes. The studio generates ramps, typography, spacing, radii, shadows and motion.
Choose token naming
Set case and prefix before exporting. Trace the important roles in the graph and test the preview in every mode.
Inspect the matrix
Check each foreground on each surface, including muted text and controls, and look again under simulated color vision. Recheck actual pages after integrating the tokens.
Review and export
Clear the health check, read the changes, copy the changelog, then copy or download your format and save the share link with the source.
Review what changed
Diff names, values and aliases against the last release with a snapshot. Keep mode behavior in one source so framework outputs stay consistent.
References
Go to the source.
The DTCG format is a Community Group specification. Check the exact version your tools support.
Keep learning on Auric Artisan
Format and framework references
- Design Tokens Format Module 2025.10designtokens.org
- Figma REST API: variablesfigma.com
- MDN: light-dark()developer.mozilla.org
- MDN: prefers-contrastdeveloper.mozilla.org
- Tailwind CSS: theme variablestailwindcss.com
- Tailwind CSS v3: theme configurationv3.tailwindcss.com
- WCAG 2.2: understanding contrast minimumw3.org
- WCAG 2.2: understanding contrast enhancedw3.org