Come il Design diventa il sistema operativo di un team tecnico
Molti dei progetti su cui lavoriamo sono idee che partono da zero: proof of concept, nuove piattaforme, soluzioni sperimentali che devono trovare una forma mentre vengono costruite. Nella maggior parte dei casi nascono dentro organizzazioni che gestiscono grande complessità — infrastrutture, logistica, processi industriali — dove il software deve reggere casi limite, integrazioni e vincoli concreti.
In questo contesto il design non è un passaggio estetico finale: è ciò che permette di dare direzione quando il terreno è ancora instabile. Quando il prodotto è nuovo, i requisiti evolvono, l’idea iniziale cambia strada, serve un sistema che tenga insieme visione, logica e coerenza.
In un ambiente a forte prevalenza tecnica il rischio è noto: relegare il design alla fase finale, come se fosse un momento di rifinitura. Ma nei progetti che seguiamo questo approccio semplicemente non regge. Se il design arriva dopo, il prodotto nasce già frammentato.
👉 Per questo abbiamo fatto una scelta precisa: il design non è un output, ma un metodo condiviso.
Non è qualcosa che “produce” il designer, è una lingua comune che guida le decisioni di chiunque contribuisca al prodotto.
Nel tempo ci siamo strutturati per prototipare velocemente, per testare ipotesi, per dare forma a qualcosa che prima non c’era. La sfida non era migliorare il passaggio di consegne tra progettazione e sviluppo, ma ridurre quella distanza fino a renderla quasi irrilevante. È un percorso in evoluzione, ma la direzione è chiara: meno compartimenti, più responsabilità diffusa.
Ownership e cultura operativa
Tutto comincia dal modo in cui le persone ragionano, comunicano e prendono decisioni. Negli ultimi mesi abbiamo lavorato sulla nostra cultura aziendale, con l’obiettivo di essere più allineati sui valori che guidano il nostro lavoro e su come ci relazioniamo tra colleghi e con l’esterno.
Per farlo abbiamo utilizzato il metodo 3-hour brand sprint, un formato rapido e collaborativo che ci ha aiutato a rendere esplicite idee e aspettative che spesso restano sullo sfondo. In vari incontri abbiamo messo sul tavolo la nostra percezione dell’azienda, la sua visione futura e il modo in cui vogliamo rivolgerci all’esterno, trasformando questi concetti in una base condivisa da tenere a riferimento per le scelte future.
In seguito abbiamo approfondito i principi del modello Teal Organization. Non come ricetta organizzativa da applicare in modo rigido, ma come lente utile per osservare come le persone e le organizzazioni prendono decisioni in contesti diversi. L’obiettivo non era “diventare teal”, ma sviluppare maggiore consapevolezza su autonomia, responsabilità e collaborazione.
Da qui abbiamo proseguito con workshop più pratici, alternando momenti di divergenza — per far emergere idee e prospettive diverse — a momenti di convergenza, in cui identifichiamo azioni e decisioni condivise. È in questi passaggi che concetti come ownership e responsabilità diffusa smettono di essere parole e diventano comportamenti quotidiani.
Il nostro retreat annuale è diventato lo spazio privilegiato per consolidare questo lavoro. Una pausa dal ritmo dei progetti per riflettere insieme su come lavoriamo e su come possiamo continuare a migliorare.
Allineamento frequente
Questo modo di lavorare richiede allineamento costante. Ogni lunedì mattina ci ritroviamo per la nostra riunione in presenza, impropriamente detta Retrospettiva. Non è una riunione di reporting e non è un momento di assegnazione dall’alto, ma uno spazio operativo in cui analizziamo carichi, verifichiamo attività, mettiamo sul tavolo criticità e priorità.
Nel tempo abbiamo adattato questo momento alle nostre esigenze reali, togliendo ciò che era superfluo e mantenendo ciò che aiutava davvero a lavorare meglio. Il risultato è uno strumento concreto per mantenere il controllo quando i progetti si intrecciano e la complessità aumenta.
È anche il modo migliore che abbiamo trovato per attutire il trauma del lunedì mattina, raccontandoci cosa abbiamo fatto nel weekend prima di tornare a parlare di backlog.
Progettare anche il fallimento
Un altro importante elemento che integra il design nel nostro metodo è la pratica di pre-mortem e post-mortem, associati sia ai progetti per i clienti che alle attività di conduzione aziendale (come la preparazione del budget, la rendicontazione di un bando o l’organizzazione di un evento) .
Prima di avviare un progetto ci chiediamo come potrebbe fallire. Analizziamo rischi, fragilità e ipotesi deboli. Questo ci permette di anticipare problemi invece di reagire a posteriori. Alla fine, nel post-mortem, valutiamo cosa ha funzionato e cosa no, trasformando l’esperienza in apprendimento strutturato.
Non è un esercizio formale. È un modo per rendere esplicite le decisioni e migliorare progetto dopo progetto.
Le fondamenta prima delle scelte visive
Quando si lavora su prodotti nuovi e complessi, l’improvvisazione si paga. Non subito, ma quando il sistema cresce, quando aumentano le funzionalità, quando entrano nuovi casi d’uso.
Per questo abbiamo costruito due Design System, uno web e uno mobile, che forniscono una base di partenza per ciascun progetto in avvio. Non sono semplici raccolte di componenti, ma un’infrastruttura condivisa fatta di variabili, pattern e regole validate con gli utenti. Sono le fondamenta che ci permettono di muoverci velocemente senza perdere coerenza.
Questo cambia il tipo di discussione nei progetti: non perdiamo tempo su elementi già risolti, ma possiamo concentrarci su logica, flussi, priorità e impatto reale. L’estetica non viene sacrificata, viene resa strutturale.
L’impatto non è solo sul prodotto
Integrare il design come principio operativo quotidiano sta producendo effetti concreti, e più rapidamente di quanto ci aspettassimo. Ma il cambiamento più evidente non riguarda subito il software: riguarda il modo in cui lavoriamo.
Oggi prendiamo decisioni con meno attrito, discutiamo sui problemi reali e non sulle interpretazioni, sprechiamo meno energie in riallineamenti tardivi. Il tempo speso a lavorare è più focalizzato, intenzionale. La produttività aumenta perché diminuiscono le ambiguità. Anche il morale cambia: quando le regole del gioco sono chiare, le persone si muovono con più autonomia e meno frustrazione.
L’effetto sul prodotto è una conseguenza naturale. Il software è più coerente, solido, aderente ai bisogni reali, perché nasce da un sistema condiviso e non da contributi isolati.
Quando il design diventa metodo e non servizio, non migliora solo ciò che consegniamo. Migliora la qualità del lavoro quotidiano, attraverso la capacità di affrontare l’incertezza senza perdere coerenza.
Non sappiamo ancora dove ci porterà questo percorso. Quello che sappiamo è che ha già cambiato il modo in cui costruiamo prodotti e il modo in cui lavoriamo insieme.