Discovery economica

Se aprite un qualunque manuale di design, vedrete lo schema del ciclo di design: scoprire, inventare, creare, valutare e ripetere. Ogni volta che abbiamo un nuovo cliente o cominciamo a lavorare a una nuova feature, cominciamo dall’alto del cerchio con la scoperta (o discovery). È il momento del progetto in cui definiamo il problema che stiamo cercando di risolvere e quale sarà il nostro primo approccio per la sua risoluzione.

Solitamente, in un’azienda strutturata parliamo della discovery all’inizio di un ciclo di sprint, dove ci sono cose come i budget, i product team e i clienti esistenti. Il processo di discovery potrebbe includere delle interviste agli stakeholder o il riversamento di dati esistenti sugli utenti. E usciamo sempre dalla fase di discovery con una qualche idea su come procedere.

Tuttavia, la discovery è intrinsecamente diversa quando lavorate in una no profit, in una startup o in un’azienda agli inizi. Potrebbe esserci un team di design composto da una sola persona (voi), con zero dollari da spendere ed esserci solo poche persone che sanno dell’esistenza dell’azienda. Non ci sono clienti da intervistare e zero dati da esaminare. Questo potrebbe anche essere il caso di grandi aziende quando vogliono testare le acque per una nuova direzione senza impegnarsi troppo (o spendere troppo). Ogni volta che avete dei vincoli di budget, dati e stakeholder, dovete essere flessibili e astuti nel modo in cui condurrete la discovery research. Ma non potete risparmiare sul rigore e sull’accuratezza. Se l’idea con cui uscite dalla fase di discovery non è buona, il vostro grande lancio potrebbe diventare un flop che pone fine alla vostra azienda.

In questo articolo vi guiderò in un ciclo di discovery research, ma lo applicherò a una idea di startup (fittizia). Introdurrò delle strategie per condurre la discovery research senza budget, senza dati utente esistenti o risorse di cui discutere. E vi mostrerò in che modo, facendo progressi, la ricerca dia forma al business.

Scrivete l’ipotesi del problema#section1

Una tremenda quantità di inchiostro (reale o virtuale) è stata versata proclamando che tutti dovremmo “innamorarci del problema non della soluzione”. Ed è stato inchiostro ben speso. Quando si arriva al product building, una filosofia incentrata sul problema è la pietra d’angolo di qualunque azienda user centric.

Ma in che modo, esattamente, sapete quando avete tra le mani un problema che valga la pena risolvere? Se lavorate in un’azienda grande e stabile, potreste avere del feedback dagli utenti e dei dati che vi indicano la via come frecce luminose su una strada ben segnalata verso un problema che vale la pena risolvere. Tuttavia, se state lanciando una startup o lavorando a un’azienda più grande che si sta avventurando in un nuovo territorio, può essere più simile a fare un’escursione nei boschi e cercare il successivo segno che indichi la pista. Le vostre idee probabilmente si basano su esperienze personali e istinto.

Quando le vostre idee si basano sulle esperienze personali, sulle supposizioni e sull’istinto, è importante realizzare che hanno bisogno di un livello di ispezioni superiore alla media. Dovete valutare la domanda “Ho un problema che vale la pena risolvere?” con un livello più alto di rigore rispetto a quello che avreste in un’azienda con un budget da investire e una quantità di dati esistenti. Dovete prendere tutte le vostre idee e supposizioni ed esaminarle accuratamente. E il modo migliore per esaminare le vostre idee e categorizzare le supposizioni è con le ipotesi.

Come descrive il dizionario, un’ipotesi è “una supposizione o una spiegazione proposta fatta sulla base di prove limitate come punto di partenza per ulteriori indagini”. Questa serve inoltre come una buona descrizione del perché innanzitutto facciamo discovery research. Potremmo avere un’idea in merito a un problema che vale la pena risolvere ma non ne conosciamo ancora la portata o i dettagli critici. Articolare i nostri istinti, idee e supposizioni come ipotesi di un problema getta le fondamenta per l’avanzamento della ricerca.

Ecco una formula generale che potete usare per scrivere l’ipotesi di un problema:

Per questo articolo, ho deciso di “lanciare” una startup fittizia (e oltremodo ambiziosa) come esempio. Ecco l’ipotesi del problema che ho scritto per la mia startup:

In questo esempio, potete vedere che le mie supposizioni sono:

• gli utenti intuiscono che i siti di social media come Facebook causano dipendenza;
• agli utenti non piace essere dipendenti dai social media;
• gli utenti sono disposti a pagare per un sostituto di Facebook che non dia dipendenza.

Queste sono le supposizioni su cui farò ricerche e che testerò durante il processo di discovery. Se attraverso la mia ricerca scoprirò che non posso subito confermare queste supposizioni, significa che non sarò ancora pronta per sfidare Mr. Zuckerberg.

I vantaggi di articolare le proprie supposizioni in forma di ipotesi è che abbiamo qualcosa di concreto su cui discutere, a cui far riferimento e da testare. Si può coinvolgere l’intero product team nella stesura dell’ipotesi iniziale del problema e potete farvi di nuovo riferimento durante il processo di discovery. Una volta che abbiamo completato la ricerca e analizzato i risultati, possiamo modificare l’ipotesi perché rifletta le nuove idee suoi nostri utenti e i problemi che vogliamo risolvere.

Adesso che abbiamo articolato un’ipotesi di problema, è ora di capire il nostro piano di ricerca. Nelle due sezioni seguenti, esaminerò il metodo di ricerca che raccomando di più per le nuove imprese, così come le strategie per reclutare i partecipanti con un budget ristretto.

Un metodo che è utile in tutte le fasi del design: le interviste#section2

Nella mia carriera di user researcher, ho usato tutti i tipi di metodi. Ho fatto test A/B, eye tracking, test Mago di Oz, think aloud, contextual inquiry e guerrilla testing. Ma il metodo di ricerca che utilizzo di più, e che credo fornisca il maggior valore per dollaro speso, sono le user interview.

Le user interview sono relativamente economiche. Non dovete andare da un cliente e non vi serve un equipaggiamento che costi una fortuna. Se avete accesso a un telefono, potete fare un’intervista con partecipanti in tutte le parti del mondo. Inoltre, le interviste forniscono una serie di informazioni e possono essere usate in ogni fase della ricerca e del design. Le interviste sono specialmente utili nella discovery, perché si tratta di un metodo flessibile. Man mano che imparate di più riguardo al problema che state cercando di risolvere, potrete adattare il vostro protocollo di intervista perché vi si adegui.

Per essere chiari, le persone che intervisterete non vi diranno:

• cosa creare,
• o come crearlo.

Ma vi potranno assolutamente dire:

• che problema hanno,
• come li fa sentire,
• e che significato avrebbe per loro una soluzione.

E se conoscete il problema, come fa sentire gli utenti e il valore di una soluzione, siete a buon punto nel percorso di progettazione del prodotto giusto.

La sfida posta dal condurre una buona user interview consiste nell’assicurarsi di fare le domande giuste che vi permettano di ottenere tali informazioni. Ecco un paio di suggerimenti.

Suggerimento 1: fate sempre le seguenti due domande:

• “Cosa ti piace di [in bianco]?”
• “Cosa non ti piace di [in bianco]?”

… In cui sostituirete “[in bianco]” con qualsiasi dominio che sarà migliorato dal vostro prodotto futuro.

Il vostro obiettivo è di ottenere una comprensione di tutti gli aspetti del problema che affrontano i vostri potenziali clienti: quelli cattivi e quelli buoni. Un errore comune consiste nel passare troppo tempo investigando quello che non funziona nello stato attuale delle cose. Naturalmente, volete che il vostro prodotto sistemi tutti i problemi incontrati dai vostri clienti. Ma, dovete anche preservare quello che funziona bene adesso, quello che soddisfa o quello che diversamente funziona bene nel modo in cui gli utenti attualmente raggiungono i propri obiettivi. È quindi importante porre entrambe queste domande nelle user interview.

Per esempio, nelle mie interviste ho sempre chiesto “Cosa ti piace dell’uso di Facebook?” Ed è solo quando un partecipante all’intervista mi ha detto tutto quello che gli piace di Facebook che chiedo “Cosa non ti piace dell’utilizzo di Facebook?”

Suggerimento 2: dopo (quasi) ogni risposta, chiedo loro di dirmi di più.

L’obiettivo del fare interviste è ottenere un insieme di dati esaustivi da rivedere e tenere in considerazione man mano che si procede. Questo significa che non volete che i partecipanti discutano una cosa che gli piace o che non gli piace, ma volete che vi dicano tutte le cose che gli piacciono e tutte quelle che non gli piacciono.

Ecco un esempio di come funziona in una delle interviste che ho fatto.

Da questo esempio si capisce come la prima feature che viene in mente all’intervistato è la possibilità di tenersi in contatto con amici con cui altrimenti avrebbe scarse opportunità di connessione. Questa è una feature che qualunque sostituto di Facebook dovrebbe replicare. Tuttavia, se non avessi spinto l’intervistato a pensare ancora di più a delle feature che gli piacciono, potrei non aver mai scoperto un’importante feature secondaria: un sistema di messaggistica in-app comodo. In effetti, sei persone su undici intervistate per questo progetto mi hanno detto di apprezzare Facebook Messenger. Ma nessuno di loro ha menzionato tale feature per prima. È saltata fuori nella conversazione solo dopo che ho indagato ulteriormente.

Continuando a ripetere la mia domanda, l’intervistato ha pensato a un’altra feature che apprezza: l’elenco degli eventi locali. (Questa feature è stata citata da cinque persone su undici intervistate). Ma dopo questo, l’intervistato non ha trovato altre feature da discutere. Sapete di poter passare alla domanda successiva nell’intervista quando il vostro partecipante comincia a ripetersi o vi dice francamente che non ha null’altro da dire.

Reclutate tutto intorno a voi, poi documentate i bias#section3

Ci sono moltissimi modi per reclutare partecipanti per la ricerca. Potete assumere un’agenzia o usare un tool come UserTesting.com. Ma molte di queste opzioni a pagamento possono essere piuttosto costose e, dal momento che stiamo lavorando con un budget risicato, abbiamo più o meno zero dollari da spendere nel reclutamento. Dobbiamo essere creativi.

Per il mio progetto, ho deciso di fare affidamento sulla gentilezza di amici e sconosciuti che potevo raggiungere attraverso Facebook. Ho postato una richiesta per trovare partecipanti sulla mia pagina Facebook personale e un’altra sulla pagina del FreeCodeCamp locale. Un giorno dopo aver postato la mia richiesta, venticinque amici e cinque sconosciuti si sono offerti volontari. Questo tipo di metodo di reclutamento partecipanti è chiamato convenience sampling, perché stavo reclutando partecipanti a cui avevo accesso in modo pratico.

Dal momento che il mio progetto implicava il parlare alle persone dei siti di social media come Facebook, era appropriato che il mio primo tentativo di reclutamento partisse da Facebook. Potevo essere sicura che tutti quelli che avrebbero visto la mia richiesta usassero Facebook in qualche modo. Tuttavia, come tutti i convenience sampling, il mio metodo di reclutamento aveva dei bias (che spiegherò tra poco).

Il bias è qualcosa che dovremmo cercare di evitare ogni volta che è possibile. Se abbiamo accesso a metodi di reclutamento più sofisticati, dovremmo usarli. Tuttavia, quando si ha un budget ristretto, evitare il recruitment bias è virtualmente impossibile. In questo scenario, i nostri obiettivi dovrebbero essere di:

• mitigare i bias al meglio delle possibilità
• e documentare tutti i bias che vediamo.

Per il mio progetto, ho potuto mitigare alcuni bias usando altri metodi di reclutamento. Sono andata in vari quartieri e ho cercato di reclutare partecipanti dalla strada (i.e., guerrilla testing). Se avessi avuto un po’ di soldi da spendere, avrei potuto passare del tempo in vari coffee shop e offrire un caffè alla gente in cambio di un’intervista di dieci minuti. Anche questi metodi di reclutamento ricadono sotto il termine ombrello di convenience sampling, ma usando vari metodi posso mitigare alcuni bias che avrei usandone solo uno.

Inoltre, è sempre importante riflettere su e documentare come i propri metodi di sampling abbiano dei bias. Per il mio progetto, ho scritto le note seguenti:

Tutte le persone intervistate erano connesse a me su Facebook in qualche modo. Conosco bene molte di loro, siamo “amici”. Tutti hanno più o meno la mia età, molti (ma non tutti) lavorano nel settore tech in qualche modo e tutti, tranne uno, vivono negli USA.

Documentare i bias assicura che non ce ne dimenticheremo quando sarà ora di analizzare e discutere i risultati.

Continuiamo così#section4

Come suggerisce il titolo, questa è solo la prima parte di una serie di articoli riguardanti il processo di discovery. Nella seconda parte, analizzerò i risultati delle mie interviste, rivedrò le ipotesi del mio problema e continuerò a lavorare sulla mia startup sperimentale. Mi butterò in un altro giro di discovery research, ma questa volta utilizzerò dei metodi di ricerca differenti, come i test A/B e fake door. Potete aiutarmi controllando questo mockup della landing page per Candor Network (come ho chiamato la mia startup fittizia) e compilando il questionario che troverete là.