Design Thinking: che cos’è e come può esserti utile

Quali sono le caratteristiche dei prodotti e dei servizi di successo? Che cosa rende un’innovazione tale? Ve lo siete mai chiesto?
Il Design Thinking ha una risposta precisa a queste domande.
Sto seguendo un corso del MIT dedicato al pensiero progettuale e approfitto per riorganizzare le idee.

Che cos’è il Design Thinking

Il Design Thinking è un approccio sistematico per creare innovazioni di successo, una metodologia per l’innovazione che combina capacità analitiche, attitudini creative e collaborazione tra le discipline.
In altre parole Il Design Thinking è un processo per la risoluzione creativa dei problemi.

Questo approccio è stato codificato attorno agli anni 2000 in California dall’Università di Stanford e ripreso poi da varie scuole e società tra cui la famosissima IDEO.
Pur essendo partito dagli studi di design, il Design Thinking sta prendendo piede negli ultimi anni nella consulenza direzionale, nella trasformazione digitale e nella progettazione software.

Il Design Thinking è la progettazione incentrata sull’uomo (human-centered design); incoraggia coloro che progettano a concentrarsi sulle persone per le quali stanno creando (ricordate le personas?), il che porta a prodotti, servizi e processi interni migliori.
Invita a cercare soluzioni innovative (solo) dopo aver individuato l’esigenza umana sottostante (non è questo un mantra per un Product Owner?).

Questa è la risposta del Design Thinking alla domanda su come creare prodotti innovativi.
Tutti i prodotti di successo hanno in comune tre dimensioni: la dimensione relativa alle persone, la dimensione tecnica e il lato business.

Le tre sfide per l’innovazione

Perché un’innovazione si possa dire veramente tale tutti e 3 questi aspetti devono coesistere.

“Impiegando il Design Thinking stai mettendo insieme ciò che è desiderabile da un punto di vista umano con ciò che è tecnologicamente fattibile ed economicamente sostenibile.”

Desiderabilità

Tutto ha inizio con l’idea che ci sia un problema là fuori che le persone hanno e che sarebbero disposte eventualmente a pagare per trovare una soluzione.
Nell’area delle persone dobbiamo essere ragionevolmente sicuri che la soluzione – ovvero il prodotto o il servizio che andiamo a proporre – sia desiderabile.
Le persone devono essere consapevoli di avere quel particolare bisogno.
A volte può capitare che ci voglia un po’ di lavoro prima che possano effettivamente riconoscerlo ma senza una vera necessità la soluzione che proponiamo è destinata a fallire: le persone non la compreranno.

Fattibilità

La seconda dimensione è la dimensione è di natura tecnica.
Dobbiamo essere in grado di risolvere questo problema in un modo tecnicamente fattibile.
In alcuni casi le soluzioni tecniche proposte possono risultare veramente molto difficili da implementare, possono richiedere risorse che non si hanno a disposizione o tecnologie che non sono ancora “pronte” per il mass market.
In questo caso il prodotto o servizio che proponiamo risolverebbe un bisogno riconosciuto dai nostri utenti, ma risulta tecnicamente irrealizzabile.

Sostenibilità

E ora la terza dimensione: il business.
Ammesso di avere davvero indirizzato uno o più bisogni e di avere trovato una soluzione tecnicamente fattibile, quello che proponiamo è anche sostenibile dal punto di vista della redditività? E’ in grado di generare ricavi?
Se non produce entrate sufficienti per pagare i costi, non saremo in grado di sostenere il prodotto per molto tempo (e perché dovremmo farlo poi?).
Il prodotto innovativo per essere tale deve anche realizzare un profitto per ripagare tutto l’investimento fatto. Va di pari passo con un modello di business (innovativo o meno).

Queste tre dimensioni insieme ci danno innovazione.
Se ne indirizziamo solo una o due, generalmente non possiamo avere un’innovazione di successo. D’altra parte non è necessario che tutte e 3 le dimensioni siano risolte immediatamente in una volta; l’importante è che al termine del processo siano tutte e 3 presenti.

Ad esempio è comune che durante l’attività di Design Thinking si parta da uno di questi aspetti. Potresti partire dalla dimensione delle persone o da un innovativo modello di business rispetto al quale sei abbastanza confidente di poterlo fare funzionare; parti da lì e poi alla fine risolvi le altre dimensioni.
Al contrario un ingegnere potrebbe partire dalla dimensione tecnica. Anche questa modalità può funzionare a patto però di rendersi conto che se la soluzione proposta non risolve una reale esigenza del cliente, se non c’è alcun desiderio da parte del mercato, il prodotto non avrà successo.
Inutile dire che se non c’è un business allora neanche il resto può funzionare a dovere…

Quando è utile il Design Thinking

L’abbiamo già detto: il Design Thinking è progettazione incentrata sull’uomo.
Questa affermazione porta con sé un corollario: se il problema che state tentando di risolvere non è “umano”, questo approccio potrebbe non fare al caso vostro.
No, non mi riferisco agli alieni… semplicemente al fatto che in molti casi come persone di prodotto ci troviamo a dover indirizzare progetti che nascono semplicemente da esigenze aziendali. Se stiamo cercando di risolvere un problema di redditività di un’azienda non correlato in alcun modo a un vero bisogno delle persone – sperabilmente i nostri utenti – il Design Thinking non è il framework che fa per noi, dovremo considerare altri tipi di risorse.

Spero a questo punto di avervi dato un’idea di massima di cos’è il Design Thinking.
In ogni caso continuerò a elaborare il tema in approfondimenti successivi. Comunque se volete avere un’idea più precisa del processo vero e proprio vi suggerisco la visione di questo video; è un po’ datato ma sempre valido.


Racconta il processo di Design Thinking in pratica applicato ad un progetto teorico (ma assolutamente realistico). Se lo guarderete sino alla fine vi stupirà vedere come innovazioni progettate nel ‘99 siano diventate oggi oggetti del nostro uso comune. Buona visione!

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: