Unified design tokens that aligned Amazon’s product teams
Amazon Devices and Services
Six device teams, six design systems, six incompatible ways of naming a design token. I sat on the central design systems team and led the effort to replace them with one. What came out was a naming framework: a short set of rules and a builder that turned a use case into a compliant name.
Teams asked for tooling. The problem was naming.
The teams surfaced concrete asks: linters, automation, analytics. Each was real, and each was a symptom of the same cause: six token frameworks, each with its own vocabulary, so one idea carried a different name on every team. Color produced the most questions.
How do I know it's even a token versus a unique style?
Unique color names, versus flat out saying gray?
How do I do color increments? Random values, 10s, 100s?
Three months to replace six opinions with one
The work ran for almost a single quarter: discovery, research and evaluation, then framework design and rollout. One rule throughout: evidence before opinion, and don't kill what already works.
Tenets, because naming is an argument
Naming was the most opinionated part of a design system, so we set tenets first to help settle debates: the standard a name had to meet. The architecture came out of a week-long session with seven designers, design technologists and engineers.
The rules that made names predictable
1. Make a token look like a token
Every token carries a prefix, so it's obvious at a glance whether something is a token or a one-off style.
2. Use words people already know
Four conventions, all built on words teams already used:
- Color: familiar names, never invented ones
- Type styles: always
text - Anything dimensional (spacing, radius, icon):
size - Size variants: t-shirt sizing, because teams already used it
3. Name the intent, not the appearance
The longest argument was over one word: light. Light meaning what: the light theme, or a light color? The two readings point in opposite directions, and flip the moment the theme does. A token named for how it looks stops being true once its context changes. inverse names intent instead: the opposite of the default. It stays correct in every theme, because it describes a relationship, not a result.
Making it cheap to adopt
Most teams wanted to describe a use case and get a name back, not learn a framework. So I built a token name builder: a spreadsheet with formulae and data validation that returned a valid name from a few answers.
Rollout moved outward: my team, then the product teams, then the wider devices division.
Results
- Half of the six device teams adopted the naming framework
- 500+ consistent tokens across those teams, built on a shared vocabulary
- Cross-team collaboration on a shared set of tokens, where silos had held before
Half was a real milestone: no two teams had shared anything before. Adoption would have gone further, but some teams had to refocus under time and resourcing constraints.
Takeaways
- The ask is rarely the problem. Teams asked for linters, automation and analytics. Building any would have just automated a broken vocabulary.
- The builder should have been real tooling. A spreadsheet proved the framework worked inside the quarter, but engineering support would have produced usable tokens, not just their names.
- Ownership capped the reach. The framework stayed with the central team. Opening it to contribution would have spread it further and let teams fix each other's problems.