Cos’è la User Research?

Ascolta su Apple Podcasts oppure su Spotify.

Sergio Panagia: Benvenuti al podcast di Moze, uno spazio di dialogo e approfondimento tecnico sullo sviluppo di nuovi prodotti digitali. Io sono Sergio, partner dello studio, e con me oggi c’è Paolo, designer di Moze. Ciao Paolo.

Paolo Tripodi: Ciao Sergio e ciao a tutti!

Sergio: Quando avviamo un nuovo progetto di sviluppo spesso ci gettiamo subito a disegnare o a programmare. Ma prima cosa viene? Oggi assieme a Paolo parliamo di ricerca, ovvero l’insieme delle attività preliminari all’esecuzione di un nuovo progetto. Paolo, cosa vuol dire fare ricerca nel contesto di un prodotto digitale?

Paolo: Ottima domanda, Sergio, grazie di avermela fatta! Allora intanto dico che come possiamo immaginare non esiste una singola risposta esaustiva, sarebbe bello ma mi sembra difficile, così come non esiste un solo modo di fare ricerca.
D’altra parte, come spesso ci capita, è possibile che sia proprio un cliente a farci questa domanda magari a bruciapelo, parlando così informalmente di un progetto e in quel caso a quel cliente direi “fare ricerca, in breve, vuol dire mettere alla prova le tue idee prima di sviluppare il tuo prodotto digitale non perchè è bello, non perchè è di moda, ma soprattutto il motivo principale è per risparmiare potenzialmente tanti soldi”.

Sergio: Sì infatti spesso, dalla nostra esperienza sul campo, le aziende si concentrano come prima cosa sulla nuova soluzione o la funzionalità da realizzare, tralasciando o trascurando un po’ l’analisi del problema da risolvere. Come mai secondo te?

Paolo: Purtroppo non posso che essere d’accordo con la tua premessa. Mi vengono in mente tante cose. Allora, per fare un esempio stupidissimo, nessuno prenoterebbe una cena costosa con dei vecchi amici senza prima averli contattati per sapere se sono disponibili, no?
Strano ma vero, questo non è sempre il caso quando si tratta di un prodotto digitale; per rimanere nel nostro esempio, spesso invece vengono “prenotati più ristoranti”, magari già con l’ordine dei posti a sedere per ogni tavolo.

Sergio: Ahahah, ottimo esempio!

Paolo: Un esempio tipico in questo senso è quello di un progetto nuovo, può trattarsi di una start-up, di un nuovo progetto di innovazione di una grande azienda…
Allora dico rispetto a questo, prima di tutto mi sembra evidente che un nuovo progetto nasce necessariamente da un’opinione, anche forte magari, sui problemi di un certo mercato o su una certa visione di prodotto.
Detto questo, bilanciare le proprie idee, il proprio punto di vista con quello dei clienti o delle persone per cui realizzo il mio prodotto rimane essenziale. Appunto non per moda o per altri motivi futili, ma soprattutto perché non farlo può essere prima di tutto molto costoso e poi anche snervante nel lungo periodo.

Sergio: Sì, è vero. In effetti molti dei nostri clienti, aziende o start-up, bussano alla nostra porta avendo un prodotto promettente, ma dei problemi di progettazione fatti all’inizio impattano l’esperienza utente impedendo la crescita del prodotto e dell’azienda e arrivano da noi dicendo “Sì, ok, queste cose le abbiamo dovute fare di fretta, ma ora ri-pensiamoci bene dall’inizio”. Come può, secondo te Paolo, la ricerca aiutare a invertire la rotta?

Paolo: Ottima domanda. Allora, fondamentalmente io inizierei dicendo che esistono due tipologie di ricerca di cui possiamo avvalerci: una è quella a cui generalmente guardano tutti, che sono i dati: dati di traffico, conversioni di una pagina, eccetera.
Qui apro una parentesi tra l’altro dicendo che tutti guardano ai dati, ma poi guardarli bene non è affatto banale e come abbiamo potuto spesso osservare, ci riescono in pochissimi; quindi anche questo non è un punto banale.
L’altro metodo di ricerca sono le interviste, ovvero la cosiddetta ricerca qualitativa, aka per gli amici parlare con i miei clienti per comprendere i loro bisogni.
Questo spesso, intanto è il metodo meno utilizzato purtroppo ci capita di vedere, e che in realtà dovrebbe essere sempre il primo quando si inizia un nuovo progetto; inoltre apro una parentesi dicendo che poi è questo il metodo che le grandi aziende tecnologiche usano praticamente da sempre, insieme ai dati poi, per fare il risultato. Queste sono un po’ di considerazioni che mi vengono in mente.
La buona notizia però, volendo dare una buona notizia, è che non serve essere degli scienziati per fare, iniziare a fare ricerca, e apprendere gli strumenti come è anche stato nel nostro caso è assolutamente fattibile appunto anche per chi non lo ha mai fatto.
E la cosa bella rispetto a questo è che poi con molti nostri clienti ci siamo riusciti.
È bello quando questo accade ed è bello soprattutto poi a distanza di tempo ricevere i ringraziamenti per questo; questo è secondo me una delle cose più belle in questo senso.

Sergio: Sì, in diversi casi nella nostra esperienza con i nostri clienti siamo riusciti, grazie a dei test e delle interviste, ad aggiustare il tiro su una nuova idea di prodotto oppure ad affinare quelle che erano le caratteristiche inizialmente pensate per delle nuove funzionalità, e questo in effetti fa risparmiare tempo che altrimenti andrebbe investito in lunghi cicli di sviluppo, prima di qualsiasi confronto reale poi con l’utente.
Paolo, da un’analisi dei problemi, un approfondimento con gli utenti, come si passa poi alla definizione della soluzione e alla sua implementazione?

Paolo: Ottima domanda anche questa! Allora, per capire davvero quali sono i reali problemi dei nostri utenti proprio la prima cosa da fare direi è sicuramente fare una bella chiacchierata con un utente o potenziale tale, quindi questo è il primo passo che io farei.
Rispetto a questo, l’unica attenzione aggiungo, è che con lui non dobbiamo fare più di tanto una “conversazione”, magari cercando di convincerlo di quello che pensiamo, ma al contrario il genere di conversazione che dobbiamo fare è ascoltare il nostro utente/cliente il più possibile, magari anche mostrandogli un prototipo della nostra app se ce l’abbiamo, per cercare di capire i suoi problemi così come sono prima che lui incontri la nostra soluzione, in sostanza.
Una volta che abbiamo fatto 4 o 5 di queste chiacchierate, ascoltando bene ciò che ci viene raccontato, emerge in modo quasi naturale, quasi intuitivo, quali sono le cose da fare per cambiare la nostra soluzione.
Faccio un esempio concreto, per dire: “la dashboard (ecco, per dire) deve per forza mostrarmi questo e quest’altro parametro”, e quindi noi lo includiamo nel prototipo appunto forti delle nostre convinzioni e poi magari capita che 5 intervistati su 3 non hanno ben chiaro che cosa stanno guardando, quindi che dato stanno guardando e magari altri due fanno la stessa cosa in excel; ecco e qui poi si sconvolgono insomma quelle famose convinzioni che appunto vale la pena mettere alla prova.
A livello più operativo, mi viene in mente anche che, per essere efficaci nel fare queste conversazioni, è molto importante separare bene quello chè è il momento dell’ascolto (cioè il momento in cui io mi siedo e ascolto i miei utenti) dal momento dell’analisi (che è invece quel momento in cui vado a trarre le conclusioni), questo per darmi la possibilità di affrontare queste due cose a mente fresca e in ognuno di questi due momenti, che sono consecutivi, andare bene dritti al punto!
Una volta che io ho fatto un’analisi di questo tipo, quindi una volta che ho chiare da queste conversazioni quali sono le azioni che io posso intraprendere, posso progettare nuovi concept di soluzione, posso appunto reiterare su quello che ho progettato e a loro volta sottoporre queste successive iterazioni a ulteriori test sempre con l’idea (di) appunto di ridurre quel divario tra ciò che noi pensiamo e poi ciò che è la reale esperienza dell’utente, ma soprattutto anche la reale comprensione dell’utente di ciò che ha di fronte.
E quindi da questo punto di vista la ricerca, se vogliamo, è più un processo incrementale che va a supportare lo sviluppo – piuttosto che un’attività a sé stante che termina appunto all’inizio una volta che inizio a sviluppare in sostanza.

Sergio: Per concludere, Paolo, c’è un libro o un’altra risorsa che consiglieresti ad un ascoltatore interessato ad approfondire il tema della ricerca nel digitale dopo questa nostra conversazione?

Paolo: Sicuramente sì, sicuramente così sui due piedi mi viene in mente, consiglierei di dare un’occhiata al libro Sprint di Jake Knapp. Questo per varie ragioni, prima di tutto questo libro è stato per noi il libro e la metodologia che ci ha iniziato a fare interviste, alla ricerca qualitativa e quindi questo è un primo punto. L’altro motivo è perché in questo libro c’è una sintesi molto efficace di come svolgere un’intervista con un altro essere umano, senza impazzire, ma soprattutto ottenendo il risultato desiderato (essere umano che poi spesso è appunto uno sconosciuto, quindi una persona con cui, da cui non sappiamo quale reazione aspettarci) e l’ultima cosa che mi viene in mente è perchè questa descrizione di come fare a intervistare un’altra persona è inserita nel processo del Design Sprint che è esso stesso un’ottima sintesi sia di quello che dovrebbe essere la ricerca all’interno dello sviluppo di un prodotto, e voglio dire appunto come abbiamo detto prima, non una cosa che io faccio all’inizio e basta, ma appunto parte integrante di ogni ciclo iterativo, ogni volta, magari non sempre, però almeno ogni volta che le incognite in gioco giustificano appunto il farsi qualche domanda.

Sergio: Va bene, grazie. Abbiamo capito quindi che la ricerca è un’attività ricorrente che dovrebbe essere programmata nel ciclo di sviluppo di un nuovo progetto. Grazie Paolo.
Siamo curiosi di sapere come altri effettuano attività di ricerca in progetti di sviluppo, quindi se siete interessati a condividere la vostra opinione o il vostro punto di vista, scriveteci sul sito mozestudio.com. Paolo ti ringrazio per il tuo contributo.

Paolo: Grazie Sergio e un saluto a tutti.