Every eighteen months, with almost meteorological regularity, an authoritative article appears declaring the death of the design system. I have read the Sketch version, then the Figma version, then the AI-generated component library version, then the zero-config CSS framework version. Every time the funeral is premature. Every time there is something genuinely new in the problem being identified, and something wrong in the diagnosis.
I have built enterprise design systems for ten years. Tarvos for Exein — a design system for an IoT security infrastructure that had to be readable by firmware engineers and understandable by the board. The component system for Vodafone Italia. Frameworks for legal, medical, and financial products. I have seen what survives and what does not. And I will say this: the eulogists are always wrong about the patient, but almost always right about the diagnosis.
The pattern that repeats: new tools, same accusations
The recurring accusation is that design systems are too rigid, too slow, too disconnected from the reality of daily development. That product teams work around them instead of using them. That the Figma library is always three versions behind the code. That nobody knows who owns a component when it needs updating. That the Notion documentation was accurate the day it was written and useless six months later.
All true. But these are not design system problems — they are governance problems. And governance does not improve by switching tools. Moving from Sketch to Figma did not solve the stale documentation problem. Moving to Storybook did not solve the question of who makes the call when product and design system contradict each other. Moving to design tokens did not solve the question of who updates the tokens when the brand changes.
What dies cyclically is not the design system. It is the illusion that building it once means you have solved it.
What dies cyclically is not the design system. It is the illusion that building it once means you have solved it.
What is genuinely dead: the monolithic model
There is one thing that is genuinely dead, at least for mid-to-large enterprise teams. It is the model I call "the one ring" — a centralised system that claims to cover every product, every surface, every use case across the entire organisation.
The issue is not conceptual but operational. A centralised team cannot know every product well enough to make sensible design system decisions for all of them. A system generic enough to work everywhere ends up generic enough to be optimal nowhere. And every exception requested by a product team becomes a ticket sitting in a queue, generating frustration and unofficial forks that nobody documents.
The model I have seen work best over the last three years is federated: a small core of shared decisions — typography, semantic colours, spacing scale, mandatory accessibility patterns — and then a documented extension system that allows product teams to build their specific components while respecting the core contract. Not total freedom. Not total control. A clear perimeter with autonomy inside it.
What generative AI has actually changed
The promise was: with AI, generating components becomes instant, the design system becomes superfluous. The reality I have observed is more interesting and less dramatic.
Generative AI has made the creation of component variants and prototypes faster. But it has not solved — and could not solve — the upstream problem: deciding which components exist, what they do, which patterns they promote and which they exclude, how they behave on error, which accessibility requirements they meet. These are governance decisions that require organisational context that a generative model does not have.
What I have seen happen with teams that adopt generative AI without a design system: the speed of component production increases, but so does divergence. Every engineer generates their own slightly different modal component. Visual consistency decreases. Technical debt grows silently. And six months later someone like me needs to run an audit to restore order.
Paradoxically, generative AI has made the design system more necessary, not less. Because without an authoritative reference specification, rapid generation rapidly produces divergence.
The design system in 2025: smaller surface, stronger tokens
The enterprise design system I build today is structurally different from what I built in 2018. Not because the philosophy has changed, but because I have learned where to concentrate investment to maximise return.
The system's surface area is smaller. Fewer components, but better documented and more stable. The rule I use: a component enters the system only when it appears in at least three different products or contexts. Before that, it lives as a local solution. This drastically reduces maintenance burden and raises the average quality of components in the system.
Semantic tokens are the core. Not color-blue-500 but color-action-primary, color-feedback-error, color-surface-elevated. Tokens that encode semantic decisions, not visual values. When the brand changes — and it always does — the underlying values are updated, not the system rewritten. For Tarvos I used this approach and the dark theme migration took two days of work instead of three weeks.
Documentation lives in the code, not in Notion. Not because Notion is the wrong tool, but because documentation separated from the source of truth always becomes stale. Components are documented via Storybook with arguments, use cases and accessibility behaviours. If the component changes, the documentation changes with it — because it is the same file.
A component enters the system only when it appears in at least three different products. Before that, it lives as a local solution.
Governance: the only thing that truly matters
I have saved the most important thing for last, because it is the most tedious to read and the most critical to get right. Design system governance answers four questions, and if you have not answered all four before you start building, the system will fail regardless of its technical quality.
Who owns the system? Not a generic team — a specific person who responds when a component has a critical bug at 11pm on a Thursday. In the organisations where I have seen design systems survive longest, there is always a person with clear ownership, even if the work is distributed.
How are decisions made when the system conflicts with a product need? You need a documented process, not a case-by-case discussion. The answer could be a committee, an asynchronous process on GitHub, or a simple rule ("the system always wins on layout and typography, the product wins on specific flows"). What does not work is having no answer.
How is adoption measured? If you do not measure, you do not know whether the system is being used or bypassed. The metrics I use: component coverage (how many surfaces use system components vs custom ones), average implementation time for a new feature vs the pre-system benchmark, number of visual divergences flagged in design reviews. They are not perfect metrics, but they are better than nothing.
How is the system updated without breaking products? Semantic versioning applied to component libraries is not merely a technical detail — it is a promise to product teams that they can upgrade in a controlled way. If every update risks breaking something without warning, the system gets frozen out of fear and then abandoned.
Where this is heading
The next change I see coming is the use of AI for automatic consistency checking: tools that analyse production screenshots and identify where components diverge from the design system, without requiring a manual review. Technically it is already possible — some teams are experimenting with vision model approaches and automated visual tests. It is not yet an industry standard, but it will be.
The other trend I see is the encoding of design decisions directly into tokens, not just values. Tokens that carry metadata about context of use, contrast requirements, accessibility constraints. A token is not just a colour — it is a colour with its rules. This makes the system smarter and harder to misuse through carelessness.
The design system is not dead. It has evolved, as it always has. And those who declared the premature funeral now find themselves working with teams that have lost three years of visual consistency and are forced to rebuild from scratch what they dismantled chasing the trend.
If you are building or redesigning a design system for an enterprise team — especially if governance is the critical bottleneck — I can help you set the right structure before writing a single line of code. The first conversation is free.
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.
Se stai costruendo o ridisegnando un design system per un team enterprise — specialmente se la governance è il collo di bottiglia critico — posso aiutarti a impostare la struttura giusta prima di scrivere una singola riga di codice. La prima conversazione è gratuita.