Un design system è l'insieme di decisioni, componenti e istruzioni con cui chi progetta e chi sviluppa costruisce interfacce coerenti senza ripartire ogni volta da zero: colori, caratteri, spaziature e pulsanti si decidono una volta e si riusano ovunque, nel file di design come nel codice. Conviene quando un prodotto digitale cresce, cambia spesso o ci lavorano più persone; per un sito di poche pagine basta di solito una guida di stile fatta bene.
Cosa c'è dentro un design system?
I contenuti variano da un'azienda all'altra, ma un design system completo ha cinque parti che lavorano insieme:
- token: le decisioni di base espresse come valori con un nome, per esempio il colore primario, la scala dei caratteri, le spaziature, i raggi degli angoli, le durate delle animazioni
- componenti: pulsanti, campi, schede, menu, ciascuno con tutti i suoi stati (normale, al passaggio del mouse, selezionato con la tastiera, disattivato, in errore)
- pattern: combinazioni ricorrenti di componenti, come un modulo di contatto, un filtro di ricerca o una procedura di registrazione
- linee guida d'uso: quando usare un componente e quando no, come scrivere le etichette, quali requisiti di accessibilità rispettare
- regole di gestione: chi approva le modifiche, come vengono rilasciate, dove si segnala un problema
Il punto di partenza sono i token, perché permettono di cambiare una decisione in un solo posto. Conviene organizzarli su due livelli: i valori primitivi, come la tavolozza completa dei blu, e i valori semantici, come il colore del testo principale o quello degli errori, che rimandano ai primitivi. La specifica dei Design Tokens chiama questi rimandi alias: se il testo principale punta al nero della palette, cambiando il nero cambia tutto ciò che lo usa.
Per ordinare i componenti si può usare l'atomic design di Brad Frost, un metodo in cinque livelli: atomi, molecole, organismi, template e pagine. Un campo di testo è un atomo, il campo con il suo pulsante di ricerca una molecola, l'intestazione del sito un organismo. Serve soprattutto a dare a tutti lo stesso vocabolario, così chiunque nel team trova un pezzo senza chiedere.
Guida di stile, UI kit, design system: sono la stessa cosa?
Sono parole che si usano come sinonimi, ma indicano oggetti diversi. Il manuale di brand identity stabilisce logo, colori, caratteri e tono del marchio su tutti i mezzi, carta compresa. La guida di stile traduce quelle regole per il web. Un UI kit è una raccolta di componenti grafici, spesso solo nel file di design, senza regole d'uso né codice. La libreria di componenti, al contrario, è codice.
Il design system le tiene insieme e le mantiene allineate nel tempo. Per questo va trattato come un prodotto interno, con un responsabile e un calendario di aggiornamenti.
Alla tua azienda serve davvero?
Il vantaggio cresce con la complessità, e con lui cresce il lavoro per mantenerlo. Un design system completo ha senso se ti ritrovi in almeno una di queste situazioni:
- hai più prodotti digitali (sito, area clienti, app, e-commerce) che devono sembrare della stessa famiglia
- sulla stessa interfaccia lavorano più persone o più fornitori, anche in momenti diversi
- il prodotto evolve con rilasci frequenti, come una web app o un servizio in abbonamento
- gestisci più marchi o linee di prodotto sulla stessa base tecnica
- devi garantire un livello di accessibilità verificabile su tutte le schermate
Due siti della stessa piattaforma, uno per i cittadini e uno per i professionisti, sono un caso tipico: per Bravoavvocato e Bravoavvocato PRO il redesign, progettato su Figma da Federica De Fraia e tradotto in codice da noi, comprende anche il design system.
Per un sito vetrina di poche pagine o una landing di campagna, invece, un sistema completo è più di quanto serve. Lì basta una guida di stile con i token principali e una manciata di componenti, definita durante il progetto di web design, che resta una buona base se un giorno il progetto cresce.
Come si costruisce, partendo da quello che hai già?
Quasi nessuno parte da un foglio bianco: c'è un sito, magari un'app, qualche presentazione. Un ordine che funziona è questo:
- inventario: raccogli tutte le varianti esistenti di pulsanti, colori, titoli e moduli, è il modo più rapido per vedere doppioni e incoerenze
- token: definisci primitivi e semantici, con nomi che descrivono l'uso (colore dell'errore) e non l'aspetto (rosso scuro)
- componenti: parti da quelli che usi di più e disegna tutti gli stati, compresi errore e disattivato
- documentazione: accanto a ogni componente, quando usarlo, quando no, esempi e note di accessibilità
- codice: token trasformati in variabili, per esempio le proprietà personalizzate CSS, e componenti raccolti in una libreria
- rilascio: una prima versione piccola e usata subito, poi ampliata con il lavoro reale
Sul lato design, Figma permette di esprimere i token come variabili con più modalità, per esempio tema chiaro e tema scuro, e di estendere una raccolta di variabili per gestire più marchi. Componenti, stili e variabili si pubblicano poi in una libreria condivisa: quando la libreria cambia, chi la usa in altri file vede gli aggiornamenti e può accettarli.
Come restano allineati il file di design e il codice?
Il rischio principale è che il file di Figma dica una cosa e il sito un'altra: un colore aggiornato solo da una parte, un componente modificato in produzione e mai ridisegnato. La soluzione è avere un'unica fonte per i token, da cui si generano sia le variabili di design sia quelle del codice.
Da ottobre 2025 esiste un formato comune per farlo. Il Design Tokens Community Group, un gruppo che lavora nell'ambito del W3C, ha pubblicato la prima versione stabile della specifica, un formato JSON che strumenti come Figma, Penpot, Sketch, Tokens Studio e Style Dictionary supportano o stanno adottando. Significa meno conversioni a mano e meno dipendenza da un singolo programma.
Per chi sviluppa, il catalogo può vivere in Storybook, un ambiente separato dall'applicazione dove ogni componente si vede e si prova da solo, in tutte le sue varianti. Le stesse schede, che Storybook chiama storie, servono per sviluppare, testare e documentare, così la documentazione non resta indietro rispetto al codice.
Chi lo mantiene quando il progetto è finito?
Un design system senza responsabile invecchia in fretta: ogni urgenza produce un'eccezione, e dopo qualche mese le eccezioni sono la regola. Servono tre cose. Una persona o un piccolo gruppo che decide cosa entra. Un modo per proporre modifiche, come la sezione Come contribuire del design system pubblico italiano. E un sistema di versioni, per esempio il versionamento semantico: il primo numero cambia quando una modifica non è compatibile con la versione precedente, il secondo quando si aggiunge qualcosa senza rompere nulla, il terzo per le correzioni.
Un buon esempio è il GOV.UK Design System, il sistema dei servizi pubblici britannici: quando a giugno 2025 GOV.UK ha avviato il rinnovo del proprio marchio, il team ha rilasciato più versioni della libreria di codice, GOV.UK Frontend, per aiutare i singoli servizi ad aggiornarsi: il nuovo marchio arriva così come un aggiornamento da installare.
Cosa deve esserci nella consegna?
Che lo realizzi un'agenzia o un team interno, a fine lavoro dovresti avere in mano:
- la libreria di Figma con componenti e variabili, organizzata e pubblicata
- il file sorgente dei token, meglio se nel formato della specifica Design Tokens, e la sua conversione per il codice
- la libreria di componenti nel repository del progetto, con la documentazione (in Storybook o strumento equivalente)
- un livello minimo di accessibilità verificato componente per componente, come contrasto, focus visibile e dimensioni dei bersagli secondo le WCAG 2.2
- le linee guida d'uso e il registro delle modifiche con le versioni
- file e codice nei tuoi account, come dovrebbe prevedere il contratto di sviluppo
Quali design system pubblici conviene studiare?
Prima di costruirne uno conviene guardare come lavorano quelli documentati in pubblico. Il design system .italia, curato dal Dipartimento per la trasformazione digitale e da AgID, è il riferimento per i siti della pubblica amministrazione e dei suoi fornitori: fondamenti, componenti e istruzioni pensati per rispettare le Linee guida di design previste dal Codice dell'amministrazione digitale. Il GOV.UK Design System organizza il materiale in stili, componenti e pattern per compiti comuni come inserire nome e indirizzo o creare un account.
Nessuno dei due va copiato così com'è, perché nascono per servizi pubblici con esigenze diverse da quelle di un'azienda. Sono però utili per capire quanto dettaglio serve nella documentazione e come si descrive l'accessibilità di ogni componente.
Design system completo o guida di stile? Dipende soprattutto da quanti prodotti hai e da quante persone ci lavorano: raccontacelo dalla pagina sul branding e ti diciamo da dove partiremmo.
