La mentalità del facilitatore: azionare il pedale del freno
Il design thinking non è solo una scusa per giocare con i post-it; è un approccio rigoroso e strutturato per risolvere problemi altamente ambigui, comprendendo a fondo l'utente finale. Come facilitatore di questo processo, devi agire come il "Pedale del Freno" per la stanza. I team sono naturalmente portati a correre verso le soluzioni, specialmente quando la stanza è popolata da ingegneri, operatori o dirigenti. Il tuo compito principale è combattere questo istinto. Devi costringere il team a rimanere nell'ambiguità scomoda e torbida dello spazio del problema finché la vera natura del dolore dell'utente non diventa innegabile. Se tentano di saltare a una soluzione prima di aver compreso appieno la difficoltà dell'utente, devi riportarli indietro con fermezza.
Quando il framework funziona davvero (e quando fallisce)
Questo workshop è più efficace quando ti trovi di fronte a un problema "complesso" (wicked problem). Si tratta di sfide notoriamente mal definite, senza un chiaro precedente storico all'interno della tua organizzazione, o che si basano fortemente su comportamenti umani complessi, come capire come rendere un processo di onboarding altamente tecnico meno intimidatorio per un utente non tecnico. Il design thinking è l'intervento giusto quando le tue soluzioni attuali sembrano obsolete, o quando sospetti che siano basate su ipotesi interne e politiche organizzative piuttosto che su prove empiriche dell'utente. Inoltre, è un eccellente meccanismo per abbattere i silos dipartimentali consolidati, o quando un team è bloccato in un ciclo di "business as usual" e ha disperatamente bisogno di sbloccare un'innovazione genuina e laterale. Fallisce, tuttavia, quando il problema è puramente tecnico o quando la soluzione è già nota e il workshop viene utilizzato solo come esercizio teatrale per ottenere consenso.
Curare la stanza e preparare il terreno
La magia di un workshop di design thinking deriva interamente dalla collaborazione radicale e interfunzionale. Dovresti puntare a un gruppo ristretto di cinque-otto partecipanti. Questo gruppo deve assolutamente includere un "Decisore", la persona con l'autorità e il budget finali per dare il via libera al progetto, assicurando che il risultato non rimanga solo in un cassetto. Hai anche bisogno di un Esperto del Cliente, come un agente di supporto di prima linea o un ricercatore UX dedicato, che parli con l'utente finale ogni singolo giorno e comprenda il suo vocabolario reale e schietto. Completa la stanza con i Costruttori che comprendono i vincoli tecnici e finanziari per mantenere le idee ancorate alla realtà, e un "Jolly" da un dipartimento completamente estraneo per fornire una prospettiva fresca e imparziale. Non tentare una sessione di Design Thinking senza dati qualitativi grezzi; non puoi empatizzare con un foglio di calcolo o un grafico a torta. Prima ancora che la sessione inizi, imponi che ogni partecipante guardi almeno un'intervista utente registrata o legga un gruppo di ticket di supporto clienti grezzi. Altrettanto importante, stabilisci l'aspettativa esplicita che i partecipanti debbano lasciare i loro ego, titoli e supposizioni alla porta. Sono lì per scoprire cosa è vero, non per convalidare ciò che già credono sia giusto.
Navigare nel caos: la fase di esecuzione
Una sessione tipica dura mezza giornata o una giornata intera, muovendosi metodicamente attraverso quattro fasi distinte. Inizia con la fase di Empatia, immergendo il team nei dati dell'utente per redigere una dichiarazione del problema chiara e incentrata sull'uomo. Se quella dichiarazione suona come un requisito tecnico, come "abbiamo bisogno di un database più veloce", devi costringere il team a riscriverla dalla prospettiva dell'utente, come "l'utente abbandona il carrello perché la lunga schermata di caricamento causa ansia riguardo alla sua carta di credito". Da lì, il team passa alla fase di Ideazione, impegnandosi in un brainstorming divergente. Qui, devi applicare senza pietà la regola del "Sì, e..." dell'improvvisazione per proteggere le idee fragili e in fase iniziale da critiche premature. Infine, il team deve passare alla fase di Prototipazione e Test, dove sono costretti a smettere di parlare e iniziare a costruire prototipi a bassa fedeltà utilizzando materiali economici come carta o wireframe, testandoli immediatamente contro la realtà.
Ingegnerizzare la svolta
Durante tutta la sessione, devi mantenere il team intellettualmente onesto ponendo domande acute e scomode. Sfidali continuamente sul fatto che stiano davvero risolvendo il problema per l'utente, o stiano solo progettando una soluzione per rendere più facili i loro processi interni. Chiedi loro di identificare l'assunto più rischioso alla base della loro idea preferita, o come potrebbero risolvere il problema se avessero zero budget e solo una settimana per il lancio. Quando qualcuno è molto critico nei confronti di un'idea, non permettere loro di ucciderla e basta; costringili ad articolare in quali specifiche condizioni di mercato quell'idea potrebbe effettivamente funzionare. Devi rimanere estremamente vigile contro le modalità di fallimento comuni. La più pericolosa è saltare completamente la fase di empatia e correre direttamente all'ideazione, il che porta costantemente un team a risolvere brillantemente il problema sbagliato. Devi anche combattere la mentalità del "Sì, ma...", che è l'assoluto killer dell'ideazione precoce. Proteggi il processo dal "Design by Committee", dove idee audaci vengono fuse per accontentare tutti, risultando in soluzioni annacquate e mediocri; abilita il Decisore a prendere la decisione finale e difficile. Infine, impedisci al team di complicare eccessivamente i loro prototipi. L'obiettivo è imparare rapidamente, non costruire perfettamente.
Ottenere di più dalla sessione
Due mosse approfondiscono questo processo. Durante la fase di empatia, fai in modo che un membro del team interpreti la persona target in un'intervista simulata, in modo che il resto del team possa esercitarsi a sondare i punti dolenti prima di parlare con utenti reali. Durante l'ideazione, assegna a qualcuno il ruolo di avvocato del diavolo, per mettere alla prova le idee con casi limite e difetti strutturali prima di iniziare la prototipazione. L'artefatto che crei in questa sessione non è un oggetto prezioso da difendere; è semplicemente un'ipotesi in attesa di essere testata. Il mandato uscendo dalla stanza è di prendere questi prototipi a bassa fedeltà, metterli di fronte a utenti reali, fallire il più rapidamente ed economicamente possibile, e riportare gli apprendimenti grezzi per la prossima iterazione. Il vero lavoro inizia nel momento in cui lasci i tuoi ego alla porta e ti metti nei panni dei tuoi utenti.
