Design token oltre il colore: comportamento e contesto nel 2026

Un token di comportamento è un design token che descrive come si muove un'interfaccia, non come appare da ferma: quanto dura una transizione, che curva di easing segue, quanto aspetta prima di partire. Il token di contesto è la stessa idea sull'altro asse: la modalità che decide quali valori valgono quando un componente finisce in tema scuro, dentro una tabella più fitta o sotto un secondo brand. Il formato stabile del Design Tokens Community Group definisce 13 tipi di token. Uno solo è il colore.

Quasi tutti i sistemi si fermano a tre: colore, misura, tipografia. Basta a descrivere una schermata immobile. Non dice niente su cosa succede fra due schermate e niente su cosa cambia quando lo stesso pulsante finisce in un layout compatto o davanti a chi ha chiesto al sistema operativo di smettere di muovere le cose. In quei due vuoti il design system torna ai valori scritti a mano, un componente alla volta.

La versione breve

• Sette tipi primitivi. color, dimension, fontFamily, fontWeight, duration, cubicBezier, number.
• Sei tipi compositi. strokeStyle, border, transition, shadow, gradient, typography.
• Il comportamento vive in tre di questi. duration, cubicBezier e il composito transition che li richiama entrambi.
• Il contesto non è un tipo. È lo strato di modalità che decide su quale valore si risolve un token: tema, brand, densità, motion ridotto.
• I tempi si tokenizzano, la coreografia no. Lo dice la specifica stessa, e quel limite decide come si documenta il motion.

Cosa ha standardizzato davvero la 2025.10

Il Design Tokens Community Group ha pubblicato la versione 2025.10 il 28 ottobre 2025: la prima specifica stabile dopo anni di bozze. Ci hanno lavorato più di venti fra editor e autori, con contributi da Adobe, Google, Microsoft, Figma, Salesforce, Shopify, Penpot e altri. Le implementazioni di riferimento esistono già in Style Dictionary, Tokens Studio e Terrazzo.

Due dettagli di quella release contano, se il comportamento ti interessa.

La durata non è più una stringa. Le bozze precedenti accettavano "100ms" e lasciavano a ogni strumento il compito di interpretarla. Il formato stabile richiede un oggetto con un value numerico e una unit che può essere ms o s.

{
  "duration": {
    "quick":  { "$type": "duration", "$value": { "value": 100, "unit": "ms" } },
    "settle": { "$type": "duration", "$value": { "value": 1.5, "unit": "s" } }
  }
}

L'easing è un array di quattro numeri, non una funzione CSS. Il tipo cubicBezier contiene [P1x, P1y, P2x, P2y]. Le coordinate x stanno nell'intervallo fra 0 e 1, le y non hanno limiti, ed è così che si scrive una curva con rimbalzo.

{
  "easing": {
    "emphasized": { "$type": "cubicBezier", "$value": [0.2, 0, 0, 1] }
  }
}

Il tipo composito transition tiene insieme i due. Prende una duration, un delay e una timingFunction, e ognuno dei tre può contenere un valore letterale o un riferimento a un altro token. Il riferimento è tutto il senso dell'operazione: cambi duration.quick una volta e si muovono tutte le transizioni costruite su quel valore.

{
  "transition": {
    "emphasis": {
      "$type": "transition",
      "$value": {
        "duration": "{duration.quick}",
        "delay": { "value": 0, "unit": "ms" },
        "timingFunction": "{easing.emphasized}"
      }
    }
  }
}

Perché il motion sta nello strato dei token

Guardiamo un sistema che l'ha già fatto. Material Design 3 pubblica il motion sotto forma di token: quattro famiglie di durata (short, medium, long, extra long) da quattro passi ciascuna, da 50ms fino a 1000ms, più due set di easing, standard ed emphasized. L'easing emphasized è cubic-bezier(0.2, 0, 0, 1).

Sono una ventina di decisioni con un nome, prese una volta sola, da persone che le hanno provate su componenti veri. L'alternativa è quello che contiene la maggior parte dei codebase di prodotto: 250ms in un componente, 300ms in quello dopo, 0,2s in un terzo perché quel pomeriggio qualcuno scriveva in secondi. Nessuno l'ha deciso. Si è accumulato.

Quando la durata diventa un token, tre cose si semplificano. La si può controllare: una regola di lint o un grep sui valori ms scritti a mano nel CSS dei componenti restituisce un numero che puoi seguire nel tempo. La si può cambiare da un punto solo, così "l'app sembra lenta" ha un posto dove andare invece di quaranta. E quando un designer e uno sviluppatore discutono di velocità, discutono di un passo con un nome e non di un aggettivo.

Quello che esce dalla pipeline non ha niente di esotico, ed è esattamente il punto.

:root {
  --duration-quick: 100ms;
  --easing-emphasized: cubic-bezier(0.2, 0, 0, 1);
  --transition-emphasis: 100ms cubic-bezier(0.2, 0, 0, 1);
}

Quello che un token di transizione non riesce a dire

Il limite c'è ed è scritto dentro la specifica. La sezione sulle transizioni porta con sé una issue aperta che chiede se quei parametri servano davvero da soli, visto che non dicono quale proprietà viene animata né qual è lo stato iniziale e quale quello finale.

Quindi un token di transizione dice: 200 millisecondi, questa curva, nessun ritardo. Non dice: opacità più uno scostamento verticale di 8px, sul pannello che entra da destra, sfalsato di 40ms per riga. La coreografia resta nel codice del componente. Si tokenizzano i tempi, si documenta la coreografia, e si smette di pretendere che il file dei token contenga una specifica di motion. Chi ignora questo confine finisce per inventare nomi come transition-modal-enter-stagger, che è una decisione di componente travestita da token.

Contesto: modalità, densità e il secondo brand

La release 2025.10 ha aggiunto il supporto al theming e al multi-brand, così che chiaro e scuro, varianti di accessibilità e temi di brand stiano in una sola struttura di file invece che in file duplicati. Questo dal lato formato. Dal lato strumenti la forma è un'altra.

In Figma l'equivalente sono le modalità su una collezione di variabili: ogni modalità contiene un valore per variabile e quante modalità hai per collezione dipende dal piano. La trappola è il calcolo combinatorio. Dentro una collezione le modalità sono piatte e indipendenti, quindi brand per tema per densità è una moltiplicazione, non una pila. Tre brand, due temi e due densità fanno dodici colonne da tenere in ordine, e dodici colonne non le tiene in ordine nessuno a mano.

Due regole rendono la cosa sostenibile. Ogni dimensione nella sua collezione, così brand, tema e densità restano separabili invece di collassare in una griglia sola. E niente dimensioni nuove se non sai dire chi le usa. La densità è un buon esempio di dimensione che serve davvero: la riga di una tabella a 44px in versione comoda e a 32px in versione compatta è un token dimension con due valori di modalità, e toglie di mezzo un'intera famiglia di eccezioni sugli spazi.

Il motion ridotto è un contesto, e vince sugli altri

prefers-reduced-motion legge un'impostazione di accessibilità di sistema che l'utente ha già scelto, su macOS, Windows, iOS, Android o Linux. MDN la descrive come il segnale che quella persona vuole ridurre al minimo il movimento non necessario. Ingrandimenti e spostamenti di oggetti grandi possono provocare disturbi a chi soffre di problemi vestibolari: per questo il W3C pubblica l'uso di questa media query come tecnica WCAG.

In un sistema di token la cosa va gestita alla radice, come sovrascrittura dei valori, non come una seconda serie di durate sparsa dentro i componenti.

@media (prefers-reduced-motion: reduce) {
  :root {
    --duration-quick: 0.01ms;
    --duration-settle: 0.01ms;
  }
}

Meglio 0.01ms che 0. Una transizione di durata zero non emette mai transitionend, e il JavaScript che aspetta quell'evento resta appeso. Due avvertenze da mettere nella documentazione: motion ridotto vuol dire meno movimento non necessario, non zero feedback, quindi un cambio di stato deve restare percepibile in altro modo, di solito con il colore o con la posizione. E l'impostazione va attivata a mano nel sistema operativo, quindi molte persone a cui servirebbe non l'hanno accesa. È un pavimento, non un sondaggio.

Quando servono i token di comportamento e quando no

Servono quando almeno due di queste cose sono vere: pubblichi su più di una piattaforma, mantieni più di un brand o di un tema, il codice di interfaccia lo scrivono più di due persone, oppure qualcuno ha già aperto una segnalazione dicendo che il prodotto sembra incoerente. Il multi-brand è il segnale più forte. Nel momento in cui esiste un secondo brand, ogni durata scritta a mano è un conflitto di merge che aspetta il suo turno.

Non servono se hai un prodotto solo, uno sviluppatore solo e meno di dieci stati animati. A quella scala un blocco di custom property CSS in un file è tutto il sistema, e una pipeline DTCG con build step è un costo che paghi ogni giorno e che non ti restituisce niente. Abbiamo lavorato in entrambi i modi. La differenza non è quanto sei sofisticato, è quante persone devono mettersi d'accordo.

Nomi che dicono il ruolo, non il valore

duration-fast sopravvive. duration-150 diventa una bugia la prima volta che qualcuno lo porta a 120ms senza rinominarlo, e rinominarlo significa toccare tutti i consumatori. Vale la stessa regola dei livelli di colore: i primitivi possono essere letterali, i token semantici devono dire l'intenzione. Un test che funziona è leggere il nome ad alta voce in code review e chiedersi se dice a cosa serve quel valore. duration-quick passa. duration-modal passa. duration-200-b no.

La scala va tenuta corta. Cinque o sei passi di durata coprono quasi ogni interfaccia, e ogni passo in più è una decisione che qualcuno sbaglierà alle sei di un venerdì.

Dove si incastra nel resto del sistema

I token di comportamento e di contesto poggiano sulla stessa struttura a tre livelli di tutto il resto, quindi il lavoro sui nomi viene prima: in convenzioni di naming dei design token trovi la divisione fra primitivi, semantici e di componente. Se stai ancora decidendo cosa sia un token rispetto agli strumenti che già usi, design token, variabili CSS e Tailwind copre quel terreno. Sul motion, la revisione da fare prima del rilascio sta in animazione funzionale UI. E l'ordine di costruzione complessivo, con motion e densità al posto giusto rispetto alle altre categorie, sta in struttura di un design system.