openskills.info
Design Tokens logoCourse Preview

Design Tokens

Design tokens are named, machine-readable records of visual design decisions such as colors, spacing, type sizes and animation timing. Designers and developers store them once, in a shared format, and build tools translate them into the variables each platform uses, so web, iOS and Android apps stay visually consistent and a brand or theme change happens in one place instead of hundreds.

itWeb development

Don't Panic: Design Tokens

A design token is a design decision that has been given a name and written down as data. The blue of the main button, the gap between two cards, the speed of a fade: each becomes an entry such as color.action.background with a value behind it. That is the whole trick. The rest of the field is about what happens once a name exists.

The problem it solves is copying. The same blue has to live in a design file, a website, an iPhone app and an Android app. Before tokens, someone typed it into each place by hand, and the four copies slowly stopped agreeing. Tokens keep one source and let a build tool rewrite it into whatever each platform speaks, from CSS to Swift. Fewer people squinting at two blues and asking which one is real.

Three ideas carry most of the weight. First, a token can point at another token; that pointer is an alias, written as the other token's name in curly braces. Second, aliases stack into tiers. Primitive tokens hold the raw palette (color.blue.600), semantic tokens say what a value is for (color.action.background), and component tokens say which part of which component uses it. Designers apply the semantic layer and leave the primitives backstage. Third, a theme changes values, never names. Dark mode keeps color.surface.default and swaps what it points at.

There is even a standard. The W3C Design Tokens Community Group published its first stable version, 2025.10, in October 2025. A token file is JSON, and a token is any object with a $value property; everything else is a group that organizes tokens into a dotted path. A separate Resolver module describes themes as sets and modifiers, and when two sources disagree, the later one wins.

The surprise is where things break. A token pointing at a name that does not exist stops the build, loudly, which is the helpful kind of failure. The quiet kind happens in the browser. A missing CSS custom property, the double-hyphen variables tokens usually become on the web, makes the element fall back to some other color, and nothing anywhere complains. Another quiet one: some native transforms assume sizes arrive in rem, so an 8px spacing value can reach an iPhone sixteen times larger than intended.

Also worth knowing early: tokens store values, not behavior. A token can say what color a button is. It cannot say when the button is disabled or how it answers a keyboard. That is the job of components and their documentation.

Where to go next depends on the question. The Intro walks through the file format, tiers, themes and the build pipeline end to end. The Cheatsheet holds the reserved $ properties, value shapes and the transform and format names. The Field Notes cover what the tidy diagrams leave out, such as why renaming a token costs far more than changing its value. The Exercise has you build a light and dark theme with Style Dictionary and break a reference on purpose, which is more satisfying than it sounds.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources