Perché rimuoviamo componenti invece di aggiungerli: la dieta del design system

Con un design system, la mossa di default è aggiungere. Una nuova schermata vuole una card un po' diversa, qualcuno forka Card in CardCompact, la libreria cresce e dopo un anno nessuno sa nominare metà dei componenti che contiene. Più la libreria è grande, più le design review rallentano e più spesso due designer risolvono lo stesso problema in due file diversi.

Noi invertiamo il default. Rimuoviamo componenti più spesso di quanto ne aggiungiamo, e trattiamo la dimensione della libreria come un numero da tenere basso, non alto. Qui ci sono le regole che seguiamo, perché ognuna esiste, e dove si rompono.

Il principio del taglio

Un design system serve a togliere decisioni dal lavoro di prodotto, non a ospitare ogni variante mai esistita. L'Atlassian design system imposta la cosa nello stesso modo e spinge i team verso la composizione: invece di un componente largo con diciotto prop, due componenti piccoli che si incastrano. Anche Adobe ha fatto lo stesso quando ha riprogettato Spectrum 2 attorno a primitive più strette.

Da qui segue una regola: ogni componente costa. Documentazione che invecchia. Rumore nelle analytics Figma. Ore di engineering quando cambia il tema e 200 istanze devono migrare. Designer nuovi che leggono tre quasi-doppioni e scelgono quello sbagliato. Il beneficio (il riuso) si materializza solo quando il componente è davvero condiviso. Sotto la soglia di riuso, hai solo il costo.

Il test d'ingresso (prima di aggiungere qualunque cosa)

Usiamo due domande prima di promuovere qualunque cosa in libreria, prese dal pattern che Josh Cusick descrive in Design systems should do less:

1. Il pattern è già usato in tre o più punti del prodotto?
2. È abbastanza generico da far comparire un quarto caso d'uso entro due trimestri?

Due sì: il componente entra. Un sì: resta pattern locale nell'app che lo usa. Due no: scrivi uno snippet su Notion e vai oltre.

È più duro di quello che sembra. La maggior parte delle richieste "ci serve nel sistema" arriva con un sì, a volte zero. Dire no presto è il momento più economico nella vita di un componente. Una volta spedito, ogni rimozione è una migrazione.

La kill list (segnali per deprecare)

Una volta a trimestre attraversiamo la libreria con la kill list davanti. Un componente è candidato alla deprecazione se vale almeno una di queste condizioni:

• Meno di 5 istanze su tutti i file di prodotto dopo sei mesi. Figma Library Analytics lo mostra direttamente nelle voci Inserts e Instances; la release di febbraio 2025 ha aggiunto la stessa vista per stili e variabili, quindi la regola vale anche per i token.
• Più del 30% delle istanze è scollegato. Il distacco è il segnale che il componente non calza il caso d'uso reale e i designer ci girano attorno. Il tasso di detach è la cosa più vicina a uno score di soddisfazione che un design system possa avere.
• Esiste un quasi-doppione. ButtonPrimary, PrimaryButton, BtnCTA. Due componenti che condividono più di metà delle prop sono un segnale forte che uno dei due deve morire.
• Nessun owner documentato. Tutto ciò che in libreria non ha qualcuno disposto a metterci la firma si mantiene male da solo. Il campo owner nella scheda di spec è un kill switch. Se resta vuoto per due trimestri, il componente entra nella lista.
• Il pattern si esprime componendo due componenti più piccoli. Card + Heading + Action è un layout, non un componente. CardWithActionButton è un componente che si forka in cinque varianti in un anno.

Candidato non vuol dire cancellato. Vuol dire deprecato, e parte un timer.

Come deprecare senza rompere i consumer

Rimuovere un componente subito è il modo in cui i design system diventano odiati. La cadenza che usiamo, modellata sulla finestra di deprecazione di Adobe Spectrum e sul pattern di rename Figma documentato da Craig Francies:

1. Rinomina il componente. In Figma, Button diventa Button [deprecated]. Figma propaga il nuovo nome in ogni file consumer al primo accesso, così i designer vedono l'etichetta senza che nessuno mandi una mail. Stessa regola nel codice: rinomina l'export, lascia un re-export dal vecchio path che logga un warning in console in development.
2. Pubblica il percorso di migrazione. Ogni componente deprecato ha un paragrafo "usa questo al suo posto" nella spec, con un diff di codice. Se non c'è un sostituto, la deprecazione è sbagliata e stai per rompere i consumer.
3. Fissa una data di rimozione. A una major version di distanza. Atlassian e Spectrum lavorano così. La data sta nella scheda di spec, non nella testa di qualcuno.
4. Traccia il conteggio delle istanze ogni settimana. Il numero deve scendere. Se non scende, il messaggio di deprecazione non passa e serve documentazione di migrazione più nitida, non una rimozione forzata.
5. Rimuovi alla data, non prima. Se i team non hanno migrato, la rimozione è una forzatura. Se sposti la data, insegni ai team che le deprecazioni sono opzionali.

La parte difficile è il punto 4. La maggior parte dei team di design system la salta, arriva alla data, scopre che metà del prodotto consuma ancora il componente deprecato, e o rimanda (lezione: le deprecazioni sono opzionali) o rimuove (lezione: il design system rompe le cose). Il tracciamento settimanale con owner nominati è ciò che chiude il loop. Lo stesso pattern compare nel nostro approccio di governance su più progetti consumer: prima i conteggi delle istanze, poi le opinioni.

Composizione, non componente

Una frazione sorprendente delle richieste "ci serve un nuovo componente" crolla quando provi a esprimere il pattern come composizione. Una card con una riga di icone, un heading, un body e due CTA non è una nuova variante di card. È <Card><IconRow/><Heading/><Body/><ActionBar/></Card>. Cinque primitive, ognuna fa una cosa.

La guida sulla composizione di Atlassian e il pattern dei compound component di React rendono la cosa concreta. Il costo è la scoperta dell'API: un designer nuovo davanti a cinque primitive deve sapere che si incastrano. Il beneficio è che il sistema ha 5 componenti che fanno il lavoro di 50, senza disallineamento di versione tra i consumer.

La regola decisionale: un nuovo componente si guadagna il posto in libreria solo se non si esprime per composizione delle primitive esistenti con codice ragionevole. Ragionevole vuol dire grosso modo 5-8 righe di JSX. Oltre, vince l'astrazione.

La dieta trimestrale

La cadenza conta più delle regole. Una volta ogni tre mesi, due persone del team design system attraversano la libreria con la kill list. Segnano i candidati. Il segno è pubblico. I consumer hanno una settimana per opporsi. Dopo la settimana, i componenti segnati entrano nel ciclo di deprecazione descritto sopra.

Cosa misuriamo lungo il ciclo: conteggio totale dei componenti, conteggio dei deprecati ancora presenti, numero medio di istanze per componente non deprecato, tasso di completamento delle deprecazioni (quante volte la data di rimozione tiene). Il primo numero deve calare o restare piatto anno su anno. Il quarto deve stare sopra l'80%. Un audit di design system fatto bene traccia tutti e quattro e fa emergere il drift prima che parta la conversazione sul rewrite.

Una libreria che cresce in modo monotono è una libreria che va verso un rewrite. I team che evitano il rewrite sono quelli che trattano la potatura come parte del lavoro ordinario.

Dove la dieta non funziona

Tre casi resistono alla regola.

Superficie di prodotto nuova. Quando il prodotto ha sei mesi e il team sta ancora trovando la forma dell'interfaccia, deprecare in modo aggressivo genera più rework di quanto risparmi. Tieni la kill list ferma per il primo anno e lascia che i pattern si assestino.

Componenti di settore con peso regolatorio. Un componente di dashboard per dispositivi medici che incorpora vincoli WCAG e FDA non è un candidato alla deprecazione solo perché il conteggio istanze cala. Il costo di sbagliare altrove pesa più del carico di manutenzione.

Handoff a un team interno. Se il design system è stato costruito da uno studio esterno e viene riconsegnato a un team interno, congela la kill list durante il passaggio. Potare un sistema che il team ricevente non ha ancora capito gli insegna a temerlo.

Per tutto il resto (design system in produzione con più app consumer, più di 50 componenti in libreria, più di un designer che tocca il sistema a settimana) la dieta è la differenza tra un sistema che capitalizza valore e uno che capitalizza il tipo di debito di cui abbiamo scritto in 10 errori di design system che rompono la coerenza su scala.