Dai fogli di calcolo a un sistema unico, condiviso da quattro team
Nel ramo Life di questa compagnia assicurativa internazionale, quattro team lavoravano ognuno con le proprie regole, funzioni e valori. L'intero processo passava da fogli di calcolo.
Ho costruito un hub che ospita il lavoro di tutti e quattro i team, su ogni mercato in cui operavano.
- I quattro team avevano necessità diverse: ruoli, funzioni e regole differenti dentro lo stesso ramo.
- Il cuore del processo viveva su fogli di calcolo passati di mano in mano.
- Nessuna digitalizzazione né centralizzazione dei processi: ogni team teneva i propri dati per conto suo.
- Processi ridisegnati insieme a chi ci lavora ogni giorno, dai contributor agli admin.
- Design system trattato come governance condivisa: regole, ruoli e criteri di aggiornamento decisi con i team.
- Un sistema che rendeva possibile il co-design diretto con i team.
- 46% degli utenti migrato in tre mesi.
- 300+ componenti documentati.
Quattro team, quattro insiemi di necessità e vincoli da tenere insieme
I quattro team del ramo Life lavoravano su aspetti diversi dello stesso business. Le loro necessità divergevano da team a team, e ancora di più in base ai mercati in cui operavano. A usare il sistema erano contributor, manager e admin di tutto il ramo.
Il cuore del processo viveva su fogli di calcolo passati di mano in mano. Le copie si allontanavano l'una dall'altra già dentro lo stesso team, e nessuno sapeva quale fosse quella buona.
La flessibilità di un foglio di calcolo, con la sicurezza del dato che gli mancava
Il vincolo vero era dare a un applicativo strutturato la stessa flessibilità di un foglio di calcolo, senza perdere qualità e sicurezza sul dato. Ho costruito un linguaggio comune fatto di token, componenti e regole di composizione, così i team potevano riconoscerlo come soluzione a un problema che vivevano ogni giorno. Alcuni team hanno rinunciato all'immediatezza di Excel, guadagnando in cambio una qualità del dato che su un foglio di calcolo non poteva esistere.
Costruite osservando come si lavorava davvero
Le fondamenta del sistema sono emerse da interviste agli stakeholder e dall'osservazione diretta di come lavoravano i quattro team ogni giorno. Prima di diventare standard, ogni scelta tornava dalle persone che l'avrebbero usata.
- Un linguaggio comunicativo unico, propagato a ogni team. Emerso osservando come si lavorava davvero, è diventato il punto di partenza obbligato per ogni nuovo sviluppo.
- Guidelines e naming pensati per essere autoesplicativi, così chi progetta o sviluppa trova il componente giusto senza chiedere a me.
- Regole di composizione condivise. Token, componenti e varianti coprono i casi dei quattro team, e ogni mercato compone dalla stessa base invece di crearsi la propria.
L'attrito non si elimina, si riposiziona
Il design system è stato il cuore del progetto, non un sottoprodotto. Ho lavorato a partire da interviste agli stakeholder, osservazione diretta dei contributor e analisi di come lavoravano i quattro team.
- Un passaggio in più non è sempre attrito perso. Dove serviva sicurezza sul dato, ho aggiunto un passaggio deliberato invece di eliminarlo: un clic in più, ma ogni modifica passa da un punto controllato invece che da uno scambio libero e rischioso.
- La familiarità riduce la paura, non il lavoro da fare. Pattern già riconoscibili spostano l'attrito.
- Il controllo va posizionato ai passaggi che contano, non su ogni singolo campo. Ho spostato le verifiche sui momenti che cambiano davvero lo stato di un processo, non su ogni interazione minima.
Un sistema vale quanto il processo che lo tiene insieme, dall'inizio alla fine
Il sistema è nato da un processo che parte prima delle schermate: ricerca sul campo, analisi di come lavoravano i quattro team, ridisegno dei flussi, fino all'allineamento con lo sviluppo. Ogni fase alimentava la successiva. Le interviste e l'osservazione diretta hanno definito i pattern, i pattern sono diventati componenti, e i componenti sono stati verificati contro il modo reale in cui gli sviluppatori li avrebbero implementati: naming coerente, varianti che rispecchiano le prop realmente disponibili.
A implementare ci pensava il team di sviluppo, con cui ragionavamo e ci impegnavamo a creare e curare un linguaggio comunicativo condiviso.
L'adozione è design ops
Le guidelines scritte non bastavano da sole a garantire l'adozione. Ho costruito un'infrastruttura operativa intorno al sistema: materiali di onboarding video per l'adozione autonoma cross-team, una presenza costante nelle revisioni di design per far diventare i pattern la norma e un processo perché ogni nuovo team potesse partire dal sistema invece di reinventarlo.
Un design system che ha retto nel tempo, su quattro team diversi
Dato reale, misurato sull'adozione del sistema.
300+ componenti documentati
Libreria condivisa su cui costruiscono tutti i team.
Adottato dai 4 team del ramo Life
Un solo standard, adottato senza il mio intervento diretto.
“Il valore di un design system non si misura alla consegna, ma anni dopo: quando i team sono cambiati e il prodotto è ancora coerente.”
Oggi controllerei meno e monitorerei di più
Ho protetto la qualità del dato con validazioni rigide, e ogni regola in più toglieva ai team un margine di manovra. Oggi partirei dall'estremo opposto: lasciare più libertà e usare l'AI per sorvegliare i dati man mano che entrano, intervenendo dove serve invece di bloccare tutto in anticipo.
Next project
Tre cantieri, un solo design system, tenuti insieme da un lavoro corale
Gruppo bancario nazionale. Redesign dei flussi con cui i gestori configurano e propongono pacchetti di servizi finanziari alle aziende clienti, dalla profilazione alla proposta firmata.
View project