Design Fluency: la competenza che manca ai board per guidare l’innovazione

Negli ultimi anni ho avuto l’occasione di lavorare fianco a fianco con molti C-level: CEO, CTO, CPO, CIO. Ho visto crescere in loro una sempre maggiore tech fluency (la capacità di comprendere, dialogare e prendere decisioni informate sulle tecnologie). Un progresso notevole, frutto di anni di trasformazione digitale, formazione e contatto diretto con l’innovazione.

Eppure, c’è qualcosa che ancora manca.

Se oggi la tecnologia è entrata nei consigli di amministrazione e nei comitati strategici, il design, inteso non come estetica, ma come disciplina strategica e sistemica, fatica ancora a trovare lo stesso spazio di governance.

Ciò che vedo mancare è quella che chiamerei design fluency: la capacità di interpretare ogni scelta tecnologica o di prodotto anche nelle sue implicazioni di esperienza, adozione e impatto organizzativo.

Dalla tech fluency alla design fluency

Nella letteratura esistono definizioni consolidate di tech fluency: capacità di comprendere il potenziale e i limiti delle tecnologie, di dialogare con gli esperti e di valutare investimenti e rischi. Diversi studi — come quelli di McKinsey e MIT Sloan — la collegano a una maggiore velocità decisionale e a un miglior allineamento tra strategia e execution.

Nel campo della psicologia cognitiva, il termine fluency viene usato per indicare la capacità di generare rapidamente e con flessibilità soluzioni diverse a un problema, come avviene nei test di “design fluency” nelle scale WAIS o in prove di elaborazione grafica. Questa abilità è correlata alla creatività e alla flessibilità esecutiva: due competenze che, se portate dal contesto individuale a quello aziendale, possono diventare leve strategiche per l’innovazione.

Traslando nel contesto aziendale, il concetto può diventare una lente potentissima: si tratta di generare scenari, ipotesi di servizio, configurazioni di prodotto.

La vera design fluency organizzativa non è l’abilità di avere un’idea brillante, ma la capacità di generare, valutare e iterare più soluzioni progettuali, sapendo leggere da subito le implicazioni cross-funzionali e i trade-off.

Perché è un tema strategico (non operativo)

Un esempio emblematico di quanto una forte tech fluency non basti senza un’adeguata design fluency è il caso di HSBC Zing.

Lanciata come app fintech per i pagamenti internazionali, in pochi mesi ha registrato circa 131.000 iscritti, ma solo 8.736 utenti attivi mensili, ben al di sotto del target di 120.000. Secondo Financial Times, il prodotto soffriva di un posizionamento poco differenziato rispetto ad altri servizi della stessa banca, come Global Money, e di un onboarding percepito come lento rispetto agli standard del settore.

Questo caso fornisce un esempio concreto di come una forte tech fluency (capaci di riconoscere opportunità fintech e tecnologie digitali) non basti: senza una design fluency che traduca strategia in esperienza, metriche di adozione, senso operativo e differenziazione reale, l’innovazione rimane fragile.

Questa competenza non riguarda solo i designer.

Riguarda i board e i comitati strategici, che dovrebbero avere gli strumenti per interpretare ogni scelta di prodotto anche nei suoi impatti operativi e organizzativi. Un processo di adozione fallimentare, un’interfaccia troppo complessa o un flusso non scalabile non sono dettagli tecnici: sono fattori che compromettono direttamente i risultati economici e la posizione competitiva.

Un caso di successo, invece, è rappresentato dell’allineamento strategico di IBM Watson Health. Quando IBM ha rilanciato Watson Health, il rischio era quello di replicare l’errore tipico di molte soluzioni AI: enorme potenza tecnologica, scarso impatto pratico nei contesti reali.

Il team dirigente ha scelto un approccio design-led, con cicli di co-progettazione tra ingegneri, clinici, designer e stakeholder ospedalieri.

Questo ha permesso di:

• Definire fin dall’inizio le implicazioni organizzative dell’adozione dell’AI (processi clinici, formazione del personale, responsabilità legali).
• Identificare casi d’uso ad alto impatto e prioritari, evitando lo sviluppo di feature marginali.
• Creare un framework di adozione graduale, che accompagnasse i cambiamenti di processo con onboarding mirato.

Risultato: Watson Health è stato adottato più velocemente e con meno resistenze, non perché fosse la tecnologia “più avanzata”, ma perché il board ha saputo tradurre la scelta tecnologica in valore operativo.

In questo caso, la design fluency ha trasformato una decisione di innovazione in un cambiamento sostenibile.

Dal framework alla pratica

Portare design fluency in azienda significa creare un linguaggio comune tra chi decide e chi progetta. Significa dotare i CdA di framework che mettano in evidenza:

• le implicazioni di ogni scelta progettuale su utenti, team e processi,
• i rischi di adozione legati a scarsa chiarezza, eccesso di complessità o incoerenza dell’esperienza,
• le metriche di lungo periodo, non solo quelle immediate di rilascio o go-live.

Il design, in questo senso, non è un output ma un catalizzatore di allineamento, comprensione e governance.

E quando questa mentalità entra davvero nei luoghi decisionali, cambia il modo in cui si valutano priorità, si distribuiscono risorse e si misurano i risultati.