Struttura di un design system: le 7 categorie e l'ordine

Un design system scalabile è fatto di sette categorie: token, componenti, pattern, layout, accessibilità, documentazione e governance. Averle tutte non è la parte difficile. Lo è costruirle nell'ordine giusto. È lì che i sistemi deragliano.

Costruiamo e gestiamo design system su più di dieci progetti. Lo stesso problema torna ogni volta: le parti ci sono, ma sono state aggiunte nell'ordine sbagliato, così ognuna lavora contro le altre. La libreria di componenti arriva prima del livello dei token. L'accessibilità diventa un controllo finale. La governance è un ripensamento. Il sistema funziona il primo mese e si disallinea entro il dodicesimo. Qui sotto trovi le sette categorie nell'ordine in cui le costruiamo, con l'errore che ciascuna evita.

Come abbiamo scelto le sette

Tre prove decidono se una cosa merita una categoria a sé. Deve essere richiamata dalle categorie costruite dopo. Deve fallire in modo evidente quando manca. E deve avere un proprietario, una persona, non cinque team. Quello che non supera le tre prove è un pezzo di un'altra categoria, non una categoria.

1. Design token (i primi da costruire)

I token sono i valori con un nome da cui legge tutto il resto. Hanno tre livelli. I token primitivi tengono i valori grezzi (un blu è blue-600 = #1A73E8). I token semantici danno un'intenzione (color-primary = blue-600). I token di componente legano l'intenzione a un contesto (button-bg = color-primary). Lo scopo dei tre livelli è una modifica sola: cambi un colore di brand aggiornando un unico token semantico, e ogni componente che lo legge cambia con lui.

Non è più una convenzione fatta in casa. Il Design Tokens Community Group del W3C ha pubblicato la prima versione stabile della specifica a ottobre 2025, e Figma, Sketch, Tokens Studio e Style Dictionary leggono lo stesso formato. I token vanno per primi perché tutto il resto li richiama. Parti dai componenti e finisci per scrivere i valori esadecimali a mano, poi un rebrand ti tocca trecento file invece di tre.

2. Componenti (i secondi)

I componenti sono le parti di interfaccia riutilizzabili: bottone, campo, card, modale, navigazione. Il modello atomico di Brad Frost è la mappa mentale più diffusa: gli atomi compongono le molecole, le molecole compongono gli organismi. Il compito di questa categoria è avere una sola versione del bottone, non quattordici versioni che si sono allontanate su quattordici schermate.

L'errore è costruire questa categoria per prima. Una libreria di componenti senza un livello di token sotto regge per sei mesi, poi ogni valore va riportato dentro i token a mano. Quel lavoro di recupero è la causa più frequente di disallineamento che vediamo. Il secondo errore è il numero: un sistema con trecento componenti è più difficile da tenere coerente di uno con sessanta.

3. Pattern (i terzi)

I pattern sono decisioni di UX, non parti di interfaccia. Dicono come dovrebbe funzionare un flusso: validazione dei form, navigazione, stati vuoti, gestione degli errori, conferma di un'azione distruttiva. Nathan Curtis di EightShapes traccia la linea con chiarezza: i componenti sono come una cosa funziona, i pattern sono come dovrebbe funzionare. Un componente si costruisce e si rilascia. Un pattern è una guida che applichi mentre costruisci.

Servono abbastanza componenti prima che scrivere i pattern abbia senso, ed è per questo che arrivano terzi. Salta i pattern e ottieni un sistema con bottoni coerenti e flussi incoerenti. Ogni team inventa il suo comportamento per gli errori di un form, e il prodotto sembra cucito insieme anche quando i pixel combaciano.

4. Layout (in parallelo ai componenti)

Il layout è la griglia, la scala di spaziatura applicata alla struttura della pagina, le regole responsive e un piccolo set di template. Legge dagli stessi token di spaziatura dei componenti, quindi può crescere insieme alla seconda categoria invece di aspettare.

Qui l'errore è sottile. Senza una categoria di layout condivisa, due schermate fatte da due persone usano 24px e 20px di margine per lo stesso scopo. L'incoerenza non si vede in revisione ed è evidente per chi passa da una pagina all'altra.

5. Accessibilità (dentro ogni categoria, non per ultima)

L'accessibilità è l'unica categoria che non è una fase. È un vincolo che vive dentro le altre sei. I rapporti di contrasto stanno nel livello dei token. Il focus e l'ordine da tastiera stanno nei componenti. Gli skip link e i landmark stanno nel layout. L'European Accessibility Act è in vigore in tutta l'Unione da giugno 2025, e questo ha spostato l'accessibilità da optional a soglia di legge per i prodotti venduti in Europa.

L'errore è trattarla come un controllo finale. Una violazione di contrasto messa in un token primitivo è una correzione sola. La stessa violazione scoperta dopo che si è diffusa su quaranta componenti sono quaranta correzioni.

6. Documentazione (in continuo)

La documentazione è ciò che trasforma una libreria di codice in un sistema che usano anche gli altri. La regola di Curtis è quella giusta: parti dalle varianti renderizzate e dal codice copiabile, scrivi le linee guida all'imperativo, sostituisci i muri di testo con contrasti fai-non fare. Un token che nessuno trova viene riscritto a mano. Un componente che nessuno capisce viene rifatto.

L'adozione è il problema che torna in cima alla survey pluriennale sui design system di Sparkbox, e la documentazione debole ne è la causa più comune. Il sistema può essere tecnicamente ottimo e fallire lo stesso, se chi dovrebbe usarlo non capisce cosa esiste o come applicarlo.

7. Governance (definita presto, applicata dal secondo consumatore)

La governance è il modello di contribuzione, lo schema delle versioni e un proprietario con un nome. Risponde a chi può aggiungere un componente, come esce una modifica che rompe la compatibilità, e cosa succede quando due team chiedono la stessa cosa. La definisci presto e cominci ad applicarla nel momento in cui un secondo prodotto dipende dal sistema.

Sparkbox ha rilevato che il 36% dei team non ha un processo definito per accettare i contributi. Senza, il sistema si biforca: ogni team mette una pezza in locale, le pezze divergono, ed entro un anno hai un design system sulla carta e quattro nella pratica.

Le sette categorie in breve

L'ordine di costruzione, in un paragrafo

Prima i token, perché tutto li richiama. Poi componenti e layout, in parallelo, entrambi a partire dai token. I pattern quando hai abbastanza componenti perché la guida significhi qualcosa. L'accessibilità intrecciata in tutte le categorie fin dai token, mai aggiunta alla fine. La documentazione scritta mentre vai avanti, non in coda. La governance definita dal primo giorno e applicata quando arriva il secondo consumatore. Puoi anche saltare l'ordine e rilasciare comunque un sistema. Solo che non scala, e il conto delle riparazioni arriva circa dodici mesi dopo.