Il Design Thinking è un metodo di problem solving centrato sull'utente che alterna fasi divergenti — in cui si esplorano più strade possibili — e fasi convergenti — in cui si scelgono e si validano le soluzioni migliori. Nato nelle scuole di design americane negli anni '60 e codificato da IDEO e dalla Stanford d.school nel decennio successivo, oggi è il framework più usato nel mondo per progettare prodotti digitali che le persone vogliono davvero usare.
Questa guida è pensata per chi progetta interfacce, prodotti e servizi digitali. Non ti racconterà la storia accademica del metodo — la trovi su Wikipedia. Ti mostrerà invece come applicare le 5 fasi del Design Thinking a un progetto UX reale, con esempi concreti, strumenti Figma, e — cosa rara — anche i casi in cui usarlo è una perdita di tempo.
Cosa imparerai leggendo:
- Cos'è davvero il Design Thinking (definizione operativa, non accademica)
- Le 5 fasi del modello Stanford d.school applicate a progetti digitali
- Gli strumenti e i template che userai in ogni fase
- Un esempio end-to-end di Design Thinking applicato a una feature reale
- La differenza tra Design Thinking e Double Diamond (e quando scegliere quale)
- Quando il Design Thinking non serve e che cosa usare al suo posto
Cos'è il Design Thinking
Il Design Thinking è un approccio iterativo alla soluzione di problemi complessi in cui si parte dai bisogni reali degli utenti, si generano molte idee alternative, si prototipano le migliori e si validano con persone vere prima di costruirle davvero. In una frase: prima capisci, poi ipotizzi, poi provi, poi decidi.
Tre caratteristiche lo distinguono da altri metodi di progettazione:
- Centralità dell'utente. Ogni decisione deriva da quello che hai osservato o sentito da persone reali, non da opinioni interne al team.
- Iterazione rapida. Non si disegna una volta sola: si fanno tanti cicli brevi di prototipo → test → revisione, ognuno più preciso del precedente.
- Bilanciamento tra desiderabilità , fattibilità e sostenibilità . Una soluzione valida nel Design Thinking deve essere voluta dagli utenti, realizzabile tecnicamente e sostenibile economicamente. Se manca anche solo una di queste tre, non è una soluzione.
Il metodo è nato per progetti fisici (sedie, strumenti medici, interni d'ufficio) ma è diventato lo standard per i prodotti digitali perché risolve un problema tipico delle startup e dei team di prodotto: scrivere codice per qualcosa che non esiste ancora nella testa degli utenti è la più costosa fonte di spreco nel software.
Chi lo ha inventato (e perché ti interessa)
Le radici del Design Thinking risalgono ai lavori di Herbert Simon ("The Sciences of the Artificial", 1969) e di L. Bruce Archer alla Royal College of Art di Londra negli anni '60. La versione moderna — quella a 5 fasi che vedi in tutti i corsi — è stata formalizzata alla fine degli anni '90 dalla Stanford d.school e resa celebre da IDEO sotto la guida di Tim Brown e David Kelley.
Sapere da dove viene non è nostalgia: ti serve a riconoscere varianti e adattamenti. Alcune aziende usano 4 fasi, altre 6, altre ancora il Double Diamond del British Design Council. Tutte discendono dallo stesso tronco. Conosci il modello base e leggi gli altri come dialetti.
Le 5 fasi del Design Thinking
Il modello Stanford d.school è quello più diffuso e quello da cui partire. Cinque fasi, non sequenziali in modo rigido: si torna indietro ogni volta che serve.
Fase 1 — Empatizza (Empathize)
Obiettivo: capire come le persone vivono il problema, nelle loro parole, nel loro contesto.
Questa è la fase in cui non disegni nulla. Esci dall'ufficio (anche metaforicamente, remote è ok), parli con gli utenti, li osservi mentre usano prodotti simili, raccogli dati quantitativi e qualitativi che illumineranno il problema da angolazioni diverse. L'errore più comune del Design Thinking nei team italiani è saltare questa fase perché sembra "lenta" — poi si scoprono a build feature che nessuno voleva.
Attività tipiche:
- Interviste semistrutturate con 5-8 utenti target (bastano per emergere gli schemi principali)
- Shadowing: osservare utenti mentre svolgono il task in contesti reali
- Analisi di ricerche esistenti (customer support tickets, recensioni, chat, analytics)
- Empathy mapping: un template visuale che sintetizza cosa pensano, dicono, fanno e sentono gli utenti intervistati
Deliverable tipici: note di ricerca, registrazioni, appunti di shadowing, empathy map sintetiche.
Per approfondire i metodi di raccolta dati, leggi la nostra guida alla user research.
Fase 2 — Definisci (Define)
Obiettivo: trasformare quello che hai osservato in un problema preciso e azionabile.
Dopo la fase di empathize avrai decine di insight grezzi. Il passo successivo è sintetizzarli in una frase breve che chiunque nel team possa usare come faro. Questa frase si chiama Point of View (POV) o Problem Statement, e segue spesso la struttura:
[Utente tipo] ha bisogno di [bisogno concreto] perché [insight emerso dalla ricerca].
Esempio: "Una consulente freelance che fattura 15 clienti al mese ha bisogno di capire in 30 secondi chi le deve ancora soldi, perché ogni mattina deve decidere in fretta chi chiamare per sollecitare senza sembrare aggressiva."
Una frase così è tanto potente quanto breve: elimina 80% delle discussioni interne perché tutti capiscono qual è il problema da risolvere e quale no.
Attività tipiche:
- Affinity mapping: raggruppare gli insight simili su una board FigJam
- How Might We: riformulare il problema in domande aperte ("Come potremmo ridurre il tempo di sollecito senza peggiorare il rapporto con il cliente?")
- Persona: creare 1-2 personaggi sintetici che rappresentano i bisogni principali emersi
Fase 3 — Idea (Ideate)
Obiettivo: generare quante più idee possibili per risolvere il problema definito, senza giudicarle ancora.
Questa è la fase divergente. Vale la regola classica del brainstorming di IDEO: quantità prima della qualità , niente critica, tutte le idee valgono finché non si è generata massa critica. Solo dopo si filtra.
L'errore più comune è far partecipare solo designer. Il Design Thinking funziona meglio con un gruppo misto di 4-6 persone: un designer, uno sviluppatore, un product manager, un rappresentante del customer care, eventualmente uno stakeholder di business. Ogni persona porta un lato diverso del problema e contribuisce a idee che un designer da solo non genererebbe.
Attività tipiche:
- Crazy 8: in 8 minuti, ognuno disegna 8 sketch veloci di possibili soluzioni (un minuto a sketch)
- Worst possible idea: generare di proposito soluzioni pessime per sbloccare la creativitÃ
- SCAMPER, mind mapping, storyboarding per variare il taglio
Deliverable: un muro di post-it, sketch, flow, mappe mentali — da filtrare nella fase successiva con criteri chiari (impatto, effort, allineamento con il POV).
Fase 4 — Prototipa (Prototype)
Obiettivo: costruire versioni tangibili e poco costose delle idee migliori, sufficienti per essere testate.
Un prototipo nel Design Thinking non è il prodotto finito. È solo quanto basta per farlo usare a qualcuno e vedere cosa succede. L'errore più costoso è prototipare troppo: un prototipo che richiede 3 settimane di Figma non è un prototipo, è un progetto. Se scopri che l'idea non funziona avrai bruciato 120 ore.
I prototipi si dividono grosso modo in tre livelli di fedeltà :
- Bassa fedeltà (sketch, wireframe su carta): 30 minuti, ottimi per testare il flusso e la priorità dei contenuti senza che le persone si distraggano con il look & feel
- Media fedeltà (wireframe interattivi in Figma): 2-4 ore, buoni per testare la navigazione e il nome delle cose
- Alta fedeltà (prototipo visivo clickable): 1-3 giorni, necessari solo quando stai testando dettagli di UI, tono di voce o micro-interazioni
Per una guida pratica ai wireframe di bassa e media fedeltà , leggi la nostra guida sul wireframe.
Fase 5 — Testa (Test)
Obiettivo: mettere i prototipi davanti a utenti reali e imparare dalle loro reazioni — non convincerli che hai ragione.
Il usability test è lo strumento principale di questa fase. Si scelgono 5 utenti (numero magico confermato da Jakob Nielsen), si danno loro 3-5 task da compiere sul prototipo, si osserva in silenzio cosa succede, si prende nota dei punti di attrito.
Ci sono due grandi pattern che cerchi:
- Dove si bloccano? Una pausa di più di 3 secondi davanti a uno schermo è quasi sempre un segnale che manca un'informazione o che un elemento non è chiaro.
- Cosa dicono con le loro parole? Quando un utente descrive una feature usando termini diversi dai tuoi, hai un problema di naming. È un dato prezioso.
Il test non è la fine del ciclo: è l'inizio del prossimo giro. Dopo ogni test torni in Empathize (con nuove domande più affilate), in Define (per riformulare il problema), in Ideate (per generare varianti delle soluzioni più promettenti) o in Prototype (per affinare quello che c'è). Cinque iterazioni sono normali prima di arrivare a un design che funziona davvero.
Un esempio reale end-to-end
Esempio semplificato ma realistico. Team: una scale-up italiana che ha lanciato un'app per freelance con gestione fatturazione e pagamenti. Metrica sotto target: il 40% degli utenti non completa la prima fattura entro 7 giorni dall'iscrizione.
Empathize. Il designer intervista 6 freelance di recente iscrizione. Shadowing su 2 di loro mentre provano a emettere la prima fattura. Analizza 50 ticket di supporto dei primi 7 giorni. Insight emergente: il campo "Aliquota IVA" intimorisce chi non ha mai fatturato prima — 4 utenti su 6 lo saltano, 2 chiudono l'app perché non sanno cosa scrivere.
Define. POV: "Un freelance al primo anno di partita IVA ha bisogno di sapere quale aliquota applicare al suo servizio, perché non ha un commercialista che gli dica cosa fare e il dubbio lo blocca all'inizio del processo."
Ideate. Il team genera 15 soluzioni in 45 minuti di workshop. Filtrate a 3 finaliste: (a) un bottone "Non lo so, aiutami" che fa comparire una guida interna; (b) un selettore precompilato con l'aliquota più comune per la categoria del servizio scelta in onboarding; (c) un link discreto a un consulente esterno.
Prototype. Vengono costruite in Figma le tre varianti come mock ad alta fedeltà . Ogni variante ha solo le 2 schermate interessate — 90 minuti totali di lavoro.
Test. 5 nuovi utenti con partita IVA aperta da meno di 12 mesi provano le tre varianti in ordine randomizzato. Risultati: la variante (b) — selettore precompilato — è la più veloce (37 secondi vs 2 minuti delle altre) ed è l'unica con tasso di completamento 100%. La (a) confonde (gli utenti si chiedono "se c'è una guida, perché non me la fanno vedere subito?"), la (c) viene percepita come costosa.
Decisione: implementare la (b) con default intelligente basato sulla categoria del servizio. Ora la metrica di target è stata fissata a 80% di completamento fattura entro 7 giorni.
Nessuno scrittore, nessuna intuizione di product manager, nessun brainstorming astratto avrebbe prodotto quella soluzione. L'ha prodotta il metodo applicato con rigore in 6 giorni di lavoro.
Design Thinking vs Double Diamond
Il Double Diamond è una variante britannica del Design Thinking, codificata dal Design Council nel 2005. Condividono lo stesso spirito (alternanza tra divergenza e convergenza) ma organizzano le fasi in modo leggermente diverso.
| Design Thinking (Stanford) | Double Diamond (Design Council) |
|---|---|
| 5 fasi: Empathize, Define, Ideate, Prototype, Test | 4 fasi: Discover, Define, Develop, Deliver |
| Enfasi sull'iterazione rapida | Enfasi sulla separazione tra "il problema giusto" e "la soluzione giusta" |
| Più adatto a progetti digitali veloci | Più adatto a progetti di servizio pubblico e innovazione strategica |
Un designer UX italiano ne incontrerà entrambi nella carriera. In un team lean con sprint da 2 settimane funziona meglio il Design Thinking classico. In un progetto di sei mesi con molti stakeholder funziona meglio il Double Diamond. Impara entrambi, usa quello che il contesto richiede.
Quando il Design Thinking NON serve
Nessun metodo è universale. Il Design Thinking è sprecato in almeno tre situazioni:
- Problemi già risolti. Se stai costruendo l'ennesima pagina di login, il Design Thinking è overkill. Copia i pattern standard (come quelli descritti nel nostro articolo sull'ux login), risparmia le ore di ricerca per problemi che lo meritano.
- Requisiti regolatori rigidi. Se il prodotto deve rispettare vincoli normativi precisi (privacy, finanza, sanità ), la creatività ha poco spazio: serve conoscere le regole, non ideare soluzioni alternative.
- Tempi strettissimi con soluzione ovvia. In certi momenti della vita di un prodotto — un bug grave, una feature richiesta dal cliente top — la soluzione è chiara e va implementata subito. Il Design Thinking in quei casi rallenta senza aggiungere valore.
Il segnale che serve Design Thinking è uno solo: il problema è complesso, gli utenti sono sconosciuti o poco compresi, nessuna soluzione evidente funziona. In quei momenti è l'unico metodo che ti evita di costruire la cosa sbagliata bene.
Strumenti utili per ogni fase
Non servono tool sofisticati, ma averne uno rodato per ogni fase rende il flusso più fluido:
- Empathize: Dovetail o Notion per archiviare note di ricerca, Zoom per interviste remote, Miro/FigJam per empathy map
- Define: FigJam per affinity mapping e POV board, Coda per archivi condivisi di persona
- Ideate: FigJam (Crazy 8 template), Mural, una lavagna fisica quando sei in presenza
- Prototype: Figma è lo standard assoluto per qualunque fedeltÃ
- Test: Maze per test non moderati, Lookback o Zoom per test moderati, Otter.ai per trascrizioni automatiche
Domande frequenti
Qual è la differenza tra Design Thinking e UX Design?
Il Design Thinking è un framework di problem solving applicabile a qualsiasi disciplina (prodotto fisico, servizio, organizzazione). Lo UX Design è la disciplina specifica che progetta esperienze d'uso di prodotti digitali. Uno UX designer bravo usa il Design Thinking come metodo, ma il Design Thinking da solo non basta a fare UX — servono anche conoscenze tecniche di interaction design, visual design, accessibilità , ricerca quantitativa, metriche di prodotto.
Quanto dura un ciclo di Design Thinking?
Dipende dalla scala del problema. Un ciclo veloce su una singola feature può durare 5-10 giorni lavorativi. Un design sprint alla Google Ventures comprime l'intero processo in 5 giorni. Un progetto grande può richiedere 6-8 settimane per completare tutte le fasi con rigore. Il principio chiave è: meglio 3 cicli da 10 giorni che 1 ciclo da 30 giorni, perché l'iterazione rapida è la fonte del valore.
Serve essere designer per usarlo?
No. Il Design Thinking è nato come metodo multidisciplinare proprio per far collaborare persone con background diversi. Product manager, sviluppatori, consulenti, insegnanti, medici: tutti possono applicarlo. Un UX designer ha il vantaggio di saperlo facilitare meglio grazie alla pratica con wireframe, prototipi e test di usabilità , ma la metodologia in sé è trasversale.
Design Thinking e metodologia Agile sono compatibili?
Sì, e vengono usati insieme nella maggior parte delle aziende moderne. Il Design Thinking copre la fase di discovery (capire cosa costruire), Agile copre la fase di delivery (costruirlo iterativamente). Molti team li alternano: uno sprint di discovery Design Thinking per definire le nuove feature, poi sprint Agile di sviluppo, poi di nuovo discovery. Per approfondire leggi il nostro articolo sullo UX Design Agile.
Qual è il libro migliore per iniziare?
"Change by Design" di Tim Brown (CEO di IDEO) è il manifesto del metodo e si legge in un weekend. Per un'applicazione più pratica al software digitale, "The Design of Everyday Things" di Don Norman è un classico intramontabile. Trovi entrambi nella nostra selezione di libri di UX Design per livello.
Prossimi passi
Se vuoi applicare il Design Thinking al tuo prossimo progetto digitale, il modo più efficace è imparare facendolo con un mentor che ti corregga. Il corso completo di UX Design di CorsoUX dedica 30+ ore di lezione pratica al Design Thinking applicato: empathy map reali, POV riscritti decine di volte, workshop di ideation con il team del corso, prototipi Figma costruiti da zero e testati con utenti veri. Al termine esci con 2-3 casi studio da mettere nel portfolio che seguono questa metodologia alla lettera.
Nel frattempo puoi partire da queste tre letture gratuite per costruire le basi:
- Le 10 euristiche di Nielsen — il linguaggio comune del mestiere
- La guida alla user research — come condurre le interviste della fase Empathize
- Come fare wireframe efficaci — la skill centrale della fase Prototype
