User Interviews – Raccogliere Dati e Scovare Problemi

User Interviews – Raccogliere Dati e Scovare Problemi

Introduzione

All’interno di Eye Studios, nell’ultimo periodo, ci stiamo concentrando sulla parte di Ricerca e Analisi nel flusso di UX Design, per riuscire a standardizzare un processo che possa essere scalabile replicabile.

Questo documento ha l’obiettivo di riunire diverse informazioni che stiamo raccogliendo e che crediamo possano essere utili a tutti coloro che vogliono approfondire l’argomento.

Non è un documento finito o una guida, ma una raccolta di informazioni utili che stiamo raccogliendo e che pensiamo possano essere condivise.

Questo farà parte di una serie di documenti, visita il profilo Linkedin di Eye Studios per essere aggiornato su tutti i documenti disponibili.

Capire quali dati raccogliere

Dati quantitativi

“I dati quantitativi servono a raccogliere i fatti nudi e crudi, le cifre. Si tratta di dati statistici e strutturati, che sono di supporto per trarre dalle ricerche conclusioni di carattere generale.”

it.surveymonkey.com › quantitative-vs-qualitative-research

Dati qualitativi

“I dati qualitativi raccolgono quelle informazioni che tentano di descrivere un argomento più che misurarlo: si tratta di impressioni, opinioni e punti di vista.”

it.surveymonkey.com › quantitative-vs-qualitative-research

	Ricerca Quantitativa	Ricerca Qualitativa
Domande	Quanti e quanto?	Perchè?
Obiettivi	• valutare l’usabilità di un sito esistente• traccia l’usabilità nel tempo• confronta il sito con i concorrenti• calcolare il ROI	• Prendere decisioni di design• identificare i problemi di usabilità e trovare soluzioni
Quando utilizzarla	Quando hai un prodotto funzionante (all’inizio o alla fine di un ciclo di progettazione)	In qualsiasi momento: durante la fase di design o anche quando si ha un prodotto finale funzionante
Risultato	Dati e statistiche significative che possono essere utilizzati per condurre altre analisi	Interpretazioni dei designer basate sulle impressioni e sul knowledge precedente
Metodologia	• Molti partecipanti• Approccio definito e preciso• Di solito non si “pensa ad alta voce”	• Pochi partecipanti• Approccio variabile in base alle esigenze del team• Di solito si “pensa ad alta voce”

Domande per conoscere l’utente

Che aspetto ha il tuo tipico giorno lavorativo?
Descrivi la tua giornata tipo in [ambiente-ruolo]?
Quando utilizzi normalmente Internet per la prima volta in una giornata tipo?
Quali sono alcune delle app e dei siti web che utilizzi di più?
Parlami del tuo ruolo nella tua azienda?
Qualsiasi domanda sullo stile di vita correlata al tuo argomento / prodotto
Parlami di te e del tuo rapporto con [nome prodotto, app, sito].
Parlami della tua relazione con l’ [argomento del progetto]?

Script di esempio

inspired by Evan Bowers – Zapier

Ciao {name}, come stai oggi?

Grazie mille per la disponibilità nell’aiutarci con questo, hai mai preso parte a uno studio sull’usabilità prima d’ora?

Ti darò solo una panoramica di quello che faremo oggi …

Ti mostrerò un prototipo di design in cui ti farò completare alcune attività e ti farò alcune domande lungo il percorso. La prima cosa che voglio chiarire è che non ti stiamo testando, stiamo testando il progetto, quindi non ci sono risposte sbagliate che puoi dare.

Il nostro obiettivo è quello di ottenere la tua prospettiva. Per avere la tua prospettiva, ti chiederò di provare a pensare ad alta voce il più possibile – di dire cosa stai guardando, cosa stai cercando di fare e cosa stai pensando – sarà di aiuto.

Se hai domande durante la sessione, chiedi pure – sappi solo che potrei non essere in grado di rispondere subito, poiché siamo interessati a come si comportano le persone quando non hanno una guida.

Un’ultima cosa prima di iniziare … ti dispiace se registro questa sessione aiuterà i miei compagni di squadra che non sono qui ed in modo da poterla rivedere

Domande per analizzare il comportamento, impressioni e aspettative degli utenti

Da Obiettivi a Test

Per riuscire a prioritizzare le domande e crearne di nuove, si può partire dalle funzionalità e dagli obiettivi presenti nel Product Backlog (o semplicemente quelli definiti dal Team)

Lo schema seguente rappresenta un esempio di come passare da un obiettivo ad un test chiaro e definito

Quali sono le attività più importanti che voi o altre persone dovete svolgere nell’utilizzo di [sito web o applicazione del progetto]?
Come descriveresti la tua esperienza passata e attuale con [argomento del progetto, sito web o applicazione]?
Con che frequenza usi o vedi usare [sito web o applicazione del progetto]?
Come si arriva normalmente a [sito web o applicazione del progetto]?
Quali dispositivi utilizzi in genere quando visiti [sito web o applicazione del progetto]?
Hai utilizzato in passato altri siti Web e risorse per lo stesso scopo di [sito Web o applicazione del progetto]?
C’è qualcosa che cerchi spesso su [sito web o applicazione del progetto] che manca o è difficile da trovare?
Esiste un modo in cui [il sito web o l’applicazione del progetto] non supporta le tue esigenze attualmente?
Se hai una domanda su [argomento del progetto] sai chi contattare?
Cosa stai pensando mentre guardi questo progetto?
Qual è la tua (prima) impressione di questo prodotto / caratteristica?
Cosa pensi che questo prodotto / features faccia o farà?
Da dove inizi?
Quando e dove pensi che qualcuno utilizzerebbe questo prodotto / funzionalità?
Cosa ti aspetti di guadagnare dall’utilizzo di questo prodotto?
Cosa ti impedirebbe di utilizzare questo prodotto?
Pensi che questo prodotto sia simile a un altro?
Ti fidi di questo prodotto?
Hai [“fatto questa azione”] quando hai [“visto/fatto qualcosa”], cosa ha causato questa reazione?

Domande durante e dopo l’utilizzo

Come faresti per eseguire [compito]?
Cosa ti aspetti che succeda se hai svolto questo [compito]?
Quale metodo alternativo useresti per eseguire [compito]?
C’era qualcosa di sorprendente o che non ha funzionato come previsto?
L’interfaccia era di facile comprensione?
Qual è stato il compito più semplice da svolgere?
Ed il più difficile da portare a termine?
Qual è la funzione principale di [argomento del progetto]?
Qual è la funzione principale del [sito web o applicazione del progetto]?
Cosa ti piace dell’attuale [sito web o applicazione del progetto]?
Cosa non ti piace dell’attuale [sito web o applicazione del progetto]?
Quanto tempo ti aspetti che richieda il [processo nel progetto]?
Ricordi la comunicazione o qualsiasi follow-up dopo aver eseguito il [processo nel progetto]?
In quali circostanze vorresti ricevere una notifica in [processo nel progetto]?
Come usi le informazioni sul [sito web del progetto o applicazione]?
Avresti mai bisogno di condividere queste metriche con altri?
1. Se sì, chi, con quale formato e metodo di condivisione?
Avresti mai bisogno di esportare [informazioni o risorsa nel progetto]?
1. Se sì, quando, perché e in che formato?
Perché pensi che qualcuno userebbe questo prodotto?
Come pensi che questo prodotto ti aiuterà?
Utilizzeresti questo prodotto oggi?
Cosa potrebbe impedire alle persone di utilizzare questo prodotto?
Qual è l’importo massimo che saresti disposto a pagare per questo prodotto?
Questo ti ricorda altri prodotti?

Organizzare i dati durante le interviste

Appunti, Note e Template

Per prendere appunti durante le sessioni abbiamo sperimentato diversi modelli utilizzati dalle grandi aziende tramite Google Sheet (template al fondo).

Il foglio per prendere note si compone di:

Obiettivo (la macro task che l’utente deve svolgere)
Emozione (cosa prova l’utente)
Tester (quale membro del team di UX conduce i test, nel caso in cui servisse un follow-up)
Note (singole note del tester).

➡️ Ecco il template Google sheets che viene utilizzato in maniera molto simile da aziende come Zapier ed Airbnb ⬅️

Follow up ed integrazione domanda-risposta

Esempio

Risposta dell’utente: “Pensavo che il design fosse molto semplice.”

Domanda successiva: “Che cosa ti ha fatto pensare che fosse semplice?”

Risposta dell’utente: “Questa non è una funzione che utilizzerei.”

Domanda di follow-up: “Qual è stata la situazione che ti ha spinto a non utilizzarla?”

Risposta dell’utente: “Non mi aspettavo che funzionasse in questo modo.”

Domanda successiva: “Come ti aspetti che funzioni in quella situazione?”

Risposta dell’utente: “Non mi piace quel colore del blu.”

Risposte successive: “Perché non ti piace quel colore di blu?” o “Qual è quel colore che non ti piace in relazione al prodotto?”

Risposta dell’utente: “Questo non è qualcosa che vorrei scaricare e utilizzare.”

Risposte successive: “Puoi dirmi perché questa applicazione non ti è utile?”

Top UX Research Interview Questions to Ask Users, Andrew Smyk, Adobe

Fonti e approfondimenti consigliati

Daniele Lunassi

Design Lead

About me: