Ogni azienda sopra una certa dimensione prima o poi costruisce la stessa cosa due volte. Poi tre. Poi un team conta le implementazioni di bottone sparse nei suoi prodotti e ne trova undici, tutte leggermente diverse, tutte mantenute da qualcuno che preferirebbe fare altro.

La risposta abituale è “facciamo un design system”, e il risultato abituale è una libreria di componenti: un pacchetto di bottoni, input e modali con un numero di versione. Sei mesi dopo, metà dei prodotti l’ha adottata, l’altra metà l’ha forkata, e gli undici bottoni sono diventati tredici — due dei quali ora vivono dentro il design system.

Ho passato l’ultimo decennio su entrambi i lati di questo problema — come consulente sulle piattaforme brand, e oggi guidando i frontend trasversali in Aruba. La lezione che continuo a re-imparare è questa: un design system non è una libreria di componenti. È una struttura decisionale che, tra le altre cose, pubblica codice.

I componenti sono la parte facile

Scrivere un buon bottone è un problema risolto. Quello che non è risolto, nella maggior parte delle organizzazioni, è tutto ciò che gli sta intorno:

  • Chi decide quando il bottone cambia — il team del design system, il prodotto che ha bisogno della modifica, o la voce più forte nella stanza?
  • Chi paga la migrazione quando arriva un breaking change — il team che l’ha introdotto, o i dodici team a valle?
  • Cosa succede quando un prodotto ha bisogno di qualcosa che il sistema non ha — aspetta, forka, o contribuisce?

Una libreria di componenti non risponde a nessuna di queste domande. Un design system è queste risposte, più il codice che rende più facile seguirle che non seguirle.

L’economia del codice condiviso

I componenti frontend condivisi hanno una proprietà che li rende diversi da quasi tutto il resto del software: il loro valore cresce con l’adozione, ma cresce anche il costo di cambiarli. Un bottone usato da un prodotto può cambiare ogni giorno. Lo stesso bottone usato da quaranta prodotti è di fatto infrastruttura — ogni modifica è una trattativa.

Ecco perché “estraiamo i componenti comuni” fallisce come strategia. L’estrazione crea l’accoppiamento senza creare la governance. I team che ci riescono trattano il frontend condiviso come un prodotto con degli utenti, non come un codebase con dei consumatori: ha una roadmap, un processo di richieste, politiche di deprecazione, e qualcuno il cui lavoro è dire di no.

È anche il motivo per cui esiste il ruolo che ricopro oggi — un product owner per la piattaforma frontend in sé. Non perché i componenti abbiano bisogno di un backlog, ma perché le cose condivise hanno bisogno di qualcuno che risponda dei compromessi che impongono a tutti gli altri.

Tre test per un design system vero

Se volete sapere se avete un design system o una libreria di componenti con delle ambizioni, provate questi:

  1. Il test del prodotto nuovo. Un prodotto nuovo può pubblicare la sua prima schermata usando solo il sistema, in un giorno? Se no, il sistema serve i suoi autori, non i suoi utenti.
  2. Il test del breaking change. Quando il sistema pubblica un breaking change, esiste un percorso di migrazione che un team a valle può seguire senza parlare con nessuno? La governance che devi chiedere è governance che non scala.
  3. Il test dell’eccezione. Quando un prodotto ha legittimamente bisogno di divergere, esiste un modo sancito per farlo? I sistemi senza via d’uscita non prevengono la divergenza — semplicemente smettono di sentirne parlare.

Nessuno di questi test menziona la coerenza visiva. La coerenza è un effetto collaterale di un sistema più facile da usare che da evitare. Quando vedete un’organizzazione con una bellissima libreria Figma e tredici bottoni in produzione, non state guardando un problema di design. State guardando un problema di ownership che nessuno ha ancora messo per iscritto.

Il codice è la parte facile. Mettete per iscritto le decisioni.