Come fare un audit del design system in 5 giorni: la checklist

Tra cinque giorni lavorativi puoi avere tre cose sul tavolo: un inventario dei componenti con tutte le varianti in produzione, una mappa di quanto il prodotto si è allontanato dalla fonte di verità, e una lista di interventi ordinata per impatto, pronta per uno sviluppatore lunedì mattina. È questo che produce un audit del design system. Qui sotto trovi la checklist che seguiamo giorno per giorno.

L'audit serve quando il sistema costa più di quanto fa risparmiare. I segnali li conosci. Un designer ridisegna un pulsante perché quello giusto è sepolto tre pagine dentro la libreria. Due schermate uscite nello stesso sprint sembrano due prodotti diversi. Nessuno sa dire quale dei quattro grigi sia quello ufficiale. Il zeroheight Design Systems Report 2026 rileva che tre team di design system su cinque sono sottodimensionati e che il 16% dei sistemi è tenuto in piedi da una sola persona. La deriva è la conseguenza prevedibile. Un audit non assume nessuno, ma dice a un team piccolo dove conviene spendere le prossime dieci ore.

La forma è fissa: un giorno per l'inventario, uno per misurare la deriva, uno per l'accessibilità, uno per token e documentazione, uno per scrivere il piano. Cinque giorni bastano per un sistema fino a una sessantina di componenti. Oltre, raddoppia i tempi.

Cosa serve prima di iniziare

Prepara tutto prima, altrimenti il primo giorno slitta sul secondo:

• Accesso alla fonte di verità del design (la libreria Figma o equivalente) e all'app in produzione o al suo Storybook.
• Un foglio di calcolo o un tool di audit. Un foglio basta. Non comprare software per il primo audit.
• Un checker di accessibilità nel browser. Noi usiamo axe-core, gratuito e open source.
• Due o tre flussi utente veri da percorrere: registrazione, dashboard principale, una schermata di impostazioni o di pagamento. Le schermate valgono più della teoria.
• Novanta minuti prenotati con chi possiede il sistema, il quinto giorno, per consegnare la lista.

Giorno 1: inventaria ogni componente in produzione

Apri il prodotto, non la libreria. Percorri i tre flussi e annota ogni componente distinto che vedi: pulsanti, campi, card, modali, tabelle, empty state, toast. Per ognuno segna dove compare e quante varianti visive ne esistono davvero. Un pulsante che appare in cinque colori, tre altezze e due raggi d'angolo è una riga sola, con accanto il numero di varianti.

Il numero che conta a fine giornata è la proliferazione delle varianti: quante versioni di ogni componente girano in produzione rispetto a quante ne definisce la libreria. Una libreria con un pulsante primario e undici pulsanti primari in produzione ha un rapporto di 11 a 1 su quel componente. Quel rapporto è l'audit in una cifra sola, e ti servirà dopo per dare le priorità.

Giorno 2: misura la deriva

La deriva non è una cosa sola. Ordina ogni incongruenza che hai registrato in quattro tipi, perché ognuno si corregge in modo diverso:

• Deriva dei token. Un valore di colore, spaziatura o tipografia nel codice non coincide più con la fonte del design. Solo il 40% circa dei team ha una pipeline di token automatica, quindi è di gran lunga il tipo più frequente.
• Deriva delle varianti. Un componente viene reso con proprietà che il design non ha mai previsto. Si diffonde in fretta ora che il codice generato dall'AI riempie spazi che il designer non ha mai approvato.
• Deriva dei pattern. I singoli componenti sono corretti, ma vengono composti in modi diversi tra un'area e l'altra: lo stesso form disposto in tre modi.
• Deriva della documentazione. La documentazione descrive un comportamento che il componente non ha più.

Dai a ogni voce un punteggio da 0 a 2: 0 se è in linea, 1 per una deviazione lieve, 2 per un componente che si è staccato del tutto. Somma i 2. È il titolo della seconda giornata, e ogni 2 è un candidato per la lista finale.

Giorno 3: verifica l'accessibilità

Lancia axe-core su ognuno dei tre flussi. In pochi secondi segnala contrasti insufficienti, etichette mancanti, ordine di focus rotto. Leggi i risultati con attenzione, perché gli strumenti automatici intercettano circa il 57% dei problemi WCAG e il resto lo trova solo una persona. Fai quindi due passaggi manuali che la macchina non può fare: attraversa ogni flusso usando solo la tastiera, e controlla che il focus sia sempre visibile e mai intrappolato. Segna ogni componente che fallisce, perché un componente rotto nel sistema è un difetto moltiplicato su tutte le schermate che lo usano. Da giugno 2025, con l'European Accessibility Act in vigore, questi errori pesano anche sul piano legale per i prodotti venduti nell'Unione Europea.

Giorno 4: controlla token e documentazione

Prendi il file dei token e confrontalo con quello che il prodotto rende davvero. Due grigi che dovrebbero essere uno, una scala di spaziature con un passo anomalo da 13px, un corpo tipografico definito ma mai usato: registra ogni scostamento come deriva dei token, con una gravità. Poi apri la documentazione e mettila alla prova come farebbe uno sviluppatore nuovo. Scegli tre componenti e prova a usarli partendo solo dalla documentazione. Dove non ci riesci, la documentazione è andata alla deriva, e i componenti non documentati sono proprio quelli che vengono rifatti da zero.

Giorno 5: scrivi la lista degli interventi

Trasforma ogni 2 della settimana in una riga su cui uno sviluppatore può agire. Ogni riga indica il componente, il tipo di deriva, l'intervento in una frase e una stima di lavoro in ore o giorni. Poi ordina con una regola semplice: in cima la proliferazione più alta e ogni errore di accessibilità, in fondo i problemi cosmetici su un solo caso. Una scoperta che resta un'osservazione non cambia niente. Una scoperta scritta come "riduci undici pulsanti primari a uno, cancella gli altri dieci, 1 giorno" viene fatta. Consegna la lista nella sessione da novanta minuti e accompagna chi possiede il sistema tra i primi cinque interventi.

Come capire se l'audit ha funzionato

Una settimana dopo la consegna, tre segnali dicono che ha attecchito. Il numero di varianti sui componenti in cima sta scendendo. Le nuove pull request citano la lista per riga. E il team ha smesso di chiedere quale token sia quello giusto, perché l'audit lo ha nominato. Se niente di tutto questo si muove, il problema non erano i componenti. Era la governance, ed è un altro tipo di lavoro.

Dove gli audit sbagliano

L'errore più comune è verificare la libreria invece del prodotto. La libreria è dove il sistema dovrebbe essere. Il prodotto è dove il sistema è davvero, e la distanza tra i due è tutto il punto. Il secondo errore è segnare ogni cosa come urgente: il team si ritrova con una lista di 200 righe e nessun ordine in cui lavorare. Il terzo è consegnare un documento che nessuno legge. Novanta minuti di walkthrough battono un PDF di cinquanta pagine ogni volta.

Approfondimenti

Per capire come dovrebbe essere organizzato il sistema che stai verificando, leggi la struttura di un design system: le 7 categorie e l'ordine.