Le 5 fasi del Design Thinking

Come avviene praticamente il processo di sviluppo del prodotto secondo questo framework?

Qualche settimana fa abbiamo parlato di cos’è il Design Thinking e come possa essere impiegato per la risoluzione di problemi che hanno al centro le persone. Oggi entriamo nel dettaglio di questo processo e delle sue diverse fasi.

La maggior parte delle aziende e dell’industria utilizza un processo che va da quattro a sei fasi e tipicamente è composto da un ciclo progettuale che precede il processo di sviluppo. Si va dallo sviluppo del concept all’ideazione di alto livello, dalla progettazione di dettaglio al test fino all’implementazione vera e propria con lo scaling della produzione e delle operations.

Il Design Thinking formalizza la prima parte del processo, ovvero tutto ciò che avviene nella fase progettuale prima dello sviluppo.
Questo è il motivo per cui in alcuni schemi e rappresentazioni potreste vedere 6 fasi invece di 5: in coda al framework di Design Thinking vero e proprio trovate lo step fattuale (come potete vedere nell’immagine in fondo al post ripresa dal sito Nielsen Norman Group).

Le 5 fasi del Design Thinking
Le 5 fasi del Design Thinking: Empatizzare, Definire, Ideare, Realizzare un prototipo, Testare

Una cosa importante da notare è che il framework si applica perfettamente sia ai prodotti che ai servizi. Non è necessario adottarlo solo per la creazione di prodotti fisici, anche i servizi che per loro natura sono per lo più immateriali possono essere costruiti con successo con il Design Thinking.
Il processo è tutt’altro che casuale: si basa su una serie di passaggi discreti che, se svolti correttamente e con attenzione, sono affidabili e portano a risultati concreti e ripetibili.
Vediamoli!

Fase 1: Empatizzare (Emphatize)

Il processo di sviluppo del prodotto inizia con la fase di sviluppo del concept, step che a sua volta può essere suddiviso in ulteriori sotto-passaggi.
Il primo di questi passaggi è l’attività di analisi delle esigenze del cliente (ne abbiamo già parlato in riferimento alle personas e alla metodologia jobs to be done).
Questa fase ha come input il risultato del processo di pianificazione – il mission statement – e si conclude con un elenco validato delle esigenze dei clienti.

Empatizzare significa condurre ricerche online e sul campo per sviluppare la conoscenza di ciò che gli utenti fanno, dicono, pensano e sentono.

Immaginiamo che il nostro obiettivo sia migliorare un’esperienza di onboarding per i nuovi utenti. In questa prima fase parliamo con alcuni utenti reali, li osserviamo direttamente nel contesto in cui usano il prodotto / servizio. Andiamo a scoprire cosa fanno, come pensano e cosa vogliono, ponendoci domande di questo tipo: “cosa motiva o scoraggia gli utenti?“, “dove provano frustrazione?“, “quale bisogno rimane insoddisfatto?”.

L’obiettivo di questa fase è raccogliere abbastanza osservazioni da poter davvero iniziare a entrare in empatia con gli utenti e le loro prospettive.

Fase 2: Definire (Define)

Durante la fase di definizione vengono messe insieme e condivise le informazioni create e raccolte durante la fase di empatia. In questo momento vengono analizzate e sintetizzate le osservazioni per definire i problemi centrali che il gruppo di lavoro ha identificato.

Il problema da risolvere dev’essere definito dal punto di vista delle persone, non come un obiettivo di business.
Facciamo un esempio: invece di definire il problema come un bisogno dell’azienda del tipo “Dobbiamo aumentare la nostra quota di mercato dei prodotti alimentari tra le giovani adolescenti del 15%“, un modo molto migliore per formularlo potrebbe essere “Le adolescenti hanno bisogno di mangiare cibo nutriente per sentirsi bene, essere sane e crescere in salute“.

La definizione del problema aiuterà i progettisti a raccogliere idee per stabilire caratteristiche e funzioni del futuro prodotto o servizio.

Al termine della fase di definizione si inizia a passare alla fase successiva mediante domande che possono stimolare idee e conversazioni.
Tipicamente queste domande sono formulate così: “Come potremmo… incoraggiare le adolescenti a compiere un’azione che le avvantaggia e coinvolga anche il tuo cibo-prodotto o servizio dell’azienda?

Fase 3: Ideare (Ideate)

Durante la terza fase del processo di Design Thinking, i designer sono pronti per iniziare a generare idee. Hanno raccolto informazioni per capire gli utenti e le loro esigenze nella fase dell’empatia, hanno analizzato e sintetizzato le osservazioni nella fase di definizione e sono arrivati ad una dichiarazione del problema incentrata sulle persone direttamente interessate.

Con questo bagaglio di conoscenze acquisite, il team di lavoro inizia a “pensare fuori dagli schemi” per identificare nuove soluzioni al problema e cerca modi alternativi di rappresentarlo.

In questa fase si applicano tipicamente diverse tecniche di ideazione. Non ce n’è una migliore di un’altra, ne esistono a centinaia e potete scegliere quella che vi è più consona o provarne diverse applicate al medesimo problema (brainstorming, brainwriting, worst possible idea e il metodo SCAMPER).
Le sessioni di Brainstorming e Worst Possible Idea sono di solito utilizzate per stimolare il pensiero creativo ed espandere lo spazio del problema.

Un aspetto importante in questa fase è ottenere quante più idee o soluzioni possibili al problema. Non fermiamoci alla prima idea che ci sembra essere risolutiva!
Il Design Thinking da questo punto di vista non è un approccio economico, sostiene anzi la necessità di generare una quantità di idee perché è da questa diversità che emergeranno le migliori risposte al problema.

Fase 4: Realizzare un prototipo (Prototype)

Il team di progettazione a questo punto andrà a produrre una serie di versioni ridotte e poco costose del prodotto / servizio in modo da poter esaminare la soluzione dei problemi individuati nella fase precedente.
Non pensate a nulla di sofisticato: i prototipi possono essere schizzi su carta, modelli creati con carta e cartone, scarne interfacce digitali o qualsiasi altro tipo di rappresentazione veloce che consenta di trasmettere l’idea agli interlocutori.

I prototipi possono essere condivisi e testati all’interno del team stesso, in altri reparti o su un piccolo gruppo di persone, clienti o potenziali clienti.

Questa è una fase sperimentale e l’obiettivo è identificare la migliore soluzione possibile per ciascuno dei problemi individuati durante le prime tre fasi.
Le soluzioni implementate nei prototipi vengono una per una indagate, accettate, migliorate, riesaminate o rifiutate sulla base dei feedback degli utenti.

Alla fine di questa fase il team di progettazione avrà un’idea più concreta dei vincoli inerenti al prodotto / servizio e dei problemi riscontrati oltre che una visione più chiara di come si comporteranno, penseranno e si sentiranno gli utenti reali interagendo con esso.

Fase 5: Testare (Test)

L’ultima fase del Design Thinking consiste nel testare rigorosamente il prodotto completo utilizzando le migliori soluzioni individuate durante la fase di prototipazione.
E’ il momento di tornare dagli utenti per raccogliere feedback.
Il prototipo viene messo di fronte a clienti reali e si verifica che raggiunga gli obiettivi prefissati.
Dobbiamo chiederci a questo punto “la soluzione soddisfa le esigenze degli utenti?” e “ha migliorato il modo in cui si sentono, pensano o svolgono le loro attività?

Questa è la fase finale del modello a 5 fasi, ma essendo un processo iterativo, i risultati generati durante il test vengono spesso utilizzati per ridefinire uno o più problemi, riconsiderare la comprensione degli utenti, le condizioni di utilizzo, il modo in cui le persone pensano e si comportano.
Alla fase di test segue lo sviluppo vero e proprio, quello che per alcuni è il sesto step.

Il processo di Design Thinking
Il processo di Design Thinking secondo Nielsen Norman Group

Il Design Thinking non è lineare

Quando si parla di fasi siamo portati a pensare a un processo diretto e lineare in cui uno step segue all’altro e ha una conclusione logica durante i test degli utenti. Tuttavia nella pratica il processo di Design Thinking viene eseguito in modo più flessibile e non lineare.

Ad esempio, diversi gruppi all’interno del team di progettazione possono condurre più di una fase contemporaneamente, oppure i designer possono raccogliere informazioni e prototipi durante l’intero progetto in modo da dare vita alle proprie idee e visualizzare le soluzioni dei problemi.
I risultati del test possono rivelare alcune intuizioni sugli utenti, che a loro volta possono portare a un’altra sessione di brainstorming (Ideate) o allo sviluppo di nuovi prototipi (Prototype) .

Tutto questo può sembrarvi caotico ma non lo è… abbiate fiducia nel processo!

Il processo di Design Thinking
Il processo di innovazione secondo il Design Thinking

Chi scrive le user stories nel tuo Scrum team?

Se pensate che sia una domanda retorica ebbene non lo è!
E’ anzi un interrogativo su cui può essere utile mettere a confronto esperienze di vita diverse.
Questa riflessione nasce in seguito alla partecipazione ad un meetup di Pierluigi Pugliese intitolato “Stupidaggini che avete sentito su Scrum, Ep. 3: Le User Stories non si scrivono!”, organizzato all’interno del gruppo Milano Scrum/Agile User’s Group.

Il titolo – inutile dirlo – mi ha attirato ed ero sicura che potesse aggiungere spunti interessanti alle riflessioni su uno degli strumenti più utilizzati dai Product Owner.
Ma non parleremo soltanto di chi scrive le user stories, smonteremo anche alcune “leggende metropolitane” che derivano da cattive pratiche ed insegnamenti discutibili discussi durante l’incontro con l’Agile coach.

Inutile dire che molti di questi comportamenti errati li ho vissuti in prima persona e in alcuni casi so di esserne stata anche corresponsabile, quindi voglio fare la mia parte nel smantellarli insieme a voi.
Nella mia esperienza con diversi development team Scrum ho visto un po’ tutte le situazioni: dai team che non fanno partire lo sviluppo se non ci sono user stories super-dettagliate, al PO che si sobbarca l’intero onere della chiarificazione dei bisogni, ai team che che contribuiscono solo al livello degli acceptance criteria fino a quelli più navigati che sono in grado di scrivere storie end-2-end e spacchettarle a dovere.
Tutte queste situazioni – giuste e sbagliate – sono dei pattern ed è utile sapere come affrontarle.

Ma partiamo dalla prima di queste male pratiche…

Il minimalismo delle user stories

Le storie sono:

  • il valore di business che vogliamo generare per l’utente
  • una promessa di conversazioni
  • riassumono l’aspettativa di business
  • descrivono l’attività da fare
  • sono un elemento di pianificazione
  • non si scrivono

Vi ritrovate in queste affermazioni?
C’è forse qualcosa che vi stona?
Davvero le user stories non si scrivono? Cosa intende dire Pugliese?

Pierluigi con questa affermazione provocatoria vuole ribadire che le user stories non sono semplicemente un modo un po’ diverso di esprimere i requisiti, un altro tipo di formato, bensì piuttosto un modo minimalista per descrivere le funzionalità e di semplificare la parte burocratica.

Questo approccio minimalista funziona a patto che la conversazione tra stakeholder, sviluppatori e Product Owner avvenga davvero.
La scrittura è secondaria; la card riassume la conversazione e non ne contiene tutti i dettagli, solo ciò che serve al team per ricordarsi cosa deve fare.

Capite bene che questo approccio definito lightweight dagli agilisti (= leggero) sta in piedi se e solo se una reale interazione avviene.
Se non c’è un momento di confronto e di approfondimento qualsiasi user story sarà monca, una promessa (di conversazione) non avvenuta.
E a quel punto nascerà inevitabilmente la richiesta di una maggiore documentazione.
Infatti una cosa che mi è spesso capitato di notare è che quando i team sono meno maturi tendono a utilizzare le storie come copertine di Linus e chiedono al Product Owner di specificare e dettagliare molto di più.

Quando ravviso questo comportamento so che è il momento di alzare le orecchie.
Può essere un indicatore rilevante del fatto che:

  • il chiarimento non è ancora avvenuto (la card non serve a eludere la conversazione)
  • Il vero valore dello strumento user stories non è stato compreso (siamo di fronte a una trasposizione dei vecchi documenti di requisiti)
  • il team demanda in toto la chiarificazione al PO (di questo aspetto ne parliamo più in là…)
  • c’è scarsa fiducia tra gli interlocutori (questo – se vero – è l’aspetto più problematico che richiede attenzione immediata).

Le parole di Pugliese per me sono sempre illuminanti…

Senza la conversazione le user stories non hanno senso. Non sono una religione alternativa per scrivere i requisiti! Se usate in maniera stupida, meccanica, inutile e dannosa fanno spegnere il cervello agli sviluppatori

Chi fa la business analysis?

Chi è l’owner della business analysis? La domanda sembrerebbe retorica… in fondo esiste una figura professionale proprio per questo, tuttavia negli Scrum team come sapete non ci sono singoli “detentori” di attività.
E’ un punto importante spesso poco capito. Nel team ideale tutti fanno tutto, o meglio sono in grado di fare tutto. Nella realtà spesso non è così perché le competenze e le seniority sono diverse, ma pratiche come il peer programming e le pair review ci vengono in aiuto facendo sì che la conoscenza di tutto il team aumenti progressivamente con il tempo.

La stessa cosa vale per l’analisi dei requisiti.
Magari date per scontato che il momento della chiarificazione dei bisogni sia appannaggio del Product Owner e del business analyst (se avete la fortuna di averlo) ma non è così!

“Voglio che il team faccia business analysis” – ha insistito il coach durante il meetup – “Più persone possibili devono saper fare le domande giuste e ovviamente devono avere competenze di dominio sufficienti per fare le domande giuste”.

Ma a cosa punta questo approccio? La finalità è avere una responsabilità condivisa dell’intero Scrum team sul risultato finale. L’analisi è una premessa fondamentale per fare la modellazione di un sistema attraverso le user stories.
Per questo motivo secondo Pugliese è un’attività che può essere portata avanti direttamente dal team con gli stakeholder senza necessariamente la presenza del Product Owner (ricordate quando si diceva di “smettere di fare il piccione viaggiatore”?)

Il vero ruolo del Product Owner

Ma se il product owner non scrive le storie e non fa chiarificazione – ha chiesto un partecipante – qual è esattamente il suo ruolo?
Esattamente quello che prescrive la Scrum Guide: essere il responsabile di massimizzare il valore prodotto.

Il PO non fa chiarificazione, può partecipare a questa attività ma non è il suo focus primario. Il product owner regola il sistema dal punto di vista delle priorità; decide cosa fare del backlog (se una storia entra, non entra e con quale priorità). In questo modo fa strategia di prodotto.
Impiegarlo solo per spiegare o scrivere le user stories è di fatto svilire questa figura a un lavoro di segretariato, quando invece il suo vero scopo è capire cosa c’è di valore e come massimizzarlo.

Non possiamo pensare che gli stakeholder si mettano d’accordo sulle priorità perché hanno solitamente interessi troppo diversi. Il team può chiarire autonomamente cosa vuole ottenere lo stakeholder, ma poi è con il PO che ci si confronta sulle priorità.
Non è compito degli sviluppatori, dei designer o degli analisti decidere cosa è più importante e cosa no.

Detto questo vi chiedo: nella vostra esperienza quanta parte del lavoro del PO è focalizzato sulla massimizzazione del valore e quanto sulla scrittura e la chiarificazione? Adesso che sapete qual è l’approccio più produttivo ed efficace avete voglia di condividerlo con i vostri team?

3 consigli per esercitare meglio la tua product ownership

Conoscete Robbin Schuurman? E’ un Agile Coach e Scrum Master Trainer di origini olandesi che ha alle spalle un’esperienza di Product Owner e prima ancora di Project Manager.
E’ anche un prolifico autore di articoli e post sul suo blog, su Medium e Scrum.org.
In questi giorni ascoltavo una puntata di Product Owner Podcast di cui è stato ospite per parlare delle responsabilità del PO e di come dire no.

Abbiamo già parlato in passato di questa responsabilità del PO.
Schuurman ribadisce che dire no è una delle cose più difficili che il product owner deve fare e allo stesso tempo uno dei modi più efficaci per creare valore.
Proprio così! Creare valore attraverso la negazione. Perché di 10 idee o richieste che arrivano sul nostro tavolo statisticamente una sola è veramente rilevante per le nostre personas primarie mentre le altre 9 – che magari sono comunque buone idee – non lo sono.
Quindi dire no alla maggior parte delle richieste ha la finalità di preservare il massimo valore del prodotto che state gestendo.

Speriamo di poter leggere presto qualche chicca nel prossimo libro di Schuurman in uscita “50 Shades of No”; nel frattempo lui ha suggerito 2 modi immediatamente spendibili per dire no e condiviso alcuni consigli per esercitare al meglio la product ownership che trovo pratiche e centrate. Ve le riassumo.

Dire no in modo gentile e perentorio

Sostiene il coach: “Dire no è difficile per moltissimi Product Owner. È difficile perché ci sono tantissime persone che chiedono o esigono determinate funzionalità. Massimizzare il valore è una tua responsabilità e lo fai mediante lo stakeholder management e dicendo no”.

Ecco due esempi efficaci per un NO “chiaro e tondo”:

  • non implementiamo la funzionalità X perché non è coerente con la product vision
    Questo è un no molto potente, ma presuppone che abbiate formulato una product vision e che sia stata anche condivisa con gli stakeholder
  • non lavoreremo sul requisito X perché non è di valore per i clienti e gli utenti
    Anche questa affermazione è perentoria e contiene a sua volta un presupposto: che abbiate preso il tempo di validare con questi interlocutori cosa sia realmente di valore.

In sostanza il presupposto per poter dire no con credibilità è fare bene l’attività di stakeholder management. Attendiamo “50 Shades of No” per prendere altri spunti…

Non tutti gli stakeholder sono ugualmente importanti

“Chi sono i tuoi stakeholder e con chi spendi il tuo tempo?” ci chiede Chris.
Nella sua esperienza ha incontrato molti product owner che trascorrono tanto tempo a gestire gli stakeholder (e questa di per sé è una cosa positiva!) senza tuttavia fare dei distinguo in termini di importanza o dedicando troppa energia a quelli meno importanti.
Gli stakeholder meno importanti sono solitamente quelli con poco potere e poco interesse per il prodotto finale; gruppi di persone che dovrebbero essere tenuti d’occhio saltuariamente.

“Nelle pratiche quotidiane molti PO sembrano dare ugualmente importanza a tutti. Mi dispiace… questo non è vero! Non tutte le parti interessate sono ugualmente importanti! Alcuni hanno un alto interesse per il prodotto, altri un interesse basso… alcuni hanno molto potere, altri no… alcuni collaborano con voi nella creazione, altri sono solo interessati all’impatto che il vostro prodotto avrà sul loro dipartimento e sulle persone”.

E’ fondamentale secondo il coach essere ben consapevoli di quali sono gli stakeholder più importanti e meno importanti. Robbin Schuurman ci suggerisce di creare una mappa degli stakeholder così da organizzare il nostro tempo con le parti interessate in modo più efficace, efficiente e intelligente (è un tema che abbiamo toccato in relazione agli stakeholder).

Esercitati ad agire da owner

Non è inusuale all’inizio della carriera come PO trovarsi in situazioni in cui non si ha alcun mandato, alcun potere decisionale o alcuna libertà. E’ capitato a tutti noi e in breve tempo abbiamo realizzato che dovevamo rimboccarci le maniche.
Non è la Scrum Guide o qualche guru dell’Agile a venirci in aiuto quando si tratta di guadagnare autorevolezza sul campo di gioco.

Quello che potete cominciare a fare (in qualsiasi momento) è comportavi da “owner”, da proprietari del prodotto.
Non avete bisogno di chiedere il permesso di sviluppare una nuova funzionalità o dedicare del tempo alla risoluzione di bug o alla riduzione del debito tecnico. Schuurman ci incita a comportarci da proprietari e non da proxy.

“Devi smettere di fare lo scriba e iniziare a comportarti da owner! Il modo in cui ti presenti agli stakeholder, il modo in cui presenti il tuo prodotto e il modo in cui agisci (parli, ti comporti, ti presenti, ecc.) determinano il mandato che ottieni! Se inizi ad agire come un vero product owner, ad assumerti la responsabilità, a formulare un piano dimostrando che ti prendi cura del prodotto e del tuo team, questo ti aiuterà ad aumentare il tuo mandato”.

Questo è un punto cardine sottolineato dall’autore: tra le responsabilità del PO c’è creare un piano, costruire il prodotto e renderlo di successo (in questo ordine!). Se non ti sei preso il tempo di elaborare un tuo piano qualcun altro te ne affibbierà uno. Del resto la delivery ha bisogno di una tabella di marcia, una previsione, una guida per un arco di tempo che va dai 3 ai 6 mesi, senza che diventi “il santo graal” né tantomeno sia scolpito nella pietra.
Piano e vision devono precedere la creazione del product backlog.

Smetti di fare il piccione viaggiatore…

Schuurman riporta la sua esperienza di coaching: “Quello che vediamo fare abbastanza spesso dai Product Owner è che iniziano a fungere da proxy, un gateway, l’unico punto di ingresso, verso il team di sviluppo.
Il team non sono autorizzati a parlare con gli stakeholder, i clienti e gli utenti; tutte le comunicazioni in questi team passano attraverso il Product Owner
”.

Esercitare il controllo non significa fare da tramite tra gli stakeholder e il team.
Questa mala pratica ha un costo enorme in termini di tempo per il PO oltre a rivelarsi inefficace e diseducativa per lo Scrum team.

Un product owner consapevole del proprio ruolo supporta il più possibile la comunicazione diretta tra stakeholder, clienti, utenti, business, sales e sviluppo.
In questo modo il team recepisce direttamente i feedback sul prodotto, acquisisce comprensione degli utenti e del business.
Per quanto il mandato del PO sia ampio e versatile non c’è bisogno di affrontare tutti i problemi da solo; si può fare leva sulla squadra nel momento in cui ha compreso la visione di prodotto, la direzione in cui vuoi andare e quali sono i prossimi passi da compiere.

Tra i valori agili ci sono l’autonomia e il coraggio: non dimentichiamo di lasciare spazio al team per esercitarli! Una volta che il PO ha condiviso la vision di prodotto e ha fornito un obiettivo chiaro per lo sprint , lascia che gli sviluppatori si organizzino a riguardo e che prendano tutti i contatti che servono per costruire al meglio le funzionalità richieste, compresa la comunicazione diretta con gli stakeholder.
E se proprio qualcosa va storto, c’è la Sprint Retrospective con il team per scoprire cosa non ha funzionato e come migliorare in futuro.