Contribuire a un design system: chi può aggiungere un componente

Un modello di contribuzione per un design system (in inglese contribution model) è l'insieme di regole che stabilisce chi può modificare la libreria di componenti condivisa, che tipo di modifica può proporre ciascuno e quale strada fa una proposta prima del rilascio. La domanda arriva la settimana in cui un secondo prodotto adotta il sistema: un designer o uno sviluppatore esterno al team centrale ha costruito un componente per la propria schermata e vuole metterlo nella libreria.

Il modello che scegli decide tre cose insieme: quanto in fretta cresce la libreria, quanto resta coerente e quanta parte della settimana del team centrale se ne va a rivedere il lavoro degli altri. Qui sotto trovi i tre modelli a confronto, come fallisce ciascuno secondo i dati, i criteri che dicono se un componente va nel sistema e il modello che usiamo sul nostro.

La risposta breve

I modelli sono tre. Nel modello centralizzato costruisce solo il team centrale e gli altri aprono richieste. Nel modello federato designer e sviluppatori di più team di prodotto costruiscono il sistema insieme, senza un team dedicato. Nel modello ibrido un team centrale è responsabile della libreria e accetta contributi in base alla loro dimensione: le correzioni da chiunque, i nuovi componenti solo con una proposta che dimostri che servono in più di un posto.

Se la tua organizzazione non è un solo team, scegli l'ibrido. Il federato da solo ha i precedenti peggiori. Nathan Curtis, che nel 2015 ha descritto i modelli di team solitario, centralizzato e federato, ha scritto nel 2024 che su oltre 80 design system seguiti come consulente nessuno ha funzionato senza persone assegnate al sistema in modo centrale. E sul suo consiglio di allora: "Favoring federated was and is wrong", preferire il federato era ed è sbagliato.

Come si confrontano i tre modelli?

Nella pratica nove team su dieci tengono un team centrale. Nel Design Systems Report 2025 di zeroheight il 50% dei rispondenti usa un modello centralizzato, il 41% un ibrido e il 9% un federato. Lo stesso report indica il problema principale di ciascuno: risorse e isolamento per i team centralizzati, la gestione e la spinta dei contributi per gli ibridi, e per i federati il lavoro sul sistema che perde contro priorità che cambiano, tanto che quei team si descrivono come impegnati solo a tenere le luci accese.

Dove vince il modello centralizzato

Con un modello centralizzato ogni API parla con una voce sola. Le stesse persone danno il nome a ogni prop, scelgono ogni valore di default e scrivono ogni linea guida, quindi un componente aggiunto al terzo anno si legge come uno del primo. Quella coerenza è il motivo per cui esiste un sistema, e un team centrale la protegge meglio di chiunque.

Atlassian lavora vicino a questo modello. La sua pagina sui contributi li accetta solo da chi lavora in Atlassian e, tra questi, prende le correzioni (un bug nel codice, un componente sbagliato nella libreria Figma, una frase poco chiara nella documentazione) e i piccoli miglioramenti come una nuova icona. Le modifiche maggiori e i nuovi componenti, con la data visualization come esempio, dichiara che potrebbe non accettarli, perché chiedono un coordinamento su tutto il sistema: codice, design e linee guida.

Il prezzo è la coda. Nel report di zeroheight il 54% dei rispondenti in aziende oltre i 500 dipendenti dice di non avere abbastanza persone, e tra i motivi c'è una domanda che supera l'offerta, con richieste a cui spesso si risponde "no" o "non ancora". Un team di prodotto che si sente dire "non ancora" rilascia la propria versione, e quella copia locale è il punto da cui parte il component drift.

Dove vince il modello federato

Il federato vince quando chi costruisce i prodotti è un gruppo piccolo, vicino e abituato a rivedere il lavoro degli altri. Decide chi sente il problema, i componenti arrivano alla velocità del prodotto e nessuno aspetta un altro team.

Smette di funzionare quando il gruppo cresce oltre il punto in cui tutti sanno cosa hanno costruito gli altri. Curtis descrive lo schema: un'azienda scioglie il team del design system e affida il sistema a un gruppo federato, nessuno dei quali viene sollevato dal resto del lavoro. Sei mesi dopo il sistema è fermo, i componenti invecchiano e la fiducia vacilla. Sono le priorità di prodotto a decidere su cosa lavora ognuno, e nessuno ha tempo riservato alla libreria.

Dove vince il modello ibrido

L'ibrido tiene un team centrale responsabile della qualità e apre una strada d'ingresso a tutti gli altri. L'esempio più documentato è il GOV.UK Design System. Il suo team ha scritto nel 2023 che ormai la maggior parte delle aggiunte importanti arriva da fuori, e pubblica i criteri che un contributo deve rispettare:

1. Utile: ci sono prove che servirebbe a molti team o servizi, per esempio screenshot o link a versioni già in uso in servizi diversi.
2. Unico: non replica qualcosa che il sistema ha già, oppure dimostra di essere migliore di ciò che sostituisce.
3. Usabile: è stato testato in ricerche con gli utenti, su un campione rappresentativo che includa persone con disabilità.
4. Coerente: riusa stili e componenti esistenti, e il codice segue gli standard del sistema.
5. Versatile: funziona nei diversi servizi che potrebbero averne bisogno, e su browser, tecnologie assistive e dispositivi diversi.

I primi due si verificano alla proposta, gli altri tre prima della pubblicazione. La divisione conta, perché chi contribuisce sa se l'idea ha posto nel sistema prima di passarci settimane.

GOV.UK ha cambiato anche chi avvia il lavoro. Nel 2022 il team ha fatto un sondaggio alla propria community (302 risposte, di cui 131 complete) e ha dato un punteggio ai risultati, premiando ciò che esisteva già nelle librerie di pattern di più dipartimenti, si poteva costruire con componenti esistenti, difficilmente richiedeva JavaScript complesso o riduceva i possibili danni agli utenti. Nel 2023 ha smesso di aspettare le proposte dei team: oggi pubblica le prossime priorità e chiede alla community di lavorarci insieme.

Quali modifiche può inviare chiunque?

I contributi si ordinano per dimensione della modifica. La guida ai contributi di Curtis li divide in due tipi, e il tipo decide la strada:

• Le piccole modifiche vanno dritte in una pull request: la correzione di un difetto funzionale, visivo o di accessibilità, un miglioramento oggettivo come lo stato di focus, le prestazioni, il supporto ai browser.
• Le grandi modifiche passano da una proposta: un nuovo componente, un cambio del linguaggio visivo che attraversa i token di molti componenti, un miglioramento che rompe markup o comportamento, la documentazione di un tema che il sistema non copre ancora.

Per le grandi modifiche Curtis prende da progetti open source come Rust ed Ember il processo di request for comment: una discussione informale, una proposta scritta, lo smistamento, un periodo di discussione con la community, l'approvazione e infine la realizzazione. L'ordine protegge il tempo di chi contribuisce, perché il passo costoso arriva dopo che quelli economici hanno detto sì. Una grande modifica incompatibile chiede anche una major release, ed è ciò che decide il versioning del design system.

Come si decide se un componente va nel sistema?

Un sistema tiene ciò che condividono molti prodotti e lascia fuori ciò che serve a uno solo. I criteri di Curtis danno le domande da fare a chi contribuisce prima di iniziare a costruire:

1. Serve a un altro prodotto, e a quanti? La sua scala: un prodotto non basta, due meritano una conversazione, tre una discussione con la community, cinque probabilmente bastano per entrare.
2. È coerente con la direzione del sistema, o porterebbe dentro un nuovo framework, un nuovo flusso di test, un nuovo tipo di dipendenza?
3. Quanto costa costruirlo e mantenerlo? Una pill in pochi colori costa poco. Un date picker che ogni prodotto vuole in una forma leggermente diversa è la trappola classica: fatto per tutti, non va bene a nessuno.
4. Apre una direzione utile a tutti? Un tooltip porta con sé livelli, eventi e posizionamento che poi riusano popover e menu.
5. Chi contribuisce sa dire quando usarlo, come configurarlo e cosa evitare? Se nessuno riesce a scriverne le linee guida, il componente non è pronto per essere condiviso.
6. È il momento giusto per entrambi, per la roadmap del sistema e per il responsabile di chi contribuisce?

Dopo il sì c'è ancora lavoro. Curtis scrive che in oltre dieci anni non ha mai visto un contributo abbastanza completo da entrare così com'era. Va ampliato fino a un insieme minimo di funzioni, alleggerito delle parti che servono solo al suo prodotto e normalizzato su come il sistema dà i nomi e costruisce. Quest'ultimo passo spetta al team centrale in ogni modello, ed è il motivo per cui un modello di contribuzione senza team centrale non dura. Lo stesso ragionamento sta dietro alla scelta di tenere basso il numero di componenti e alle regole sulle prop che evitano gli errori.

Cosa usiamo noi e perché

Usiamo un ibrido con un blocco netto sui nuovi componenti. Sul nostro design system un progetto che lo usa non può aggiungere componenti. Quando una pagina ha bisogno di qualcosa che il sistema non disegna, il progetto rilascia la versione locale più piccola che funziona, in un solo file, con un prefisso tutto suo e una riga sopra che indica il task che la porterà nel sistema. Il team del sistema la costruisce lì e la rilascia, poi il progetto aggiorna la dipendenza e cancella la copia locale. Un controllo conta le versioni locali a ogni build, così il debito resta in vista.

Prima di un nuovo componente cerchiamo quello esistente che disegna la stessa cosa con una prop in più. Una fila di loghi sotto un gruppo di card è diventata una taglia più piccola del componente dei loghi, e la card non ha preso niente. Il prezzo è il tempo: a volte una pagina aspetta una release per il suo pezzo. In cambio la libreria mantiene una voce sola in tutte le API, e le versioni locali sono una lista breve che possiamo contare.

Un modello di contribuzione sta dentro un insieme di regole più ampio. Governare un design system su dieci o più progetti copre il resto, e perché l'adozione di un design system si ferma spiega cosa succede quando ai team di prodotto entrare nel sistema costa più che costruirci intorno.