Un design system non scala se vive solo in Figma o solo nel CSS. Scala quando le decisioni visive diventano token: valori nominati, documentati e riutilizzabili per colori, spaziature, tipografia, raggi, ombre e motion.
I design tokens servono a evitare che ogni componente reinventi gli stessi valori con nomi diversi. Se un colore primario cambia, non vuoi cercare codici esadecimali nel repository: vuoi modificare una decisione alla fonte.
Aggiornamento luglio 2026
I design tokens non sono più solo una convenzione interna. La Design Tokens Community Group specification ha pubblicato il draft 2025.10 il 17 giugno 2026: non è uno standard W3C definitivo, ma è ormai il riferimento pratico per interoperabilità tra strumenti. La direzione è chiara: token in JSON, proprietà come $value, $type, $description, alias, gruppi e formati esportabili.
La best practice attuale è mantenere tre livelli: token primitivi, token semantici e token di componente. I primitivi descrivono la palette o la scala; i semantici descrivono uso e intenzione; i token di componente traducono decisioni locali senza duplicare valori. In Figma, Variables e modes vanno allineati al codice, non trattati come fonte separata.
Per il frontend, esporta in CSS custom properties e mantieni un changelog dei token deprecati. Il problema da evitare è la crescita incontrollata: ogni nuovo token deve avere nome, uso e owner. Questo è lo stesso principio che guida un buon lavoro di UI/UX design: meno valori arbitrari, più decisioni riutilizzabili.
Cosa sono i design tokens
Un token è una variabile che rappresenta una scelta di design. Può essere primitivo:
--blue-600: #2563eb;
--space-4: 1rem;Oppure semantico:
--color-action-primary: var(--blue-600);
--space-card-padding: var(--space-4);I token primitivi descrivono il valore. I token semantici descrivono l'uso. In un sistema maturo servono entrambi.
Naming semantico
La differenza tra --gray-900 e --color-text-primary è importante. Il primo dice com'è fatto il valore. Il secondo dice a cosa serve. Lo stesso ragionamento aiuta anche quando devi scegliere tra block theme e tema classico, perché theme.json funziona bene solo se le decisioni sono già chiare.
Il naming semantico rende possibili dark mode, rebranding e temi multipli senza riscrivere componenti. Un bottone non deve sapere se il testo è grigio, bianco o nero. Deve usare --button-primary-fg. Questo riduce anche problemi di contrasto e accessibilità.
Una buona struttura può essere:
- primitivi:
--color-neutral-900,--space-6,--font-size-300; - semantici globali:
--color-bg-page,--color-text-muted; - componenti:
--button-bg,--card-border,--input-focus-ring.
Formati: CSS, JSON e Figma
Nel codice frontend, le CSS custom properties sono spesso la scelta più naturale. Permettono override a runtime, temi con data-theme e integrazione diretta nei componenti.
In sistemi più grandi, i token possono nascere in JSON e passare da strumenti come Style Dictionary per generare CSS, file per app native o documentazione. In Figma, le Variables aiutano a mantenere allineati designer e sviluppatori.
La cosa importante non è lo strumento. È avere una fonte di verità chiara e un processo per aggiornarla.
Multi-brand e dark mode
Con i token, il theming diventa più gestibile. Un esempio semplice:
:root {
--color-bg-page: #ffffff;
--color-text-primary: #111827;
}
[data-theme="dark"] {
--color-bg-page: #0f172a;
--color-text-primary: #f8fafc;
}Il componente non cambia. Cambia il contesto. Questo è essenziale per prodotti white-label, dashboard multi-brand e siti con dark mode.
Evitare la deriva tra design e codice
La deriva nasce quando Figma dice una cosa, il codice ne fa un'altra e nessuno sa quale sia la versione corretta. I token riducono il problema, ma non lo eliminano da soli.
Servono:
- review dei token prima di aggiungerne di nuovi;
- nomi stabili;
- documentazione minima;
- mapping tra Figma e codice;
- deprecazione dei token vecchi;
- controlli nei componenti.
Un sistema pieno di token duplicati è solo caos con nomi più eleganti.
Casi d'uso reali
I token sono utili quando devi fare un rebranding rapido, introdurre dark mode, creare varianti white-label, mantenere coerenza tra sito e app o ridurre discussioni su dettagli visivi ripetuti.
Sono meno urgenti per un sito statico piccolo, ma anche lì una base di custom properties ben nominata evita CSS fragile.
Conclusione
I design tokens rendono il sistema visivo più prevedibile. Non sostituiscono il design, ma lo traducono in decisioni applicabili. Il risultato è un'interfaccia più coerente, più facile da modificare e meno dipendente dalla memoria di chi ha scritto il primo CSS, soprattutto quando estetica e performance del design system devono restare allineate.