Quando affidare il design system a un'agenzia (e quando aspettare)

Affidare il design system a un'agenzia è prima di tutto una questione di tempi. Quale studio scegli conta dopo. A decidere è se il prodotto si ripete già abbastanza da far rientrare l'investimento: la stessa tabella in quattro schermate, la stessa logica di form in due codebase, lo stesso bottone rifatto da chi ha preso il ticket.

Il testo è per chi firma la fattura. Quattro soglie dicono adesso. Una lista più corta dice aspetta sei mesi. Qui trovi come distinguerle e cosa mettere nel primo perimetro quando la risposta è sì.

Quanto rende un design system, e in quanto tempo

Due studi mettono numeri sul risparmio. Il team di data science di Figma ha misurato un esercizio controllato: chi aveva a disposizione un design system ha chiuso lo stesso obiettivo il 34% più in fretta di chi partiva da zero. Sparkbox ha provato il lato sviluppo con Carbon di IBM: su otto sviluppatori, una pagina con un form semplice ha richiesto 2 ore di mediana con il sistema contro 4,2 ore partendo da zero, il 47% in meno.

Sono campioni piccoli e misurano un compito solo. Vanno letti come ordine di grandezza: un design system taglia circa un terzo del costo di costruire interfaccia che il sistema copre già. È l'ultima parte della frase a reggere tutto il ragionamento.

Il conto nasce dalla ripetizione. Prendi un team che rilascia otto schermate nuove a trimestre, cinque giornate di design e front-end ciascuna. Sono 40 giornate di interfaccia a trimestre, quindi un risparmio del 35% ne restituisce 14. Ipotizza fondamenta più un primo set di componenti fra le 30 e le 60 giornate di lavoro. Il rientro arriva intorno al terzo o quarto trimestre, e da lì in poi il sistema continua a rendere. Rifai lo stesso conto su un team che rilascia due schermate a trimestre e il rientro cade molto dopo il momento in cui il prodotto sarà cambiato.

Perché aspettare che faccia male costa di più

La regola implicita nei team di prodotto è aspettare che l'incoerenza diventi fastidiosa. A quel punto il conto ha due righe. Si paga per costruire il sistema e si paga per migrare tutte le superfici che nel frattempo hanno preso strade diverse. La migrazione è la metà cara: tocca codice già rilasciato, compete con la roadmap, chiede QA su schermate che nessuno aveva in programma di riaprire. Come si accumula quella deriva lo abbiamo raccontato in component drift.

Muoversi troppo presto ha un altro difetto, e non riguarda la costruzione. I design system muoiono in adozione, e il modo più sicuro per ucciderla è consegnare una libreria ampia di componenti che nessuno aveva chiesto. Netguru descrive bene gli errori di adozione: si prova a coprire ogni scenario al lancio, e i componenti mai nati da una schermata vera restano lì. Una libreria da 60 componenti consegnata a un prodotto di 11 schermate è una guida di stile molto costosa.

Quando la risposta non è chiara, un audit di cinque giorni produce i numeri che servono a decidere, a una frazione del costo di una build. La checklist che usiamo è pubblica: come fare un audit del design system in 5 giorni.

Le quattro soglie che dicono adesso

1. Lo stesso componente esiste in tre punti

Conta i duplicati veri, non quelli previsti. Cerca nel codice il bottone, il campo, la modale, la tabella. Tre o più implementazioni indipendenti dello stesso elemento, oppure due superfici che hanno già divergenze (sito e app, console di amministrazione e prodotto per il cliente), sono il segnale singolo più forte. Un design system capitalizza sulla ripetizione. Senza ripetizione non c'è niente da ammortizzare.

2. All'interfaccia mettono mano più di tre persone a settimana

Un designer e uno sviluppatore front-end tengono la coerenza a mente, e lo fanno più in fretta di qualsiasi documentazione. Smette di funzionare intorno alle tre-cinque persone, o la settimana in cui entra il primo collaboratore esterno. Il ritmo pesa quanto il numero: un rilascio settimanale genera in un trimestre più divergenza di quanta ne generi in un anno un rilascio mensile.

3. C'è qualcuno che se ne occupa il lunedì dopo la consegna

È la soglia che chi compra salta e poi rimpiange. Leggendo le indagini annuali di Zeroheight, NN/g riporta che la maggior parte dei team di design system è fatta da 2 a 5 persone, che sopra i 5.000 dipendenti la media resta fra 9 e 11, e che questi team superano di rado le 20-25 persone. Qui conta il pavimento più del soffitto: il presidio minimo sono un designer e uno sviluppatore con ore assegnate, non una pagina wiki e buone intenzioni. Se quelle ore non ce le ha nessuno, rimanda. Un sistema senza presidio si degrada più in fretta del codice che doveva sistemare.

4. C'è una data che non si sposta

Un rebrand, una migrazione di piattaforma, una seconda linea di prodotto, una gara enterprise o una scadenza di accessibilità. L'European Accessibility Act si applica dal 28 giugno 2025 con la direttiva (UE) 2019/882, e le richieste che oggi arrivano dagli uffici acquisti (dichiarazione di accessibilità, prove di conformità) si soddisfano una volta sola sul componente oppure ogni volta sulla singola schermata. Una data fissa trasforma il design system da argomento di efficienza a dipendenza di consegna, e questo prevale sui conti di prima.

Tre soglie su quattro sono un sì. Due aprono una discussione sul perimetro. Una è un no.

Quando aspettare sei mesi

Aspetta finché il prodotto sta ancora decidendo cosa è. I segnali concreti:

• Il flusso principale è cambiato due volte nell'ultimo trimestre e il prossimo cambio è già in calendario.
• Una superficie, un designer, uno sviluppatore front-end.
• Meno di 15 schermate distinte e nessun secondo prodotto in roadmap.
• Nessun responsabile con nome e cognome dopo la consegna.
• Cassa sotto i 12 mesi e product-market fit ancora aperto.

Aspettare non vuol dire stare fermi. La versione economica tiene la porta aperta: definisci i token (colore, tipografia, spaziature, raggi, elevazione) e fermati lì, poi tieni un inventario scritto dei componenti mano a mano che nascono. Una o due settimane di lavoro, quasi gratis da buttare via, e il sistema che verrà diventa un refactoring invece di uno scavo archeologico. L'ordine con cui costruirlo poi sta in struttura di un design system.

Cosa mettere nel primo perimetro quando la risposta è sì

Il primo incarico deve chiudersi con delle fondamenta, non con un catalogo.

• Token e temi, dark mode inclusa se il prodotto prima o poi la vorrà. Aggiungere il supporto ai temi dentro valori scritti a mano è la rilavorazione più prevedibile di tutta la categoria.
• Da otto a dodici componenti, scelti contando quello che le schermate esistenti usano davvero, non copiando l'indice di una libreria. Nella maggior parte dei prodotti quel gruppo copre la parte più grande dell'interfaccia.
• Una base di accessibilità dentro i componenti: stati di focus, contrasto, percorsi da tastiera, etichette. Si sistema una volta e la ereditano tutti.
• Una politica di versioni e contribuzione: chi può aggiungere un componente, cosa conta come cambio incompatibile, come si annuncia una release. È la governance a decidere se fra un anno il sistema è ancora vivo.
• Documentazione attaccata al codice, non un sito a parte che nessuno aggiorna.

Il modello di consegna che regge è ibrido. L'agenzia costruisce le fondamenta a una velocità che un team interno non può tenere mentre porta avanti il prodotto, e poi il team interno se ne prende la crescita. Dove vince l'una e dove vince l'altro lo trovi in design system interno o con agenzia, e le forme commerciali (progetto, retainer, proprietà condivisa) in prezzi di un design system.

Lo stesso prodotto, due risposte opposte

Prendi un prodotto B2B con app per il cliente, console di amministrazione e sito. Tre bottoni in tre codebase. Due designer, quattro sviluppatori front-end, rilasci settimanali. Una seconda linea di prodotto è firmata per il trimestre successivo, e sulle trattative enterprise cominciano a chiedere la dichiarazione di accessibilità.

Quattro soglie su quattro. Il conto: circa 45 giornate per fondamenta e dieci componenti, contro 14 giornate a trimestre recuperate sull'interfaccia nuova, più il lavoro di accessibilità che altrimenti si ripete su ogni schermata. Rientro intorno al terzo trimestre, e la seconda linea di prodotto parte sul sistema invece di forkare la prima.

Ora cambia due variabili. Togli la seconda linea di prodotto e la console di amministrazione, lascia un designer e uno sviluppatore front-end. Lo stesso team dovrebbe spendere due settimane su token e inventario e riparlarne fra sei mesi. Stesso interlocutore, stessa categoria di prodotto, risposta opposta, perché le soglie si sono mosse.