2 posts tagged with "design-tokens"

Most themes start in the wrong place.

They start with a palette.

Then someone chooses a type scale, a spacing ramp, a radius scale, a shadow system, and a handful of component defaults. If the result looks polished enough, the theme is treated as done.

But a theme is not done when its values look good in isolation.

A theme is done when it reliably organizes perception, attention, action, meaning, risk, and time across a product.

That is the harder problem.

Spacing should communicate what belongs together. Sizing should communicate what can be acted on. Typography should govern rhythm and hierarchy. Radius should express material and posture. Color should communicate meaning through valid pairs. Motion should explain causality. Focus should preserve navigation. Elevation should express functional distance.

A good theme is not a skin.

A good theme is a perceptual operating system.

It decides what the user sees first, what feels related, what feels available, what feels risky, what feels disabled, what feels elevated, what deserves attention, and what should remain quiet.

Design tokens made visual decisions portable.

Now themes need to make perception governable.

Most design systems do not fail because they lack components. They fail because they never define the layer that tells tokens, components, and product code how meaning should flow through the system.

Teams usually do the visible work. They define foundations, create tokens, build component libraries, and document usage. But when the semantic contract remains implicit, the system slowly drifts.

APIs stop lining up. Variants stop meaning the same thing across components. Tokens get bypassed. Over time, the design system collapses into a themed styling library rather than a true design language.

The failure is not visual first. It is semantic.