Design tokens: the common language between design and development

Designers and developers often talk about the same things using different words: what design calls "corporate blue" becomes a hex code in Figma and a uniquely named variable in the Drupal theme. Information gets lost at every step, and over time, no one remembers which values were deliberate choices and which were accidents.

Design tokens solve this problem by turning design decisions into a shared vocabulary: every color, typography style, or spacing value carries a name, a value, and an intent. This common language is agreed upon by design and frontend teams before hand-off, not after.

Regardless of who creates the design—whether it’s the internal team, an external agency, or the client—the token acts as the contract between all parties, replacing static PDF style guides with a version-controlled file as the single source of truth.

In this session, we will walk through the entire process, from variables in Figma or Penpot to Drupal components, following the W3C DTCG standard (stable since October 2025). We will explore why this structured vocabulary is even more crucial now that AI agents generate code, and how it applies to two common scenarios: multisite platforms, where each site defines only what changes, and products, where design defines customizable parameters while clients adjust values without touching code.

We will wrap up with what Drupal offers today—from contrib modules to the new Core Design Tokens API—along with clear criteria to determine when tokens are worth implementing.

A session for frontends, themers, designers, and product owners. No prior experience with design tokens is required.