Usabile ma inutile: perché a tutte le aziende serve la product discovery

L’aumento dei prodotti usabili ma inutili#section1

Da tempo abbiamo accettato che per far sì che un prodotto sia utile, deve avere un livello accettabile sia di utilità (“se fornisce le feature di cui si ha bisogno”) e di usabilità (&8220;quanto siano semplici e piacevoli da utilizzare queste feature”). Tuttavia, molto spesso, sembra che ignoriamo la prima in favore della seconda, finendo con centinaia di applicazioni semplici e piacevoli che non hanno alcuna ragione di esistere. Si potrebbe sostenere che la prima versione di Color cadeva in questa trappola e quando è stata l’ultima volta che abbiamo sentito qualcosa su Path?

Uno dei maggiori problemi in cui si imbattono in particolare i nuovi prodotti è la mancanza di “product/market fit”, come ha notato Marc Andreessen:

La qualità di un prodotto di una startup può essere definita nel modo in cui il prodotto impressiona un cliente o un utente che lo usa davvero: quanto è facile usare questo prodotto? Quante feature ha? Quanto è veloce? È estendibile? Quanto è raffinato? Quanti bug ha? La dimensione del mercato di una startup è il numero e il tasso di crescita di quei clienti o utenti per quel prodotto…

La sola cosa importante è arrivare al “product/market fit”. “Product/market fit” significa essere in un buon mercato con un prodotto che possa soddisfare quel mercato.

Il problema si solleva quando le startup e le compagnie non passano abbastanza tempo ad aumentare la probabilità di un buon product/market fit prima di cominciare la progettazione e lo sviluppo. Il concetto di Lean Startup di “Minimum Viable Product” è certamente utile, ma non sarebbe meglio concentrarci sui Minimum Desirable Products? Qual è lo scopo delle iterazioni rapide se tutto quello che otteniamo è il massimo locale in maniera più rapida?

Ma prima di anticipare e discutere come sistemare questo problema, buttiamoci sulle domande importanti, sui “perché”.

Perché i prodotti non vanno bene#section2

Il più grande problema di Brasilia è che gli architetti che l’hanno progettata non hanno considerato il modo in cui la città avrebbe potuto essere usata una volta che milioni di persone ci avessero abitato. Hanno mostrato una certa Miopia Architetturale, ossia hanno progettato ad uso e consumo del proprio settore ma non per le persone. Già in precedenza ho scritto di un fenomeno simile nel nostro settore, la Miopia del Designer. Attirati dai riconoscimenti (e dai clienti e dai dirigenti) che si meritano, i designer sono attirati dall’apparire in gallerie e blog post che fanno elenchi volti ad attirare molto traffico.

Non c’è niente di assolutamente sbagliato con questo bisogno di riconoscimenti ma diventa un problema quando danneggia gli utenti. Se Brasilia ci può insegnare qualcosa, è che diventare sordi ai bisogni degli utenti ci porta lungo un pericoloso percorso discendente, in cui perdiamo il controllo dei nostri prodotti, senza modo di tornare indietro. Una volta che rilasciamo qualcosa, si può solo iterare o fare pivoting. L’iterazione va benissimo se siete sulla strada giusta, mentre il fare pivoting è pericoloso perché può cambiare il corso e devastare sia gli impiegati sia gli utenti.

Un modo migliore: la product discovery#section3

Se vogliamo disegnare dei prodotti migliori e più utili, dobbiamo smetterla di progettare delle soluzioni troppo presto e cominciare invece a fare product discovery, ossia operare secondo un processo che ci aiuti a comprendere in maniera corretta il problema, così che non si progetti in modo migliore ma si progettino cose migliori.

Il product discovery è costituito da tre step:

• Step 1. Inquadrare il problema e massimizzare l’opportunità
• Step 2. Esplorare e valutare diverse soluzioni
• Step 3. Dare delle priorità e pianificare

1. Inquadrare il problema e massimizzare l’opportunità#section4

È difficile litigare con Einstein:

Se avessi un’ora per risolvere un problema, passerei 55 minuti a pensare al problema e 5 minuti a pensare a possibili soluzioni.

Quei proverbiali 55 minuti costituiscono lo Step 1 della product discovery. Ecco, dovreste discutere e trovare delle risposte a domande come queste:

• Per chi stiamo risolvendo questo problema?
• Quali sono i bisogni degli utenti che stiamo cercando di gestire? Per i prodotti esistenti: quali sono i punti deboli da sistemare?
• Che dati abbiamo a nostra disposizione da parte dei clienti che possono esserci utili per la soluzione (supporto clienti, statistiche, ricerca di mercato, user research, analisi dei competitor, etc.)?
• In che modo risolvere questo problema ci aiuterà con i nostri affari?
• Perché il nostro business è in grado di fare di questa soluzione un successo?
• Come misureremo il nostro successo?

Ci sono svariate tecniche per strutturare la discussione e far sì che sia più facile trovare una risposta a tutte queste domande. I Fishbone Diagrams e The Five Whys sono due tecniche di analisi che possono essere applicate in maniera molto efficace per definire un problema in termini di bisogni utente e di obiettivi di business.

Questa fase produce sempre – senza eccezione – dei dati che il team trova incredibilmente utili. Le startup riescono ad avere le idee più chiare riguardo a cosa tenere e cosa eliminare nei propri prodotti e le grandi aziende imparano ad andare oltre le parole di moda della centralità dell’utente e a scoprire quali benefici dovrebbero dare ai propri utenti. Solo come esempio, una volta mi trovavo in un workshop in cui apparve chiaro che i dirigenti avevano una visione completamente differente dell’azienda rispetto ai designer e agli sviluppatori. Furono due ore strane, ma alla fine furono d’accordo sulla difficile ma corretta decisione di sospendere i loro piani di e-commerce fino a che alcune aree di contenuto del sito non fossero state riordinate. È bello vedere una dichiarazione di obiettivi emergere da queste sessioni, una che alla fine fa sì che l’organizzazione sia d’accordo su cosa debba concentrarsi l’attenzione della produzione.

Da questo step, io produco un diagramma problem-frame, che non è altro che un riassunto visivo dei punti principali da tenere a mente, sotto forma di tre cerchi che si sovrappongono:

• I bisogni degli utenti
• Gli obiettivi di business
• Le competenze principali

Ogni decisione che il team prende dovrebbe apparire almeno in uno di questi tre cerchi, preferibilmente nell’area di sovrapposizione di tutti e tre. Le decisioni di design dovrebbero concentrarsi sulla soddisfazione di quei bisogni e sul trarre profitto dalle opportunità di business utilizzando le competenze principali individuate.

Le customer journey map sono un altro utile output e il punto di vista di Megan Grocki e Jamie Thomson su di esse è molto utile: le journey map sono delle rappresentazioni visive che aiutano a riassumere i risultati delle ricerche, a sottolineare e a dare priorità alle opportunità e ad ottenere lavori.[1]

Una volta che si è definito il problema (e si è raggiunto l’accordo da parte di tutti gli stakeholder), è ora di cominciare a pensare alle soluzioni.

2. Esplorare e valutare diverse soluzioni#section5

I risultati del problem-framing ci conducono a una fase di pensiero divergente, un momento in cui si producono svariate soluzioni possibili, il più velocemente possibile e in maniera visuale. Tirate fuori le matite e molta, molta carta.

Piuttosto che aprire il portatile troppo presto nel processo di design, usate degli schizzi per produrre una varietà di soluzioni in un breve lasso di tempo. Semplicemente, a volte “Sposta nel cestino” non è l’azione adeguata quando dovete eliminare un’idea che vorreste non aver mai avuto: non c’è niente che dà più soddisfazioni di accartocciare una cattiva idea e di buttarsela dietro alle spalle con disgusto.

In questa fase del processo, si lavora insieme per tirare fuori degli storyboard, degli schizzi e dei prototipi a bassa fedeltà che aiutino a visualizzare le idee. È anche un ottimo momento per iniziare ad avere un feedback dai potenziali clienti e sì, diciamolo insieme: chiunque è in grado di disegnare. Se lo dice Dan Roam chi siete voi per non essere d’accordo?

3. Dare delle priorità e pianificare#section6

Parlo con molti team che si lamentano della “paralisi da analisi”, ossia dell’incapacità di prendere decisioni perché ci sono così tanti fattori (e persone) coinvolti. Dei buoni metodi di assegnazione della priorità danno ai team il comfort che anche se non si stanno concentrando su tutto insieme, si stanno concentrando sull’informazione giusta per prendere buone decisioni.

Potete fare ciò con una fase di pensiero convergente, che seleziona quali idee e soluzioni esplorare in maniera più approfondita. Ci sono molti processi prestabiliti per questo tipo di assegnazione della priorità, ciascuno progettato per uno scenario diverso:

1. Con il KJ-Method, si raggruppano delle questioni simili e si usa un meccanismo di voto per classificarle in ordine di importanza. È meglio quando si ha un nutrito gruppo di stakeholder che hanno tutti delle opinioni forti riguardanti il prodotto e volete prendere una decisione rapidamente.
2. Il Kano Model utilizza un asse a due dimensioni per raggruppare le questioni in una di queste tre categorie: aspettative di base (feature che gli utenti si aspettano), generatori di entusiasmo (bellissime e inattese feature) e performance payoff (feature che necessitano di miglioramenti continui per far aumentare la soddisfazione dell’utente). Questo metodo funziona quando volete essere sicuri di avere una roadmap equilibrata che gestisca le richieste di base, così come le feature innovative che potrebbero aiutare il prodotto a superare quelli dei competitor.
3. L’approccio di Amazon dà la priorità prima ai temi grossi, prima ancora di entrare nelle singole feature o progetti per gestire questi temi. È un buon approccio quando il solo numero di feature o miglioramenti richiesti sembra opprimente e avete bisogno di un modo per strutturarli e dargli un senso.

Questi metodi funzionano perché facilitano il lavoro di squadra senza cadere nelle trappole del “design by committee”. Tutti possono dire la loro ma non tutti possono prendere le decisioni. Questo è un attributo essenziale di qualunque buon metodo di assegnazione delle priorità, poiché, come dice Seth Godin, “Non succede alcunché quando tutti devono essere d’accordo.”

Oltre a fornire la struttura necessaria per giungere rapidamente alla decisione di come assegnare le priorità, questi metodi producono anche degli artifatti tangibili che possono aiutarvi a vendere le vostre idee agli stakeholder interni. La user experience spesso è più un problema organizzativo che non di design. Così come vogliamo solo fare il nostro lavoro senza ostacoli, possiamo anche essere davvero efficaci se riusciamo a fornire argomenti persuasivi alle persone negli altri settori della nostra azienda. Questi metodi di assegnazione strutturata della priorità rendono questo step ragionevolmente indolore aiutandovi a produrre dei record scritti e visivi del vostro processo di elaborazione delle vostre idee.

Una volta fatto, dovreste essere in grado di scremare le idee, per poter scegliere quelle poche che volete implementare e testare e, statene certi, quelle idee avranno le migliori chance di soddisfare i bisogni dei vostri utenti e gli obiettivi di business.

L’output#section7

Gli artefatti prodotti durande la product discovery dipendono dalla portata e dalla natura del progetto. A volte, sono pochi schizzi sul retro di un tovagliolo che vengono usati da uno sviluppatore per iniziare a prototipare, altre volte sono costituiti da un documento PowerPoint che riassume il processo e i risulati nello sforzo di coinvolgere i dirigenti senior.

Indipendentemente dall’output fisico, alla fine del processo dovreste essere in grado di rispondere con facilità alle seguenti domande:

• Qual è il problema che stiamo cercando di risolvere?
• Per chi lo stiamo risolvendo? Perché dovrebbe importargliene?
• Qual è la visione della soluzione?
• Quali sue parti sono per noi?
• Qual è il nostro piano per la sua implementazione?

Il vero potere di questo processo è che darà al vostro team la tranquillità di aver già introdotto sufficiente variazione in un processo di design da essere sicuri che non state scalando la montagna sbagliata al massimo locale.

Va bene per voi#section8

Vi sento esclamare “Carino, ma noi siamo una startup che si muove volocemente e non abbiamo tempo per sederci e parlare”

Ce l’avete se l’alternativa è il fallimento, portato dalla dipendenza poco salutare alle cose graziose che portano a 15 minuti di gloria e poco altro.

Stiamo entrando in un’interessante era del web design. I display retina potrebbero non essere ancora stati adottati in massa, ma è solo questione di tempo prima che diventino la norma. Stiamo inoltre assistendo ad un interesse verso la tipografia e la grafica paragonabile solo a quando apparvero i monitor CRT. Ci sono molti oggetti scintillanti e se ci concentriamo su quelli (o ci concentriamo solo sull’impressionare i Vice-Presidenti che si concentrano su quelli) a scapito dell’utilità, potremmo trovarci in una situazione simile a quella di qualche anno fa, quando creavamo le introduzioni Flash su tutti i siti solo perché potevamo.

In altre parole, la product discovery è essenziale per le startup proprio perché siamo in un periodo di innovazioni visive entusiasmanti.

Non possiamo permetterci che il fascino delle immagini ci distolga dall’utilità dei prodotti che stiamo sviluppando. È vero che il fallimento ci insegna molto su quello che funziona e quello che non funziona, ma è molto più economico ed efficace fallire solo con delle idee sulla carta rispetto che fallire con un’idea completamente sviluppata. Come probabilmente testimonia Color, a quel punto è difficile tornare indietro.

Insieme, possiamo evitare di creare tante Brasilia digitali, che generano euforia ma che non soddisfano i bisogni dei propri abitanti. Quindi, scopriamo prima di costruire.

Riferimenti#section9

[1] Se non conoscete il journey mapping, leggete The Anatomy of an Experience Map, Using Customer Journey Maps to Improve Customer Experience e Building a Vision from a Journey Map.

Illustrazioni: {carlok}