Component drift: come un design system si degrada e come scoprirlo

Apri un prodotto che ha lanciato un design system un anno fa. Guarda tre pulsanti nella stessa schermata. Spesso trovi tre raggi di bordo diversi, due varianti dello stesso blu "primario" e un pulsante che si anima al passaggio del mouse mentre gli altri restano fermi. Nessuno l'ha deciso. Si e accumulato.

Quell'accumulo e la deriva dei componenti: la lenta divergenza tra i componenti definiti nel design system e l'interfaccia che finisce davvero in produzione. Il sistema non si e rotto in un commit. Si e eroso in centinaia di piccole decisioni mai riviste, ognuna ragionevole presa da sola. Quando qualcuno se ne accorge, la pulizia non e piu un ticket. E un progetto.

Che aspetto ha la deriva in un codebase reale

La deriva non e un problema solo. Si manifesta in quattro forme, e quasi tutti i team le hanno tutte e quattro insieme.

Deriva dei componenti. Lo stesso elemento esiste in tre o quattro versioni quasi identiche. Un Card nella libreria, un Card che qualcuno ha copiato e ritoccato per la dashboard, e un terzo costruito da zero perche i primi due "non andavano bene".

Override dei token. I valori locali si insinuano. Una spaziatura di 14px dove la scala prevede solo 12 e 16. Un codice esadecimale incollato a mano invece di un token di colore. Ogni override e piccolo. Insieme frammentano il sistema finche nessuno sa piu cosa significhi "standard".

Proliferazione delle varianti. Le varianti "solo per questa volta" si accumulano. Un pulsante prende una nuova dimensione per una campagna, un nuovo colore per un team, uno slot per un'icona per una schermata. Dopo sei mesi il pulsante ha quaranta varianti e nessuno sa quali siano approvate.

Deriva del comportamento. La grafica coincide, il comportamento no. Una modale blocca il focus, un'altra no. Un form valida quando esci dal campo, un altro all'invio. E la deriva piu difficile da vedere, perche uno screenshot sembra a posto.

Queste quattro forme si sommano. Un override di un token genera un componente quasi identico, che qualcuno biforca in una nuova variante, che si comporta in modo un po' diverso dall'originale. Una piccola deviazione di martedi diventa quattro tipi di deriva entro il trimestre dopo. Per questo la deriva sembra invisibile finche non e ovunque: ogni passo e troppo piccolo da segnalare, e il totale e troppo grande da ignorare.

Perche la deriva accade, e perche dare la colpa alle persone non aiuta

La deriva raramente nasce da una decisione sbagliata. Nasce da una decisione giusta il cui ragionamento non ha viaggiato. Come scrive il team di UXPin, un sistema va alla deriva perche il pensiero dietro i componenti buoni non e stato comunicato abbastanza bene da evitare quelli cattivi.

Tre meccanismi spiegano la maggior parte dei casi. Primo, gli handoff in cui si ricostruisce: quando uno sviluppatore ricrea un design da un mockup statico, l'interpretazione si insinua, i casi limite sfuggono e sotto scadenza si fanno sostituzioni. Secondo, nessun processo di ingresso per le modifiche: senza un modo definito per chiedere un nuovo token o una nuova variante, i team li aggiungono alla bell'e meglio per risolvere il problema del momento. Terzo, il divario di adozione: un sistema tecnicamente solido viene comunque aggirato nel giro di sei mesi quando il team lo ha ricevuto gia pronto invece di costruirlo. Nessuno di questi e il cattivo della storia. E proprio questo il punto. La deriva e una proprieta del sistema, non una colpa personale.

Quanto costa davvero la deriva

Il dato di partenza fa riflettere. Nel Design Systems Report 2026 di zeroheight, solo l'8% dei team definisce il proprio sistema "molto stabile", mentre il 44% lo considera instabile o molto instabile. Quasi meta del settore costruisce su fondamenta che si muovono.

Il conto si paga in tre punti. Manutenzione: un singolo aggiornamento del brand diventa una revisione enorme su decine di componenti, con tanto spazio perche qualcosa sfugga. Velocita: gli sviluppatori smettono di fidarsi della libreria e ricostruiscono da zero, cosi il sistema smette di far risparmiare tempo, che era tutto il suo scopo. Qualita: stati di focus e validazioni incoerenti sono problemi di accessibilita, e con l'European Accessibility Act, in vigore da giugno 2025, comportano un rischio concreto. Un sistema che va alla deriva non e solo disordinato. Trasforma in silenzio la tua piu grande leva di efficienza in un peso. Piu a lungo gira senza controllo, piu si diffonde l'istinto di ricostruire, e l'interfaccia ricostruita e deriva con un altro nome.

Come sistemare la deriva che hai gia

Dalla deriva esistente non si esce con la sola prevenzione. Prima la devi trovare. Un audit del design system mappa ogni decisione visiva in produzione e segnala dove ci sono valori scritti a mano al posto dei token.

Affronta la pulizia in quest'ordine. Scansiona il codice per i valori hardcoded che dovrebbero essere token e per i token che non corrispondono piu alla loro definizione. Unifica i componenti quasi identici in uno solo, tenendo solo le varianti che il sistema approva davvero. Deprecane il resto su una tabella di marcia chiara, invece di cancellarlo da un giorno all'altro, cosi i team hanno il tempo di migrare. Meno componenti vanno alla deriva, e un sistema piu piccolo lo tiene ancora in testa una persona sola: per questo conviene ridurre la superficie con decisione.

Dai priorita in base al raggio d'impatto, non a quanto una cosa e brutta. Un pulsante alla deriva usato su 80 schermate conta piu di una card isolata in una pagina di impostazioni. Mappa ogni elemento alla deriva su dove finisce in produzione, sistema prima i componenti condivisi ad alto traffico e lascia la coda lunga all'audit programmato. Cosi la pulizia resta rilasciabile, invece di diventare un blocco di sei settimane che nessuno ha approvato.

Come accorgersi della deriva prima degli utenti

La prevenzione richiede due controlli diversi, e quasi tutti i team ne fanno uno solo.

Test di regressione visiva. Intercettano la deriva nuova. Strumenti come Chromatic, Percy e l'open source BackstopJS catturano gli screenshot di ogni componente e li confrontano con una baseline a ogni build, cosi una modifica accidentale a un componente condiviso emerge gia nella pull request. Serve, ma ha un punto cieco: rileva il cambiamento rispetto all'ultima baseline, non lo scostamento dalle specifiche. Se la deriva e gia nella baseline, il test la protegge senza problemi.

Linting di specifiche e token. Intercetta la deriva accumulata. Una regola di lint o una scansione in CI confronta cio che va in produzione con la definizione del sistema: codici esadecimali a mano, spaziature fuori scala, componenti che puntano a valori grezzi invece che ai token. La guida di Material Design e netta: un token di componente deve puntare a un token di sistema o di riferimento, mai a un valore hardcoded come un codice esadecimale. Una scansione che gira in CI trasforma quel principio in un cancello.

Entrambi i controlli sono meccanici. La parte che regge davvero e la governance: un processo di ingresso definito per nuovi token e varianti, una revisione prima che esca l'eccezione "solo per questa volta", e una proprieta che non sparisce dopo il lancio. La deriva e il sintomo. L'anello di revisione mancante e la malattia.

I team che evitano la deriva non sono quelli con piu strumenti. Sono quelli dove aggiungere una variante richiede una conversazione, non solo un commit. Gli strumenti fanno emergere la deriva. Le persone, e l'anello che decidono di seguire, sono cio che le impedisce di tornare.