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

Le 3 C delle user stories: carta, conversazione e conferma

Oggi parliamo di storie, un grande classico per i product owner, e andiamo alla base della loro costruzione esplorando insieme le 3 C delle user stories: carta, conversazione e conferma.

Ma cosa sono le user stories? Sono semplici descrizioni, contenute in una frase, di ciò che un determinato utente vuole ottenere raccontate dal suo punto di vista.
Sono nate nell’ambito dell’Extreme Programming prima dell’inizio di questo millennio (la loro origine si fa risalire al 1998) e sono poi diventate popolari in tutti i processi agile.

User story: qualche esempio di scrittura delle card

Facciamo qualche esempio pratico per capirci meglio.
Immaginiamo di stare sviluppando un sito di annunci (i cosiddetti classified) che consente a venditori e acquirenti di scambiarsi beni materiali e servizi accordandosi tra privati.
La nostra piattaforma avrà user stories come queste:

  • come utente di <nome della piattaforma> , posso effettuare ricerche su articoli specifici.
  • come venditore, posso facilmente consultare la lista di tutti i potenziali acquirenti interessati al prodotto che ho messo in vendita.

Come vedete sono frasi brevi che descrivono cosa un utente vuole fare, raccontate secondo il suo punto di vista.
Un’altra cosa che possiamo notare è che abbiamo più tipologie di utenti: nel primo caso parliamo di un utente generico, nel secondo adottiamo il punto di vista di uno dei principali attori della piattaforma (in venditore).

Possiamo fare la stessa cosa mettendoci dal punto di vista dell’acquirente:

  • come potenziale acquirente di una macchina usata, voglio poter vedere delle foto del veicolo.

Cosa manca ancora in questo esempio?
Manca un dettaglio che per me è la parte più importante delle user stories, la cosiddetta clausola so-that.
Ciò che spiega perché un determinato utente vuole una certa cosa, qual è la sua finalità, qual è il risultato finale a cui tende (o outcome).

La storia potrebbe prendere allora questa forma:

“come potenziale acquirente di una macchina usata, voglio poter vedere delle foto del veicolo così da potermi accertare delle sue condizioni”

O dal punto di vista del venditore:

“come proprietario di un auto che desidero vendere, posso creare una pagina in cui descrivere lo stato dei veicolo e mostrarlo al suo meglio”

Notate che stiamo parlando della medesima funzionalità (le foto associate al prodotto) da due punti di vista differenti: quello del venditore e quello dell’acquirente.

User story: l’importanza del punto di vista

Bene, abbiamo introdotto il formato più classico con cui si scrivono le user stories:

Come <tipo di utente>, voglio <funzionalità> così da <obiettivo o valore per l’utente>.

Semplice ed efficace! Chiunque è in grado di esprimere un bisogno, una necessità o un desiderio secondo questo formato.
Ma non è solo la semplicità ad essere la chiave del successo delle user stories, l’elemento essenziale qui è la prospettiva: il punto di vista che adottiamo ci aiuta a relazionarci con specifiche tipologie di utenti, a metterci nei loro panni.

Sembra un dettaglio ma non lo è.
Ditemi se vi fa lo stesso effetto esprimere le medesime funzionalità come si descrivevano una volta nei documenti di requisiti …

  • il sistema consente all’utente di effettuare una ricerca
  • il sistema consente all’utente di pubblicare online un prodotto
  • il sistema consente all’utente di associare una o più foto a un prodotto

Il significato di queste affermazioni è lo stesso ma nel primo caso rispondiamo con più empatia perché stiamo mettendo l’utente – una persona – al centro della scena.

User story: la conversazione a partire dalla carta

Un errore in cui cadono spesso i team che muovono i primi passi con i framework agili è pensare che una volta scritta la user story tutto sia chiaro e definito.
In realtà chi ha un po’ più di esperienza alle spalle sa bene che la scrittura è solo l’inizio del gioco.
Non dobbiamo dimenticare che la user story comprende tre C:

  • una scheda o carta (= card),
  • la conversazione (= conversation)
  • criteri di conferma (= confirmation).

Le 3 C sono un’allitterazione ideata da Ron Jeffries per chiarire che una user story è più di un semplice testo scritto su carta fisica o su strumento software.
Le user stories sono brevi, non sono fatte per contenere molti dettagli bensì per agevolare delle conversazioni (si parla anche delle storie anche come “placeholder per conversazioni con il team”).
La carta è solo una delle tre C, la più visibile, e anche quella meno importante.

Mi è capitato in passato di lavorare con team che pretendevano di avere il massimo livello di dettaglio nelle storie; questo desiderio di chiarezza e completezza per quanto comprensibile dà l’illusione che tutto sia stato definito e compreso ma non aiuta le persone ad uscire dalla propria comfort zone e fare il “viaggio di scoperta” nei bisogni dell’utente.
E’ dall’interazione tra il product owner, il team allargato e gli utenti che nasce la vera comprensione di ciò che c’è da fare, non da una frase scritta su un pezzo di carta.

Non si tratta di un modo alternativo di scrivere requisiti, la card è “una promessa a due vie” come dice Mike Cohn:

  • la promessa del team di porre domande prima di iniziare a lavorare su una storia
  • la promessa del product owner di essere disponibile ad approfondire l’argomento.

Questi due aspetti insieme ci evitano di dover scrivere corposi documenti di specifiche contenenti ogni singola funzionalità.

Se il team si parla prima di iniziare a lavorare, il product owner può specificare solo quanto basta per poter avere quella conversazione.
E’ la conversazione in sé che rende agile un team, non la scrittura delle storie, l’utilizzo di post-it o di tool come Jira.

User story: la C di conferma

Quando Mike Cohn illustra questa parte delle storie dice che non gli piace iniziare qualcosa se non capisce come saprà quando ha terminato. E a chi piace questa incertezza?
I criteri di conferma di una user story servono proprio a questo; sono il modo in cui il product owner definisce insieme al team ciò che deve essere fatto affinché lo sviluppo possa essere considerato completo.

Ricordate quando a scuola per la prima volta un insegnante vi ha assegnato un riassunto di un libro? Alzi la mano chi non si è chiesto quanto dovesse essere lungo lo scritto!
Ecco, questo è un classico esempio di criterio di accettazione. Per alcuni professori una sintesi di una pagina è accettabile, per altri non si parla di sufficienza sotto le 3 pagine (e non pensate di barare con la dimensione del testo e l’interlinea!).

Una parte della conversazione tra il team e il product owner prima di lavorare una storia riguarderà proprio i criteri di conferma, ovvero come ciò che sarà sviluppato verrà valutato per l’accettazione durante la sprint review.
Si tratta delle “condizioni di soddisfazione” della storia. In altre parole, affinché il product owner possa considerare la user story fatta, una determinata cosa deve fare questo, quello e quell’altro.

Torniamo al nostro esempio di prima quando parlavamo della possibilità di associare delle foto all’auto che il nostro utente vuole mettere in vendita.
Per questa user story potremmo definire criteri di accettazione di questo tipo:

  • i formati di immagine accettati dal sistema (es. jpg, png, ecc.)
  • il peso massimo della singola immagine
  • la possibilità di vedere un’anteprima dell’immagine caricata
  • e magari anche la possibilità di poter ruotare eventuali immagini capovolte prima della pubblicazione.

User story: la prima C da sola non basta!

Siamo arrivati alla fine del nostro excursus sulle user stories.
Come abbiamo visto le storie non sono un nuovo modo di scrivere i requisiti, ma molto di più. Hanno come minimo 3 funzioni:

  • sono un placeholder per una conversazione sui bisogni degli utenti
  • sono strumenti per capire cosa vogliono gli utenti e cosa ha senso realizzare
  • sono un modo per programmare il lavoro del team.

Quindi ricordatevi di prestare attenzione a tutti e 3 gli aspetti: non solo al testo che andrete a scrivere su una scheda, ma anche alle conversazioni sulla funzionalità e ai criteri di conferma che utilizzerete per determinare se la storia è completa.

Note

Questo post è liberamente tratto dalle lezioni di Mike Cohn sulle user stories. Se volete approfondire vi consiglio il suo corso – molto valido – “Better User Stories“.

Nel blog trovate anche diversi post dedicati alle storie. Eccone qui una piccola selezione:

Pensare e testare il prodotto – intervento all’Agile Experience Conference

Recentemente ho preso parte all’Agile Experience Conference organizzata dagli amici di Agile for Italy. Si tratta di incontri live caratterizzati da un taglio pratico e dalla formula intervento iniziale più intervista da parte dei peer.
Giovedì 18 febbraio ho parlato di come “Pensare e testare il prodotto” in compagnia di Roberto Lunazzi, Lorenzo Cassulo e Deborah Ghisolfi.
Abbiamo approfondito quali tecniche usare per creare un prodotto amato dai nostri clienti, quali metriche e quali difficoltà si incontrano.

Qui trovate la registrazione:

Ed ecco a voi una traccia del mio intervento.

Le precondizioni di un buon progetto

Dobbiamo fare una premessa prima di affrontare il momento della discovery di prodotto.
E’ necessario fare un setting quando affrontate progetti di questo tipo per comprendere:

  • chi saranno gli interlocutori (il cliente finale, l’acquirente, lo sponsor in azienda, il responsabile della decisioni finale e chi può influenzare il progetto).
    E’ fondamentale riuscire a mappare tutti questi attori per partire con il piede giusto;
  • qual è esattamente l’obiettivo.
    Quando si fanno attività di questo tipo c’è sempre un’aspettativa da parte dell’azienda, che siano obiettivi di ricavi, quote di mercato piuttosto o volumi di vendita.
    È opportuno fare tante domande prima di iniziare e capire bene quali sono le regole del gioco perché gli obiettivi si possono portare a casa in molti modi e noi dobbiamo capire quali sono i trade-off percorribili.

Prima di tutto vi voglio proporre una distinzione tra prodotti totalmente nuovi e prodotti esistenti che devono essere fatti evolvere, ottimizzati, ecc.
Perché questo? Perché nei due casi abbiamo a disposizione strumenti diversi.

Creare prodotti, ma di che tipo?

Nuovi prodotti

Stiamo parlando di una situazione in cui non abbiamo dati a disposizione di prima mano.
Il prodotto non è presente in azienda; stiamo creando qualcosa di nuovo con cui non ci siamo ancora confrontati.

Cosa faccio di solito io?

Analisi

Faccio un’analisi: cerco gli stessi prodotti o soluzioni simili sul mercato e li studio (se posso li utilizzo direttamente, altrimenti cerco qualcuno che ne abbia esperienza, cerco materiale online, help o video, commenti, ratings).
Queste sono tutte informazioni utili per cominciare a farmi un’idea di questa tipologia di prodotti:
– come sono fatti
– che caratteristiche hanno
– quali sono i loro punti di forza
– eventuali punti deboli.

Personas

L’altro passo che faccio immediatamente è andare a capire chi sarà il mio pubblico.
Dedico tempo alla costruzione delle personas primarie che coincidono con i miei utilizzatori.
Si dice che i PO sono la voce del cliente in azienda ma se questa voce non la ascoltiamo mai dal vivo non stiamo facendo il nostro lavoro, ci stiamo perdendo una grande opportunità.

Con le personas voglio capire quale sarà il mio segmento di pubblico, non solo da un punto di vista socio-demografico.
Qui ho bisogno di scavare in profondità:
– che tipo di bisogni ha?
– quali preoccupazioni?
– cosa vuole ottenere?
– cosa è importante per queste persone?
– che cosa li motiva e li ispira?

Devo riuscire a costruire un profilo a tutto tondo per potermi mettere nei loro panni e verificare che il nuovo prodotto risponda alle sue necessità.

Impact Mapping

Negli anni uno strumento che mi è venuto molto in aiuto nella creazione di nuovi prodotti è l’impact mapping.
E’ una tecnica di pianificazione strategica che ci aiuta a costruire la mappa mentale del progetto:
– qual è esattamente l’obiettivo che vogliamo ottenere
– quali sono gli attori in gioco (e qui tornano in gioco le personas ma non solo)
– quali sono gli impatti che vogliamo produrre ovvero i cambiamenti nel comportamento degli attori
– quali attività (ovvero funzionalità o caratteristiche del prodotto potrebbero aiutarci ad ottenerli).

Per costruire questa mappa si fanno sessioni collaborative, più persone con diversi ruoli e competenze. Maggiore è la varietà e meglio è.

Sessioni collaborative di discovery

Come dico sempre il prodotto è un gioco di squadra, non è qualcosa che fate chiusi da soli dentro il vostro ufficio. Avete bisogno di un confronto continuo nella fase di discovery.

Ecco perché consiglio di sfruttare il più possibile per la creazione di nuovi prodotti le sessioni collaborative di co-creazione: facciamo brainstorming, ad esempio lift-off di progetto o – se ne avete la possibilità – potete proporre degli innovation days o degli hackathon dove diversi team cross-funzionali elaborano idee, le migliori vengono votate e si può arrivare a generare un prototipo dell’idea.

Tutti questi eventi hanno un enorme vantaggio perché portano le persone a bordo, fanno comprendere la sfida e consentono di generare tantissime idee così da selezionare le migliori.

Migliorare prodotti esistenti

Dati ed esperienze di prima mano

Qui possiamo utilizzare tutto quello che abbiamo detto prima ma abbiamo altre frecce al nostro arco. Esistono già degli utenti del nostro prodotto, abbiamo dati di acquisto e di utilizzo.
Sfruttiamo al massimo questi mezzi!
Andiamo a parlare con acquirenti e utilizzatori, intervistiamoli (i dati quantitativi non vi bastano per capire i fenomeni, dovete capire il perché), guardiamo gli analytics, dati di vendita e utilizzo, le registrazioni di sessioni utente, le domande che arrivano all’assistenza clienti o vengono fatte ai commerciali, sondaggi, analisi della customer journey.

Io di solito parto da interviste interne all’azienda per farmi un’idea dei problemi principali, monitoro l’utilizzo e poi vado a fare interviste qualitative.

Interviste JBTD

Potete utilizzare il framework JBTD con cui cercate di capire a quale scopo serve il prodotto o il servizio, sia da un punto di vista più funzionale (è il cosiddetto lavoro primario), sia da un punto di vista emotivo e sociale (come il prodotto fa sentire il cliente, come viene percepito dagli altri).
Perché sono importanti? Perché se non capiamo sulla base di che cosa un utente sceglie il nostro prodotto, quali sono i suoi parametri principali o creiamo una soluzione che non vuole nessuno (e magari questo problema non l’avete con un restyling o un replatforming) o riempiamo il prodotto di funzionalità inutili che non ne aumentano il valore, bensì lo diminuiscono.

Utilizzando anche solo alcuni di questi strumenti avrete raccolto una marea di informazioni su cosa funziona e cosa no, avrete moltissimi spunti su cosa aggredire per primo e avrete generato un backlog di attività.

Pronti per lo sviluppo? No, testiamo l’idea di business

A me piace l’idea di testare l’idea di business (non stiamo parlando di testare il prodotto finito); stiamo parlando di compiere un giro completo prima ancora di partire con un singola riga di codice.
E’ un approccio che è diventato sempre più mainstream negli ultimi anni. Da Lean Startup in avanti è conosciutissimo.

Experiment Map

Qui ci vengono in aiuto una serie di strumenti: ad esempio potete utilizzare un semplicissimo canvas, quello della experiment map. Identificate quali sono le assunzioni più rischiose che stanno dietro alla vostra soluzione, chiarite il risultato che vorreste ottenere e poi costruite un esperimento (il più semplice e meno costoso possibile) per verificare la vostra idea.
Non serve avere il prodotto finito, basta abbozzarlo!

Minimum Viable Product

Ci rifacciamo al concetto di MVP, Minimum Viable Product, una delle idee più bistrattate e meno comprese.
Quando parlo di MVP mi viene sempre in mente l’esempio di Zappos che nel 1999 ha testato l’assunzione più rischiosa che stava dietro alla sua idea di business con un concierge MVP.
Tenete conto che l’e-commerce non era il fenomeno che è adesso. Il founder doveva capire se le persone sarebbero state disposte a comprare qualcosa online – le scarpe – senza poterlo provare.
Ha costruito un negozio finto, un front-end vetrina senza che ci fossero tutti i processi dietro. Ogni volta che qualcuno cliccava sul pulsante “Compra” andava fisicamente a comprare il paio di scarpe in negozio.

Design Sprint

Negli anni gli strumenti sono diventati sempre più sofisticati: pensate al design sprint inventato da Google Venture. In 5 giorni riducete i rischi del lancio sul mercato di un nuovo prodotto o servizio. Partite dalla definizione del problema, fate brainstorming delle possibili soluzioni, scegliete la più promettente, costruite un prototipo e lo validate con potenziali utenti.
Questo non vi fa solo risparmiare tempo e denaro, vi fa risparmiare la creazione di waste.

Conclusioni

In sintesi abbiamo tanti strumenti a disposizione.
Non esiste lo strumento perfetto o un unico strumento per un problema.
Provateli, testateli e cercate quello che più vi risuona, con cui vi trovate bene.

Ma la cosa importante non sono gli strumenti in sé.
Quando penso alla creazione di un nuovo prodotto per me è determinante l’approccio che è fatto di questi ingredienti principali: ascolto, lavoro di squadra, confronto con la realtà (uscite dagli uffici!), utilizzo di dati e sapere di non sapere.
Tutto è ancora da imparare!