Anonymous Design Tokens

The problem

Design tokens primarily use a name (often dash delimited strings) to provide context for the token usage (e.g., slider-handle-border-width-down-small). This approach has served us well until now, but it has some downsides.

• Harder to validate
• A string provides too much freedom
  • Pros:
    • It's allowed us to move quickly
  • Cons:
    • Can make it harder to decide what to name tokens
    • It can make it harder to onboard new designers and developers, both on the design system team and on the products
• General wayfinding

The proposal

Use an object instead of a string with a schema definition to validate token context data.

slider-handle-border-width-down-small

id: 683fb538-290c-423f-990b-d7134e485f51
$schema: adobe/spectrum/schema/0.0.0/token-types/dimension.yml
component: slider
part: handle
property: border-width
value: 7px
options:
  $schema: adobe/spectrum/schema/0.0.0/components/slider.yml
  state: down
  size: small
  platform: mobile

id: c9b7d8d9-c5ba-4d97-a03b-a214104ede23
$schema: adobe/spectrum/schema/0.0.0/token-types/extend.yml
base: 683fb538-290c-423f-990b-d7134e485f51
value: 5px
options:
  platform: desktop

combo-box-visual-to-field-button-quiet

id: ce908a70-5a6b-4fea-a97c-8f0320e3991f
$schema: adobe/spectrum/schema/0.0.0/token-types/spacing.yml
component: combo-box
property: spacing
from: visual
to: field-button
value: 0px
options:
  $schema: adobe/spectrum/schema/0.0.0/components/combo-box.yml
  quiet: true

Missing parts:

• Component Data:
  • Component options
  • Component parts (anatomy)