Quando un servizio non viene usato, un processo interno rallenta o un cliente abbandona il percorso, la risposta non è sempre aggiungere funzioni o lavorare più velocemente. Il design thinking aiuta a partire dai bisogni reali delle persone, trasformare un problema ambiguo in una sfida concreta e verificare le idee prima di investire troppe risorse. In queste righe mostro come applicarlo alla gestione, all’organizzazione e al lavoro dei professionisti autonomi.
Un metodo pratico per progettare soluzioni utili
- Centralità delle persone: si osservano comportamenti e bisogni, non soltanto opinioni.
- Cinque fasi ricorrenti: empatia, definizione, ideazione, prototipazione e test.
- Piccoli esperimenti: si verifica presto un’idea prima di trasformarla in un progetto costoso.
- Collaborazione tra competenze: marketing, operations, tecnologia e utenti contribuiscono insieme.
- Risultato concreto: meno decisioni basate su supposizioni e maggiore utilità per chi userà la soluzione.
Il problema viene prima della soluzione
In azienda molte decisioni partono dalla soluzione già immaginata. “Dobbiamo creare un’app”, “serve un nuovo gestionale”, “il team ha bisogno di un corso” sono frasi comprensibili, ma contengono già una risposta. Io preferisco tornare alla domanda iniziale e capire quale difficoltà concreta si vuole risolvere.
Questo approccio è una combinazione di mentalità, strumenti e pratiche per progettare prodotti, servizi o processi più adatti alle persone. Non riguarda soltanto la grafica e non richiede di essere designer. Un responsabile HR può usarlo per migliorare l’inserimento dei nuovi dipendenti, un consulente per rendere più chiaro il proprio servizio e un piccolo imprenditore per ridurre gli ostacoli all’acquisto.
La differenza rispetto a una semplice sessione di brainstorming è sostanziale. Il brainstorming produce possibilità; il metodo centrato sull’utente cerca prima di capire perché il problema esiste, poi mette alla prova le idee con evidenze e feedback. La creatività conta, ma da sola non basta.
Bisogno dichiarato e bisogno reale
Un cliente può dire di volere un preventivo più dettagliato. Osservando il suo comportamento, però, potremmo scoprire che il vero problema è la paura di ricevere costi inattesi o di non capire cosa sia compreso nel servizio. La prima richiesta riguarda il documento, la seconda riguarda la fiducia nella decisione.
Per questo interviste, osservazione e analisi dei comportamenti sono più utili di un questionario pieno di domande astratte. Chiederei a una persona di raccontare l’ultima esperienza concreta, non “che cosa vorresti in futuro?”. I dettagli del passato fanno emergere attriti che spesso l’interessato non sa spiegare in modo diretto.
Le cinque fasi per passare dai bisogni alle prove
Le fasi sono spesso rappresentate in ordine, ma nella pratica si procede avanti e indietro. La d.school di Stanford presenta il processo come un modo di lavorare umano e sperimentale, non come una ricetta rigida da applicare identica in ogni situazione.
1. Entrare nel punto di vista dell’utente
Nella fase di empatia si raccolgono informazioni parlando con le persone, osservandole e ricostruendo il loro percorso. Per un primo giro è ragionevole coinvolgere 3-5 utenti con caratteristiche diverse, purché siano davvero vicini al problema.
Le domande migliori sono aperte e legate a episodi reali. “Mi racconti l’ultima volta che hai provato a fare questa cosa?” è più rivelatore di “ti piacerebbe avere questa funzione?”. Si annotano frasi, ostacoli, emozioni, workaround e passaggi ripetuti.
2. Definire una sfida precisa
Le informazioni raccolte vanno trasformate in una frase utile al lavoro. “Come possiamo aiutare i nuovi clienti a capire il valore del servizio entro i primi dieci minuti?” è una sfida più produttiva di “come miglioriamo il marketing?”.
Una buona definizione non propone già la soluzione e non accusa l’utente. Deve indicare chi vive il problema, quale bisogno emerge e in quale situazione. Se la domanda resta troppo ampia, anche le idee successive saranno difficili da valutare.
3. Generare possibilità senza giudicarle subito
Solo a questo punto si apre la fase ideativa. Il gruppo può produrre molte opzioni in 20-30 minuti, combinando idee realistiche e proposte più ambiziose. Io trovo utile separare nettamente la produzione dalla selezione, perché criticare ogni idea mentre nasce riduce la partecipazione.
La scelta finale, però, non dovrebbe premiare l’idea più originale. Si possono valutare le proposte secondo quattro criteri semplici: utilità per l’utente, fattibilità operativa, sostenibilità economica e coerenza con gli obiettivi. Una matrice su quattro dimensioni rende la discussione meno politica.
4. Rendere l’idea visibile
Un prototipo è una versione semplificata della soluzione. Può essere una schermata disegnata su carta, una pagina dimostrativa, uno script di telefonata, una simulazione del servizio o una procedura descritta in pochi passaggi.
Il suo scopo non è impressionare, ma permettere alle persone di reagire a qualcosa di concreto. Un prototipo realizzato in un’ora può rivelare un errore che altrimenti costerebbe settimane di sviluppo.
5. Testare e correggere
Durante il test si chiede all’utente di usare o commentare il prototipo in una situazione vicina alla realtà. Non bisogna guidarlo troppo, altrimenti si finisce per confermare la propria idea. Meglio osservare dove si blocca, cosa interpreta male e quali passaggi considera superflui.
Il test non serve soltanto a ricevere approvazione. Il risultato più utile può essere scoprire che l’ipotesi iniziale è sbagliata. In quel caso si modifica il prototipo, si torna alla definizione del problema o si interrompe il progetto prima di consumare altro budget.
Come applicare il design thinking alla gestione
In un’organizzazione il metodo funziona quando diventa una pratica decisionale, non un workshop isolato con post-it colorati. Il manager deve creare uno spazio in cui sia possibile dire “questa ipotesi non regge” senza trasformare l’errore in una colpa. La sicurezza psicologica è una condizione pratica, non uno slogan.
Un laboratorio di due settimane
Per affrontare un problema circoscritto, imposterei un percorso breve. Nella prima settimana il team raccoglie testimonianze, osserva il processo e definisce la sfida. Nella seconda costruisce uno o due prototipi, li testa e decide se iterare, cambiare direzione o fermarsi.
Il gruppo ideale può avere 4-6 persone con competenze diverse. Servono almeno una persona vicina agli utenti, una che conosca i vincoli operativi e una che possa valutare tecnologia o costi. Se partecipano soltanto i dirigenti, il progetto rischia di riflettere le loro supposizioni invece dell’esperienza quotidiana.
Un esempio nell’organizzazione del lavoro
Immaginiamo che una società di servizi riceva molte richieste incomplete dai clienti. La soluzione istintiva sarebbe aggiungere campi al modulo. Con alcune interviste potrebbe emergere che il linguaggio è troppo tecnico e che le persone non sanno quali documenti preparare.
Il prototipo potrebbe essere una versione ridotta del modulo, accompagnata da esempi e da una checklist. Dopo il test con cinque utenti si misurano completezza delle richieste, tempo necessario per inviarle e numero di chiarimenti successivi. La soluzione migliore non è quella più sofisticata, ma quella che riduce davvero l’attrito.
Il ruolo del professionista autonomo
Per chi lavora in proprio, il vantaggio è ancora più diretto. Non avendo grandi strutture o budget per la ricerca, può usare conversazioni con clienti, revisioni dei progetti e osservazione delle richieste ricevute come fonte di apprendimento.
Prima di rifare il sito o l’offerta commerciale, raccoglierei almeno cinque conversazioni recenti e cercherei ricorrenze. Quali parole usano i clienti? Dove esitano? Quale promessa capiscono e quale no? Una pagina di vendita riscritta e testata con pochi contatti può essere un prototipo più utile di un rebranding completo.
Cosa cambia rispetto a brainstorming, Agile e Lean startup
Questi metodi possono convivere, ma non rispondono alla stessa domanda. Confonderli porta spesso a riunioni produttive solo in apparenza, con molte attività e poca chiarezza sul problema da risolvere.
| Approccio | Domanda principale | Quando è più utile |
|---|---|---|
| Metodo centrato sull’utente | Quale bisogno vale la pena affrontare e come possiamo verificarlo? | Quando il problema è ambiguo o le persone sono poco comprese. |
| Brainstorming | Quali idee possiamo generare? | Quando la sfida è già definita e servono molte alternative. |
| Agile | Come sviluppiamo e rilasciamo il lavoro in cicli brevi? | Quando la soluzione è abbastanza chiara e occorre organizzarne l’esecuzione. |
| Lean startup | Quale ipotesi sul mercato possiamo validare con il minimo investimento? | Quando si deve verificare rapidamente un modello di business. |
In pratica, potrei usare l’approccio centrato sulle persone per capire il bisogno, il brainstorming per esplorare le opzioni, il Lean startup per verificare il valore economico e Agile per costruire la soluzione. La sequenza non è obbligatoria, ma il principio resta: non accelerare la costruzione di qualcosa che nessuno considera utile.
Gli errori che fanno perdere valore al metodo
Innamorarsi della prima idea
Un gruppo competente può produrre una soluzione brillante in pochi minuti. Il problema è che la brillantezza interna non dimostra l’utilità esterna. Se l’idea non viene osservata nelle mani degli utenti, resta una convinzione ben presentata.
Intervistare soltanto persone già favorevoli
Parlare con clienti entusiasti crea un’immagine incompleta. Conviene includere anche chi ha abbandonato il percorso, chi usa una soluzione alternativa e chi ha avuto un’esperienza negativa. Sono proprio questi profili a mostrare gli ostacoli più costosi.
Scambiare opinioni per evidenze
Una frase come “tutti vogliono un servizio più veloce” è troppo vaga per guidare una decisione. Bisogna capire quale passaggio rallenta, per chi e con quale conseguenza. Non ogni informazione deve essere quantitativa, ma ogni decisione importante dovrebbe poggiare su un comportamento osservabile o su un test.
Fare workshop senza potere decisionale
Se il team produce idee ma nessuno può approvare un test, l’entusiasmo si spegne. Prima di iniziare bisogna stabilire chi decide, quale budget è disponibile e quale risultato minimo giustifica il passaggio successivo. Anche un limite di 500 euro o dieci ore può essere sufficiente per un primo esperimento, se il problema è ben delimitato.
Leggi anche: Come scrivere una circolare aziendale chiara ed efficace
Misurare solo la soddisfazione
Un utente può dire che il prototipo è “interessante” e poi non usarlo mai. Accanto ai commenti raccoglierei almeno un comportamento concreto, come il completamento di un’attività, il tempo impiegato, il numero di errori o la richiesta di assistenza. Il feedback spiega il perché, mentre il comportamento mostra cosa accade davvero.
Quando l’approccio non è la scelta migliore
Questo metodo non risolve ogni problema. Se un processo deve rispettare un vincolo normativo preciso, se la causa tecnica è già nota o se occorre intervenire immediatamente su un’emergenza, un lungo percorso esplorativo può rallentare inutilmente la risposta.
Ci sono anche limiti organizzativi. La ricerca richiede accesso a utenti reali, tempo per ascoltare e disponibilità a cambiare idea. Se la direzione ha già deciso la soluzione e vuole soltanto una conferma, il progetto diventa una rappresentazione del coinvolgimento, non un vero lavoro di progettazione.
Per questo io userei una regola semplice. Prima di partire, chiederei se esiste una incertezza concreta che un’intervista o un prototipo può ridurre. Se la risposta è no, probabilmente serve un altro strumento, come un’analisi tecnica, un piano operativo o una decisione manageriale più netta.
La qualità di una soluzione si vede dopo il workshop
Il valore non sta nel numero di idee raccolte, ma nella capacità di trasformare un’intuizione in una prova osservabile. Un buon percorso produce una decisione più informata, anche quando porta a scartare la proposta iniziale.
Per iniziare basta scegliere un problema reale, parlare con poche persone direttamente coinvolte, costruire una versione semplice della possibile risposta e fissare una misura concreta. Ascolto, prototipo e verifica sono più importanti di strumenti costosi o riunioni elaborate.
Quando questa abitudine entra nella gestione quotidiana, l’organizzazione smette di progettare soltanto per gli utenti e comincia a progettare insieme a loro. È qui che il metodo diventa davvero utile, soprattutto per chi lavora con risorse limitate e non può permettersi di scoprire troppo tardi di aver risolto il problema sbagliato.
