ROI del design system: misurarlo come voce di conto economico

Un design system e una libreria condivisa di componenti, token e regole a cui attinge ogni team di prodotto, e il suo ritorno si legge nel conto economico, non in una presentazione di brand. Trattato come voce di bilancio, ottiene budget alle stesse condizioni di qualsiasi altro investimento: accorcia i tempi di rilascio, elimina il lavoro duplicato e abbassa il costo della prossima funzionalita. Trattato come asset di marketing, compete con le funzionalita per i fondi e di solito perde.

Questa differenza decide se il tuo design system sopravvive al prossimo taglio di budget. Founder, CTO e head of design che lo raccontano parlando di coerenza ed estetica raccolgono cenni di approvazione nella stanza e zero nel budget. Chi continua a ottenere fondi lega il sistema a numeri che un CFO gia segue. Qui vediamo quali sono quei numeri e come misurarli in modo onesto.

Perche raccontarlo come asset di brand fa perdere il budget

Quasi tutti i design system vengono presentati sulla coerenza. I bottoni sono uguali. Le spaziature tornano. Il prodotto sembra un prodotto solo invece di sei. Tutto vero, e tutto facile da definanziare, perche la coerenza visiva viene letta come gusto, e il gusto e la prima cosa che salta quando la roadmap si stringe.

Il problema non e che la coerenza non abbia valore. Il problema e che quel valore e reale ma invisibile. Quando manca un design system, nessuno apre un ticket che dice abbiamo ricostruito lo stesso menu a tendina per la quarta volta questo trimestre. Il costo emerge come rilasci piu lenti, piu cicli di QA, e sviluppatori che in silenzio reinventano componenti gia presenti da qualche parte nel codice. E una tassa pagata in cento punti diversi, cioe esattamente il tipo di costo che una presentazione di marketing non sa catturare.

Spostare il sistema nel conto economico cambia la domanda. Non e piu bello ma quanto cambia di quello che spendiamo per rilasciare. A questa domanda si puo rispondere con delle fonti.

Cosa muove davvero un design system nel conto economico

Quattro voci. Tempo di sviluppo, tempo di design, costo dei difetti e velocita verso il fatturato. Ognuna e misurabile, e ognuna si muove in una direzione che un team finanziario riconosce. Due sono documentate abbastanza bene da portarle oggi in una riunione di budget.

Tempo di sviluppo e di design

E la voce piu grande e piu documentata. In uno studio controllato di Sparkbox, otto sviluppatori hanno costruito due volte la stessa pagina con un form, una da zero e una con il Carbon Design System di IBM. Con il sistema, il tempo mediano e sceso da 4,2 ore a 2 ore, il 47% in meno, anche tenendo conto del tempo per imparare il sistema (Sparkbox). I team di design riportano guadagni simili o maggiori, perche un componente deciso una volta e un componente che non si ridiscute piu.

Uno studio Total Economic Impact di Forrester su Dev Mode di Figma, che sta nel passaggio dal design al codice, ha misurato oltre 90 minuti di tempo risparmiato a settimana per sviluppatore e un aumento dell'output tra il 20 e il 30 per cento (Forrester). Novanta minuti a settimana per ogni sviluppatore, su un team di venti persone, valgono piu o meno la capacita di uno sviluppatore a tempo pieno restituita ogni settimana.

Costo di difetti e rilavorazioni

Un componente condiviso lo correggi una volta e la correzione si propaga. Un componente copiato lo correggi ovunque sia stato incollato, o piu spesso lo correggi in alcuni punti e in altri no. E cosi che le violazioni di accessibilita e i bug visivi si moltiplicano nel prodotto. Il design system non elimina i difetti, ma ne cambia l'economia: una correzione invece di tante, e meno posti in cui la deriva puo nascondersi. Meno difetti vuol dire anche meno rilasci d'emergenza, e i rilasci d'emergenza sono i piu costosi.

Velocita verso il fatturato

Build piu veloci vogliono dire funzionalita che escono prima, e una funzionalita che esce a marzo incassa due mesi di ricavi in piu della stessa funzionalita a maggio. Questa voce e piu difficile da attribuire con precisione, quindi trattala come indicativa e non come esatta. I modelli di ROI pubblicati collocano il ritorno complessivo ben oltre il pareggio: un modello molto citato mostrava un investimento di 646.000 dollari che ne restituiva circa 1,5 milioni in tempo risparmiato, un ritorno del 135% (zeroheight). Prendi quel numero come esempio di ordine di grandezza, non come promessa. Il tuo ritorno dipende da una variabile che il modello da per scontata: l'adozione.

Perche il calcolo di ROI piu ovvio inganna

Il calcolo standard moltiplica il tempo risparmiato per schermata per il numero di schermate. E pulito, ed e sbagliato nel momento in cui il team il sistema non lo usa davvero. Un design system che nessuno adotta rende zero, per quanto buoni siano i componenti.

L'adozione e il punto in cui la maggior parte dei sistemi fallisce in silenzio. La ricerca sul tema e netta: la bassa adozione e quasi sempre un problema di design, non di comunicazione, e gli obblighi calati dall'alto di usare il sistema rendono meno di un'introduzione fatta insieme ai team (DesignSystems.one). Se il sistema e piu scomodo che copiare un componente esistente, gli sviluppatori copiano. La libreria resta li, finanziata per intero e ignorata per intero, e il ROI che avevi previsto non arriva mai.

Per questo il conto economico deve includere anche una voce di costo, non solo una di risparmio. Un design system ha un costo corrente: manutenzione, documentazione, versioning, e la persona o il team che lo mantiene. Nascondi quel costo e il tuo ROI sembra inventato. Mettilo nero su bianco e il numero regge, che e l'unico tipo di numero che vale la pena portare a una riunione di budget.

Come portare un design system nel conto economico

Quattro passi, nessuno dei quali richiede un team di analisi dedicato.

1. Fissa un tempo di sviluppo di riferimento. Prima dell'adozione, o all'inizio, misura quanto ci vuole a costruire una schermata rappresentativa senza il sistema. E il tuo numero di controllo. Senza, ogni affermazione successiva e solo un'opinione.

2. Misura l'adozione, non solo l'esistenza. Conta la quota di nuova interfaccia che usa i componenti del sistema rispetto a quelli fatti su misura. L'adozione e il moltiplicatore di ogni altro numero, quindi e la metrica che decide se il sistema si ripaga. Un sistema nella trappola della bassa adozione ha bisogno di un piano di recupero prima che di piu componenti.

3. Metti il costo corrente sul foglio. Uno o due sviluppatori di manutenzione, o una frazione del tempo di piu persone, e un numero reale. Scrivilo. Il ROI onesto e il risparmio meno questo costo, e il ROI onesto sopravvive al trimestre dopo.

4. Attribuisci il risparmio a una voce che la finanza gia gestisce. Capacita di sviluppo restituita, cicli di QA evitati, tempo di lancio ridotto. Associa ogni risparmio a un centro di costo che esiste gia. Un team finanziario finanzia cio che vede nelle proprie categorie.

Come si traduce nella pratica

Prendi un team di dieci sviluppatori e tre designer. Ipotizza che il sistema restituisca un prudente 30% del tempo di sviluppo front-end, sotto il 47% misurato da Sparkbox. Se il lavoro front-end e un terzo del tempo di sviluppo, sono piu o meno la capacita di uno sviluppatore restituita a tutto il team. A un costo pienamente caricato tra 120.000 e 180.000 dollari per quella capacita, il solo risparmio copre un manutentore e avanza.

Contro quel risparmio, il costo corrente di un responsabile part-time e uno strumento di documentazione. Il sistema supera il pareggio entro il primo anno, e il secondo anno e dove il ritorno si accumula, perche il tempo di sviluppo di riferimento continua a scendere man mano che la copertura cresce. Questo e il caso che un CFO finanzia. Non e coerente, ma restituisce la capacita di una persona al costo di una frazione di persona. La prima frase e gusto. La seconda e una voce di bilancio.

Niente di tutto questo funziona se l'analisi di partenza e sbagliata. Se non sai cosa hai, non puoi dare un prezzo a quello che ti fa risparmiare. Una verifica del design system e il modo piu economico per fissare il numero di riferimento prima di costruire il caso economico.