Il design system è morto. Lunga vita al design system.

Ogni diciotto mesi, con una regolarità quasi meteorologica, compare un articolo autorevole che dichiara la morte del design system. Ho letto la versione Sketch, poi la versione Figma, poi la versione libreria di componenti generata dall’AI, poi la versione framework CSS zero-config. Ogni volta il funerale è prematuro. Ogni volta c’è qualcosa di genuinamente nuovo nel problema identificato, e qualcosa di sbagliato nella diagnosi.

Ho costruito design system enterprise per dieci anni. Tarvos per Exein — un design system per un’infrastruttura di sicurezza IoT che doveva essere leggibile dagli ingegneri firmware e comprensibile dal board. Il sistema di componenti per Vodafone Italia. Framework per prodotti legali, medicali e finanziari. Ho visto cosa sopravvive e cosa no. E dirò questo: chi scrive i necrologi sbaglia sempre riguardo al paziente, ma quasi sempre ha ragione nella diagnosi.

Il pattern che si ripete: nuovi strumenti, stesse accuse

L’accusa ricorrente è che i design system sono troppo rigidi, troppo lenti, troppo scollegati dalla realtà dello sviluppo quotidiano. Che i team di prodotto ci lavorano intorno invece di usarli. Che la libreria Figma è sempre tre versioni indietro rispetto al codice. Che nessuno sa chi possiede un componente quando deve essere aggiornato. Che la documentazione su Notion era accurata il giorno in cui è stata scritta e inutile sei mesi dopo.

Tutto vero. Ma questi non sono problemi di design system — sono problemi di governance. E la governance non migliora cambiando strumenti. Passare da Sketch a Figma non ha risolto il problema della documentazione obsoleta. Passare a Storybook non ha risolto la questione di chi decide quando prodotto e design system si contraddicono. Passare ai design token non ha risolto la questione di chi aggiorna i token quando il brand cambia.

Ciò che muore ciclicamente non è il design system. È l’illusione che costruirlo una volta significhi averlo risolto.

Ciò che muore ciclicamente non è il design system. È l’illusione che costruirlo una volta significhi averlo risolto.

Cosa è davvero morto: il modello monolitico

C’è una cosa che è davvero morta, almeno per i team enterprise di medie e grandi dimensioni. È il modello che chiamo “l’unico anello” — un sistema centralizzato che pretende di coprire ogni prodotto, ogni superficie, ogni caso d’uso in tutta l’organizzazione.

Il problema non è concettuale ma operativo. Un team centralizzato non può conoscere ogni prodotto abbastanza bene da prendere decisioni sensate sul design system per tutti. Un sistema abbastanza generico da funzionare ovunque finisce per essere abbastanza generico da non essere ottimale da nessuna parte. E ogni eccezione richiesta da un team di prodotto diventa un ticket in coda, che genera frustrazione e fork non ufficiali che nessuno documenta.

Il modello che ho visto funzionare meglio negli ultimi tre anni è federato: un nucleo ristretto di decisioni condivise — tipografia, colori semantici, scala di spaziatura, pattern di accessibilità obbligatori — e poi un sistema di estensione documentato che permette ai team di prodotto di costruire i propri componenti specifici rispettando il contratto di base. Non libertà totale. Non controllo totale. Un perimetro chiaro con autonomia al suo interno.

Cosa ha davvero cambiato l’AI generativa

La promessa era: con l’AI, generare componenti diventa istantaneo, il design system diventa superfluo. La realtà che ho osservato è più interessante e meno drammatica.

L’AI generativa ha reso più veloce la creazione di varianti di componenti e prototipi. Ma non ha risolto — e non poteva risolvere — il problema a monte: decidere quali componenti esistono, cosa fanno, quali pattern promuovono e quali escludono, come si comportano in caso di errore, quali requisiti di accessibilità soddisfano. Queste sono decisioni di governance che richiedono contesto organizzativo che un modello generativo non ha.

Quello che ho visto succedere con i team che adottano l’AI generativa senza un design system: la velocità di produzione dei componenti aumenta, ma aumenta anche la divergenza. Ogni ingegnere genera la propria versione leggermente diversa del componente modale. La coerenza visiva diminuisce. Il debito tecnico cresce in silenzio. E sei mesi dopo qualcuno come me deve fare un audit per ristabilire l’ordine.

Paradossalmente, l’AI generativa ha reso il design system più necessario, non meno. Perché senza una specifica di riferimento autorevole, la generazione rapida produce rapidamente divergenza.

Il design system nel 2025: superficie ridotta, token più forti

Il design system enterprise che costruisco oggi è strutturalmente diverso da quello che costruivo nel 2018. Non perché la filosofia sia cambiata, ma perché ho imparato dove concentrare l’investimento per massimizzare il ritorno.

La superficie del sistema è più piccola. Meno componenti, ma meglio documentati e più stabili. La regola che uso: un componente entra nel sistema solo quando appare in almeno tre prodotti o contesti diversi. Prima di allora, vive come soluzione locale. Questo riduce drasticamente il peso della manutenzione e alza la qualità media dei componenti nel sistema.

I token semantici sono il nucleo. Non color-blue-500 ma color-action-primary, color-feedback-error, color-surface-elevated. Token che codificano decisioni semantiche, non valori visivi. Quando il brand cambia — e succede sempre — vengono aggiornati i valori sottostanti, non riscritto il sistema. Per Tarvos ho usato questo approccio e la migrazione al tema scuro ha richiesto due giorni di lavoro invece di tre settimane.

La documentazione vive nel codice, non su Notion. Non perché Notion sia lo strumento sbagliato, ma perché la documentazione separata dalla fonte di verità diventa sempre obsoleta. I componenti sono documentati via Storybook con argomenti, casi d’uso e comportamenti di accessibilità. Se il componente cambia, la documentazione cambia con esso — perché è lo stesso file.

Un componente entra nel sistema solo quando compare in almeno tre prodotti diversi. Prima di allora, vive come soluzione locale.

La governance: l’unica cosa che conta davvero

Ho tenuto la cosa più importante per ultima, perché è la più noiosa da leggere e la più critica da fare bene. La governance del design system risponde a quattro domande, e se non le hai risposto tutte e quattro prima di iniziare a costruire, il sistema fallirà indipendentemente dalla sua qualità tecnica.

Chi possiede il sistema? Non un team generico — una persona specifica che risponde quando un componente ha un bug critico alle 23 di un giovedì. Nelle organizzazioni dove ho visto i design system sopravvivere più a lungo, c’è sempre una persona con ownership chiara, anche se il lavoro è distribuito.

Come vengono prese le decisioni quando il sistema entra in conflitto con un’esigenza di prodotto? Serve un processo documentato, non una discussione caso per caso. La risposta potrebbe essere un comitato, un processo asincrono su GitHub, o una regola semplice (“il sistema vince sempre su layout e tipografia, il prodotto vince sui flussi specifici”). Quello che non funziona è non avere una risposta.

Come si misura l’adozione? Se non misuri, non sai se il sistema viene usato o aggirato. Le metriche che uso: copertura dei componenti (quante superfici usano componenti di sistema vs componenti custom), tempo medio di implementazione di una nuova funzionalità vs il benchmark pre-sistema, numero di divergenze visive segnalate nelle design review. Non sono metriche perfette, ma sono meglio di niente.

Come si aggiorna il sistema senza rompere i prodotti? Il versioning semantico applicato alle librerie di componenti non è solo un dettaglio tecnico — è una promessa ai team di prodotto che possono aggiornare in modo controllato. Se ogni aggiornamento rischia di rompere qualcosa senza preavviso, il sistema viene congelato per paura e poi abbandonato.

Verso dove sta andando

Il prossimo cambiamento che vedo arrivare è l’uso dell’AI per il controllo automatico della coerenza: strumenti che analizzano screenshot di produzione e identificano dove i componenti divergono dal design system, senza richiedere una revisione manuale. Tecnicamente è già possibile — alcuni team stanno sperimentando approcci con modelli di visione e test visivi automatizzati. Non è ancora uno standard di settore, ma lo diventerà.

L’altra tendenza che osservo è la codifica delle decisioni di design direttamente nei token, non solo dei valori. Token che portano metadati sul contesto d’uso, i requisiti di contrasto, i vincoli di accessibilità. Un token non è solo un colore — è un colore con le sue regole. Questo rende il sistema più intelligente e più difficile da usare male per superficialità.

Il design system non è morto. Si è evoluto, come ha sempre fatto. E chi ha dichiarato il funerale prematuro si trova ora a lavorare con team che hanno perso tre anni di coerenza visiva e sono costretti a ricostruire da zero quello che hanno smantellato inseguendo la tendenza del momento.