Design tokens: understand the structure first

Nate Baldwin argues that design tokens should emerge from reusable interface structures, rather than being created through naming conventions. His team at Adobe Spectrum identified recurring patterns before deciding which design decisions needed tokens. Which makes sense. But the process was messier than “structure first” suggests. You cannot get around that. His team began with semantic names like “gap-tight” and “gap-loose,” then discovered through discussions with designers and engineers that people thought about spacing in terms of relationships, such as the space between a label and a field. Naming debates helped them discover the structure.

Arguments about token names are often disagreements about the design system itself. Teams may have different ideas about what should be shared, how components relate, and where responsibilities belong. No convention or tool can determine the right structure for every team.

The challenge is finding the balance between overly generic tokens and overly specific component tokens. Shared structural patterns can help, but in the end there are subjective decisions that might follow patterns and might not even be worth deliberation.