Adozione del design system ferma: 5 cause e come risolverle

L'adozione di un design system si ferma quando l'infrastruttura c'è e le abitudini no: il pacchetto è installato in ogni repository, la libreria Figma è pubblicata, eppure le nuove schermate escono con pulsanti locali, istanze staccate e colori esadecimali scritti a mano. Le installazioni crescono, l'uso reale resta fermo. Qui sotto le cinque cause che cerchiamo quando un sistema smette di diffondersi, e il rimedio per ciascuna.

È un problema facile da non vedere, perché ogni metrica dell'infrastruttura sembra in ordine. La dipendenza c'è, i token si generano, il sito della documentazione è online. Quello che non si è mosso è la scelta che un designer o uno sviluppatore fa a fine giornata, con una scadenza addosso: usare il sistema, oppure scrivere la cosa in locale e andare avanti.

Come si riconosce un'adozione ferma in un codebase reale?

I segnali sono quattro, compaiono insieme e si possono contare.

• Installato, non importato. Ogni app ha il pacchetto tra le dipendenze, ma una scansione mostra che tre o quattro componenti fanno quasi tutti gli import.
• Copie locali. Un PrimaryButton.tsx o un CardWrapper nella cartella dell'app, che rifà un componente del sistema cambiando una prop.
• Istanze staccate nei file di design. Figma registra un detach ogni volta che qualcuno rompe il legame tra un'istanza e il componente principale, e le analytics della libreria ne danno il conteggio per componente (Figma Help Center).
• Valori grezzi negli stili. Colori esadecimali e spaziature in pixel scritti direttamente nel CSS, dove un token esiste già.

Preso da solo, nessuno di questi è un fallimento. Un'istanza staccata può essere uno schizzo, un componente locale può essere un prototipo. Conta l'andamento: se i quattro conteggi salgono a ogni rilascio mentre la versione del pacchetto resta aggiornata, il sistema è installato e aggirato.

Perché l'adozione si ferma dopo il lancio?

I sondaggi seguono il problema da anni. Nel Design Systems Survey 2021 di Sparkbox il 44% dei rispondenti interni ha indicato l'aumento dell'adozione come una difficoltà, e l'adozione è in quella lista dall'edizione 2018. Lo stesso sondaggio la collega ai risultati: tra chi giudica il proprio sistema «non riuscito», l'83% indica l'adozione tra i problemi principali, contro il 9% di chi lo giudica «molto riuscito» (Sparkbox).

Anche i team che gestiscono i sistemi sono sotto pressione. Il Design Systems Report 2026 di zeroheight, basato su 147 risposte, rileva che 3 team di design system su 5 non hanno abbastanza persone per raggiungere i propri obiettivi, e che la soddisfazione per il sostegno ottenuto dall'organizzazione è scesa in un anno dal 42% al 32% (zeroheight). Un team piccolo e poco sostenuto riesce a rilasciare l'infrastruttura. Gli restano molte meno ore per cambiare il modo di lavorare degli altri team, ed è lì che l'adozione si decide.

Le cinque cause che cerchiamo

1. Il componente manca proprio il giorno in cui serve

Martedì uno sviluppatore ha bisogno di un selettore di intervallo di date. Il sistema ha il selettore di data, non quello di intervallo. Il ticket va chiuso giovedì. La versione locale viene scritta, revisionata e unita, e da quel momento è quella che il team riusa. Ogni buco nel catalogo è un fork in attesa, e il fork sopravvive al buco: quando due mesi dopo il sistema aggiunge l'intervallo, nessuno torna indietro a sostituirlo.

Rimedio: tenere pubblica la lista dei buchi noti, ognuno con una data prevista, e pubblicare per ciascuno un pattern provvisorio approvato, cioè una composizione di parti esistenti descritta in un paragrafo. Con una soluzione ufficiale nasce un solo fork condiviso al posto di sei privati, e un fork solo si migra facilmente.

2. Chiedere costa più che fare da sé

Se proporre una modifica al sistema vuol dire un modulo, una riunione di revisione e due settimane di attesa, con una scadenza vicina la scelta razionale è costruire in locale. L'adozione segue il costo della strada. Quando contribuire è più lento che aggirare, aggirare vince ogni volta che lo si misura contro uno sprint.

Rimedio: fissare un tempo di risposta per le richieste di contributo (due giorni lavorativi per una prima risposta sono un obiettivo sostenibile) e una strada leggera per le modifiche piccole: una prop, una variante, un token. La revisione completa resta per i componenti nuovi. Come decidiamo se un componente nuovo merita di esistere lo spieghiamo in la dieta del design system.

3. La documentazione dice cosa, non quando

Una tabella di prop e un esempio dal vivo spiegano cosa fa un componente. Non dicono quando usarlo, quando usare quello accanto, né cosa fare quando nessuno dei due va bene. Ed è proprio la domanda che ci si pone nel momento della scelta. La ricerca 2026 di zeroheight sull'AI nei design system rileva che solo il 17% di 123 rispondenti considera la propria documentazione «molto pronta per l'AI» (zeroheight). Agenti e persone si bloccano sullo stesso pezzo mancante: la regola per scegliere.

Rimedio: aggiungere a ogni pagina di componente un blocco «Quando usarlo» e uno «Quando non usarlo», ciascuno con l'alternativa. Poi leggere per un mese il canale di supporto e trasformare ogni domanda ricorrente in una riga di quei blocchi.

4. Nessuno misura l'uso, quindi nessuno vede la deriva

Senza un conteggio, da dentro un sistema fermo e uno che cresce sembrano uguali. Misurare costa poco. Il team di ingegneria di Brevo lancia react-scanner su tutti i repository con una matrice di GitHub Actions, salva i report e mostra in Metabase l'uso dei componenti per progetto (Brevo Engineering). Lato design, le analytics delle librerie Figma riportano inserimenti e detach per componente. La scansione del codice è spiegata più nel dettaglio in component drift: come un design system si degrada.

Rimedio: seguire tre numeri per prodotto, ogni mese: la quota di import di interfaccia che arrivano dal sistema, il numero di componenti locali che ne duplicano uno del sistema, la percentuale di detach per componente della libreria. E pubblicarli dove i team di prodotto li vedono.

5. L'adozione non è un obiettivo del team di prodotto

Il team del sistema ha in mano il sistema. Il team di prodotto ha in mano una roadmap con delle date. Se nessun obiettivo di prodotto nomina il sistema, ogni attività di migrazione compete con una funzione nuova e perde. Chi dovrebbe adottare il sistema viene valutato su altro.

Rimedio: scrivere l'adozione negli obiettivi del team di prodotto, come un numero legato alle sue schermate («entro fine trimestre il checkout usa solo componenti del sistema»), e mettere a budget le ore nello stesso piano. Con molti prodotti su un solo sistema, la parte di governance è in come governare un design system su 10 progetti.

Quanto costa un'adozione ferma?

Il costo si vede il giorno in cui il sistema cambia. Una correzione di accessibilità sul pulsante del sistema arriva a ogni schermata che lo importa, e a nessuna di quelle che l'hanno copiato. Un rebrand aggiorna i token, e i colori scritti a mano restano quelli vecchi. Ogni fork trasforma una modifica in una ricerca dentro il codice. Per darle un valore economico, c'è il ROI del design system come voce di conto economico.

Come si recupera un'adozione già ferma?

1. Fare una fotografia iniziale. Lanciare una scansione dell'uso su ogni repository ed esportare il report dei detach. In un pomeriggio si hanno i tre numeri di sopra.
2. Ordinare i fork. Elencare le copie locali per numero di schermate che le usano, e partire dalla prima.
3. Chiudere il buco dietro ogni fork. Se un fork esiste perché manca una variante, prima si aggiunge la variante al sistema, poi si migra.
4. Migrare con un team di prodotto alla volta. Affiancare a quel team una persona del sistema per uno sprint, inserire la migrazione nella sua roadmap e pubblicare i conteggi prima e dopo.
5. Trattare i detach come segnalazioni di bug. Un detach su un componente della libreria dice che il componente non andava bene. Ogni mese si rivedono i dieci più staccati e si decide: nuova variante, documentazione migliore o eccezione accettata.

Come evitare che si fermi di nuovo?

Le regole vanno messe dove si lavora. La regola color-no-hex di Stylelint segnala i colori esadecimali nei fogli di stile (Stylelint), e no-restricted-imports di ESLint può bloccare gli import da una cartella di componenti locali deprecata o da una seconda libreria di interfaccia (ESLint). Con una regola di lint una linea guida diventa un commento sulla pull request, proprio nel momento della scelta.

Poi si tengono i tre conteggi in calendario ogni mese, si rispetta il tempo di risposta ai contributi e la lista dei buchi resta pubblica. L'adozione tiene finché usare il sistema resta la strada più economica per chi ha la scadenza.