Design system: cos’è e come funziona
Un design system è l’insieme organizzato di componenti riutilizzabili, token visivi e linee guida che permette a designer e sviluppatori di realizzare prodotti digitali coerenti, mantenendo un’unica fonte di verità condivisa tra progettazione e codice. Non è un singolo file, ma un prodotto che evolve nel tempo con regole di governance proprie.
Design system in sintesi
- Composizione: token, componenti UI, pattern e documentazione formano i quattro livelli operativi.
- Differenza con UI kit: un UI kit è un file statico, mentre il design system include regole, governance e una fonte unica di verità.
- Strumenti principali: Figma per progettazione e token, Storybook o Zeroheight per la documentazione del codice.
- Diffusione: l’83% delle organizzazioni ha un team dedicato al design system nel 2026, con un aumento del 5% rispetto all’anno precedente, secondo il Design Systems Report 2026 – brought to you by zeroheight (2026).
- Caso pubblico italiano: il design system .italia è il riferimento ufficiale per i servizi digitali della Pubblica Amministrazione.
- Costruzione: si parte da un audit dell’esistente, non da un sistema completo al primo tentativo.
Cos’è un design system e da cosa è composto
Un sistema di questo tipo nasce per risolvere un problema concreto: evitare che ogni team ricostruisca da zero bottoni, campi di testo o card già esistenti altrove nel prodotto. È composto da tre elementi che lavorano insieme: un linguaggio condiviso fatto di token e convenzioni di naming, una libreria di componenti riusabili e un insieme di regole che ne definiscono l’uso corretto.
Vale la distinzione terminologica che spesso genera confusione. Un UI kit è un file di progettazione con elementi visivi pronti da copiare, privo di documentazione e di regole di evoluzione. Una component library è invece una libreria tecnica di codice, orientata all’implementazione più che alla documentazione di design. Il design system racchiude entrambi, aggiungendo governance e una fonte unica di verità: quando un token cambia, la modifica si propaga su ogni piattaforma che lo consuma, da Figma al CSS fino alle app native.
Un elemento spesso sottovalutato è la distanza tra “design system esistente” e “design system adottato”. Secondo il Design Systems Report 2026 – brought to you by zeroheight (2026), i professionisti di product design e UX costituiscono circa il 50% dei rispondenti coinvolti nella gestione di questi sistemi, a conferma che la responsabilità non ricade solo sugli sviluppatori ma su un team misto.
I livelli che compongono un design system
Un design system maturo si organizza su tre livelli gerarchici, dal più astratto al più concreto: i design token, i componenti UI e i pattern di composizione.
Design token come fondamenta visive
I design token sono le variabili atomiche del linguaggio visivo: un colore, una spaziatura, una dimensione tipografica, un raggio di bordo. Sono indipendenti dalla tecnologia e possono essere consumati come variabili in Figma, come proprietà personalizzate in CSS, come valori XML su Android o come colori Swift su iOS. Secondo il Design Systems Report 2025 (2025), l’84% dei team ha già adottato i design token come pratica standard, segno che questo livello è diventato il punto di partenza obbligato di qualsiasi sistema moderno.
Componenti UI riutilizzabili
I componenti sono gli elementi di interfaccia costruiti consumando i token: bottoni, campi input, card, modali, menu di navigazione. Un componente ben costruito presenta varianti (primario, secondario), stati (default, hover, focus, disabilitato), dimensioni multiple e accessibilità nativa integrata, con attributi come aria-label e gestione del focus da tastiera.
Pattern come composizioni ricorrenti
I pattern combinano più componenti per risolvere un problema di interfaccia ricorrente: un form di login, una card prodotto, uno stato vuoto, una tabella con filtri e paginazione. Non vivono nella libreria dei componenti, perché troppo specifici, ma nella documentazione, come riferimento per chi deve replicare la stessa soluzione senza reinventarla.
Metodologie usate per progettare un design system
La metodologia più nota per organizzare i componenti è l’atomic design, ideata da Brad Frost, che scompone l’interfaccia in cinque livelli crescenti di complessità.
- Atomi
- gli elementi più piccoli: pulsanti, colori, tipi di carattere, icone.
- Molecole
- gruppi di atomi combinati, come un campo di ricerca con relativo pulsante.
- Organismi
- sezioni complete dell’interfaccia, come un’intestazione o un piè di pagina.
- Template
- la struttura che definisce la disposizione degli organismi nella pagina.
- Pagine
- la realizzazione finale con tutti gli elementi combinati e popolati di contenuto reale.
Accanto all’atomic design esistono approcci complementari: il Design Language System, che si concentra sul linguaggio visivo e sul tono di voce del brand; l’human-centered design, che parte dai bisogni reali delle persone che useranno l’interfaccia; e il design sprint, un formato intensivo per risolvere in pochi giorni un nodo specifico del sistema.
Come costruire un design system passo dopo passo
L’errore più diffuso consiste nel cercare di completare un sistema perfetto al primo tentativo. L’approccio efficace è iterativo: si parte da un nucleo minimo e si espande con l’uso reale del prodotto.
- Fotografare lo stato attuale dell’interfaccia, contando colori, varianti di bottoni e valori di spaziatura effettivamente in uso.
- Estrarre un numero limitato di token essenziali che coprano la maggior parte dei casi d’uso, evitando di partire con centinaia di variabili.
- Costruire i componenti più usati nel prodotto, documentando per ciascuno quando va impiegato e quando va evitato.
- Scegliere un unico luogo di documentazione condiviso tra design e sviluppo, evitando di disperdere le informazioni tra file diversi.
- Avviare l’adozione con un team pilota per alcuni sprint, prima di estendere il sistema a tutta l’organizzazione.
Se il team è piccolo o alle prime armi
Conviene limitare il sistema a token essenziali e a una decina di componenti core, documentati in una pagina condivisa invece che in uno strumento dedicato: il costo di uno strumento complesso non è giustificato finché il prodotto non cresce.
Se il team è distribuito su più prodotti
Diventa necessaria una governance esplicita, con un responsabile o un piccolo gruppo che approva le modifiche ai token e ai componenti condivisi, per evitare che versioni diverse dello stesso elemento convivano nel prodotto.
La fase di documentazione è quella in cui si concentrano gli strumenti dedicati, approfonditi più avanti; la sua corretta impostazione incide direttamente sulla velocità con cui un’architettura dell’informazione coerente si riflette sull’interfaccia finale: approfondisci su architettura dell’informazione e progettazione.
Vantaggi concreti di un design system
I benefici principali riguardano coerenza, velocità operativa e scalabilità del prodotto nel tempo.
| Area | Effetto osservabile |
|---|---|
| Coerenza | Esperienza uniforme su ogni schermata e touchpoint del prodotto. |
| Velocità | Riduzione del tempo di progettazione e sviluppo grazie al riuso dei componenti già testati. |
| Scalabilità | Possibilità di far crescere team e prodotto mantenendo un’unica fonte di verità. |
| Manutenibilità | Una modifica a un componente condiviso si riflette automaticamente ovunque sia implementato. |
| Comunicazione | Linguaggio comune tra designer, sviluppatori e product manager. |
Il beneficio di governance non è però garantito solo dall’esistenza del sistema. Secondo il Design Systems Report 2026 – brought to you by zeroheight (2026), la soddisfazione per il sostegno interno al design system è calata dal 42% al 32% anno su anno, un dato che segnala quanto l’adozione organizzativa resti più complessa della costruzione tecnica del sistema stesso.
Design system .italia per la pubblica amministrazione
Il design system .italia è il primo sistema di progettazione dedicato al mondo della Pubblica Amministrazione italiana e ai suoi fornitori. Fornisce componenti predefiniti e testati, fondamenti su linguaggio e tono di voce, e indicazioni per garantire qualità, accessibilità e inclusività nei siti e servizi pubblici digitali.
L’adozione di queste risorse non è solo una scelta tecnica: risponde ai requisiti previsti dalle linee guida di design emesse secondo quanto definito dall’art. 53 del CAD. Il design system .italia è articolato in quattro aree operative: come iniziare, fondamenti, componenti e come contribuire, pensate rispettivamente per designer, sviluppatori e responsabili di progetto.
Se il progetto riguarda un ente pubblico
La scelta corretta è partire direttamente dalle risorse del design system .italia, già validate per accessibilità e conformità normativa, invece di costruire un sistema proprietario da zero.
Se il progetto è per un prodotto privato o aziendale
Il design system .italia resta un riferimento metodologico utile, ma la struttura dei token e dei componenti va costruita su misura dell’identità visiva specifica del prodotto.
Esempi noti di design system
Alcuni sistemi hanno definito gli standard di settore e vengono presi a riferimento da chi inizia a costruirne uno nuovo.
| Design system | Ambito di riferimento |
|---|---|
| Material Design | Sistema unificato multi-piattaforma sviluppato da Google. |
| Human Interface Guidelines | Linee guida visive per i prodotti dell’ecosistema Apple. |
| Fluent Design System | Sistema visivo sviluppato da Microsoft per i propri prodotti. |
| Carbon Design System | Riferimento per la robustezza in contesti enterprise, sviluppato da IBM. |
| Atlassian Design System | Orientato a documentazione approfondita e pattern per strumenti di produttività. |
| Design system .italia | Sistema pubblico per siti e servizi della Pubblica Amministrazione italiana. |
Strumenti per progettare e documentare un design system
La scelta dello strumento dipende dal punto in cui si colloca il team: progettazione visiva, implementazione in codice o documentazione condivisa.
Figma resta lo strumento più diffuso per la progettazione dei componenti e, dal 2024, per la gestione diretta dei token tramite la funzionalità Variables. Per la parte di codice, Storybook è lo standard per documentare componenti React o Vue in modo interattivo e automatico. Strumenti dedicati come Zeroheight centralizzano documentazione di design e codice in un’unica piattaforma consultabile da tutto il team, mentre soluzioni più semplici come una pagina Figma condivisa o uno spazio di lavoro collaborativo bastano per i progetti più piccoli.
Un aspetto ancora poco sfruttato riguarda l’intelligenza artificiale applicata alla manutenzione del sistema: secondo il Design Systems Report 2025 (2025), solo il 10% dei team utilizza l’AI per documentazione e generazione di idee, un margine di crescita significativo rispetto all’adozione dei token tradizionali. L’implementazione dei token tramite fogli di stile richiama direttamente i concetti dei fogli CSS e delle proprietà personalizzate.
Problemi comuni e quando non serve un design system
Non ogni progetto trae beneficio immediato da un sistema di progettazione strutturato, e anche i sistemi già avviati incontrano ostacoli ricorrenti.
Errori frequenti nell’adozione
Il problema più comune non è tecnico ma organizzativo: un design system che esiste ma non viene usato genera più disordine visivo di quanto ne risolva, perché convivono componenti vecchi e nuovi. Imporre il sistema a tutti i team contemporaneamente, senza un pilota che ne dimostri il valore, è la causa più frequente di abbandono.
Costi di manutenzione nel tempo
Un sistema di progettazione richiede aggiornamenti regolari: token, componenti e documentazione invecchiano insieme al prodotto. Senza un responsabile dedicato alla governance, il sistema smette di rappresentare realmente l’interfaccia in uso.
Quando conviene rimandare la costruzione
Per un prodotto con una sola schermata, un prototipo non destinato a scalare o un team di una sola persona, il costo di costruire un sistema formale supera il beneficio immediato: in questi casi è più utile mantenere una semplice libreria di stili di base, da strutturare in sistema solo quando il prodotto cresce.
Design e design system: termini da non confondere
Il termine “design” indica, in senso generale, l’attività di progettazione di un prodotto, di un servizio o di un’interfaccia; il design system ne è uno strumento operativo specifico, applicato alla coerenza delle interfacce digitali. Ricerche che accostano al termine nomi di località o di settori merceologici, come studi di progettazione locali o produttori di pavimentazioni, si riferiscono ad attività commerciali distinte dal significato qui trattato e non rientrano nell’ambito dei sistemi di progettazione digitale descritti in questo articolo.
Allo stesso modo, domande sulla storia del design, sulle figure più note della disciplina o su metodologie progettuali generali appartengono al campo più ampio del design industriale e grafico, non al design system in senso stretto: quest’ultimo riguarda esclusivamente l’organizzazione di componenti, token e linee guida per prodotti digitali.
Domande frequenti
Cosa si intende per design system?
Si intende l’insieme organizzato di componenti riutilizzabili, token visivi e linee guida che permette a team di design e sviluppo di realizzare prodotti digitali coerenti, scalabili e manutenibili nel tempo, con un’unica fonte di verità condivisa.
Cos’è il design system del Paese?
È il nome con cui viene indicato il design system .italia, il sistema di riferimento ufficiale per la progettazione dei siti e servizi digitali della Pubblica Amministrazione italiana, basato su qualità, accessibilità e inclusività.
A chi è dedicato il design system .italia?
È dedicato alle pubbliche amministrazioni italiane e ai loro fornitori, come punto di partenza per realizzare siti e servizi digitali pubblici conformi ai requisiti di qualità e accessibilità previsti dalla normativa vigente.
Qual è la differenza tra designer e design?
Il design indica l’attività di progettazione nel suo complesso, mentre il designer è la figura professionale che la svolge; il design system, in questo contesto, è lo strumento che il designer utilizza insieme allo sviluppatore per mantenere coerenza nel prodotto digitale.
Come si usa Figma per un design system?
Figma permette di costruire componenti con varianti e stati, e di gestire i token come Variables direttamente nel file di progettazione, in modo che le stesse variabili alimentino sia il design sia il codice implementato dagli sviluppatori.
Cosa sono i componenti di Designers Italia?
Sono gli elementi predefiniti e testati della libreria del design system .italia, pronti per essere riutilizzati nei progetti della Pubblica Amministrazione, con accessibilità e usabilità già verificate.
Quando non serve costruire un design system?
Non è necessario per prodotti con una sola schermata, prototipi non destinati a scalare o team composti da una sola persona: in questi casi conviene mantenere una semplice libreria di stili di base fino a quando il prodotto non cresce.
Fonti e riferimenti
- Design Systems Report 2025 (2025) francescoimprota.com
- Design Systems Report 2026 – brought to you by zeroheight (2026) report.zeroheight.com
