I quadri di progettazione del prodotto nella pratica: come uscire dalla teoria senza diventare ostaggio del metodo

Ogni team di prodotto, ad un certo punto, scopre i framework. Doppio diamante, Design Thinking, Lavori da svolgere, Design Sprint. Si attaccano al muro, diventano diapositive di processo e, per un po’, danno la confortante sensazione che ormai un metodo esista.

Il problema appare più tardi. Il team segue il rituale alla lettera e fornisce comunque prodotti nella media. I passaggi sono stati completati, i post-it erano incollati e il risultato non è migliorato. La domanda che nessuno si pone ad alta voce è: il quadro aiuta o è diventato teatro?

Questo testo è per chi conosce già la teoria e vuole usarla veramente, senza trasformare il metodo in religione.

Cosa fanno davvero i framework di progettazione per te

Una struttura non ha intelligenza. Non prende decisioni, non capisce il suo utente e non conosce il suo mestiere. Ciò che fa è strutturare il pensiero, fornire una sequenza di domande e impedire al team di saltare passaggi importanti per ansia.

Questa è la tesi: il valore di un quadro normativo sta nel ridurre il costo del pensare bene, non nel sostituire il pensiero. Organizza la conversazione, allinea il team e fornisce un vocabolario comune. Quando inizi a dettare risposte invece di migliorare le domande, diventa una stampella.

Il miglior utilizzo di una struttura è come impalcatura. Lo imposti per costruire e ad un certo punto impari a lavorare senza doverlo guardare in ogni fase del processo.

Doppio diamante nella routine: divergere e convergere veramente

Double Diamond è semplice sulla carta: esplorare il problema (scoprire e definire), quindi esplorare la soluzione (sviluppare e fornire). Due diamanti di apertura e chiusura.

Il punto in cui fallisce in allenamento è quando la squadra salta il primo diamante. La fretta di consegnare fa sì che tutti si precipitino alla soluzione prima di comprendere il problema. Il risultato è un prodotto ben eseguito per la domanda sbagliata.

Applicare veramente significa proteggere la fase di scoperta. Significa resistere alla pressione del “sappiamo già cosa fare” e dedicare tempo alla comprensione del problema prima di progettare la risposta. In un vero team, non si tratta tanto di seguire il diagramma quanto di avere la disciplina di non convergere troppo presto.

Lavori da svolgere: la domanda che cambia il focus

Il lavoro da svolgere non è un processo, è un obiettivo. Invece di chiedere "cosa vuole l'utente", chiedi "quali progressi stanno cercando di fare nella loro vita?" La gente non vuole un trapano; vogliono un buco nel muro e, in fondo, vogliono che venga installata la mensola.

Cambia ciò a cui dai la priorità. Non esiste, ad esempio, una piattaforma di servizi del municipio per “offrire moduli online”. Esiste affinché i cittadini possano risolvere un problema con il minimo attrito. Quando si riformula il problema attorno al "lavoro", le caratteristiche che sembravano essenziali si rivelano rumore.

L'errore comune è usare JTBD come gergo di presentazione senza modificare alcuna decisione. Se il quadro non ha modificato ciò che entra o esce dalla tabella di marcia, non è stato applicato, è stato menzionato.

Design Sprint: potente e spesso abusato

Il Design Sprint comprime scoperta, prototipazione e test in pochi giorni. È eccellente per sbloccare una decisione difficile o convalidare rapidamente una direzione rischiosa.

L’uso sbagliato è trattarlo come un processo standard per tutto. Lo sprint è costoso, concentra i senior per intere giornate. Usarlo per problemi banali è uno spreco; Usarlo senza un problema ben formulato è ancora peggio, perché sprechi le energie del team nel rispondere rapidamente alla domanda sbagliata.

Il Design Sprint ripaga quando c’è una decisione ad alto rischio e con basso consenso. Allora vale oro. A parte questo, di solito è una cerimonia.

Come scegliere tra loro nella vita di tutti i giorni

La scelta non riguarda quale framework sia migliore, ma a quale domanda stai cercando di rispondere ora.

Non so quale sia il problema. Inizia con la scoperta, il primo diamante Double Diamond, le interviste, l'osservazione.
Conosco il problema, ma non capisco la motivazione dell'utente. Utilizza Jobs to be Done per riformulare.
Ho una decisione rischiosa e ho bisogno di indicazioni rapide. Design Sprint.
Ho già la soluzione, devo perfezionarla e consegnarla. Concentrati sull'esecuzione, sul secondo diamante, e testalo nell'uso reale.

Si noti che questi quadri non sono in competizione, coprono momenti diversi. Mescolarli con criteri è più maturo che difendere un unico metodo come verità assoluta.

Combinare strutture senza diventare un patchwork

Raramente un singolo framework gestisce un progetto dall'inizio alla fine. Il team esperto combina gli approcci, ma combinarli in modo inadeguato crea un processo confuso, in cui nessuno sa perché stanno facendo ogni cosa.

Il segreto è trattare ogni struttura come una risposta a una fase, non come un'identità per il team. Puoi utilizzare Double Diamond come scheletro generale, Jobs to be Done per riformulare il problema nella fase di scoperta e un Design Sprint una tantum quando una decisione specifica si blocca. Questa non è incoerenza; Si tratta di utilizzare lo strumento giusto per ogni momento.

Ciò che mantiene sana questa combinazione è la chiarezza di intenti. Prima di adottare qualsiasi tecnica, il team dovrebbe sapere come rispondere a due domande: a quale domanda stiamo cercando di rispondere e come sapremo che questo approccio ha aiutato? Se nessuno può rispondere, il quadro è stato scelto per abitudine o moda, non per necessità.

Un esempio di combinazione che funziona: un team di prodotto presso un ente pubblico mappa il "lavoro" del cittadino (risolvere un problema), utilizza il primo diamante Double Diamond per comprendere le reali barriere all'accesso e solo dopo esegue un breve sprint per progettare e testare il flusso critico. Ogni passo porta logicamente al successivo. È il processo a servire il problema e non il contrario, che è esattamente il contrario di ciò che accade quando i framework si accumulano senza criterio.

La trappola del processo che diventa teatro

Il rischio più grande nella pratica è non scegliere il quadro sbagliato. E' il processo che diventa performance. I team che amano i rituali di progettazione a volte dimenticano che il rituale non è mai stato l'obiettivo.

Ho visto team orgogliosi di seguire il metodo alla perfezione, consegnando prodotti che nessuno utilizzava. La cerimonia ha dato un senso di progresso mascherando l’assenza di decisioni difficili. Un quadro ben eseguito non sostituisce mai il coraggio di ridurre la portata, dire di no e scommettere.

La leadership tecnica matura utilizza le strutture per accelerare il giudizio, non per nascondersi da esso. Quando il team può spiegare perché sta utilizzando un determinato approccio e quando smetterebbe di usarlo, il metodo è al servizio del prodotto. Quando nessuno sa rispondere, il prodotto è diventato un servitore del metodo.

Chiusura

Le strutture di progettazione del prodotto sono strumenti di pensiero, non formule di successo. In pratica, ciò che distingue chi consegna da chi esegue solo rituali è la capacità di sapere quale utilizzare, quando e quando abbandonare.

Il miglior product designer non è quello che segue il processo più bello. È ciò che fornisce il risultato giusto e, se necessario, interrompe il processo stesso per arrivarci.

Se il tuo team continua a seguire i framework senza vedere miglioramenti nei risultati, forse il problema non è il metodo, ma come viene utilizzato. Vale la pena parlarne e qui ci sono altri articoli sulla scoperta e il design nella vita di tutti i giorni che approfondiscono l'argomento.