User Testing collaborativo: meno preconcetti, migliore ricerca

Non si può evitare di essere parziali#section1

Da persone completamente immerse nel progetto, siamo soggetti a molti parzialità cognitive che possono influenzare i risultati in qualunque fase della ricerca, dalla pianificazione all’analisi. Il confirmation bias tra i valutatori inesperti è comune. Questo ci porta a formulare domande che è più probabile che confermino quello che già pensiamo o che diano inconsciamente priorità a certe risposte e ne ignorino altre. L’ho fatto io stessa e lo vedo anche nei miei colleghi. Per esempio, una volta avevo un collega che era particolarmente attivo nell’introdurre delle funzionalità di ricerca. Nonostante il fatto che solo una persona che aveva risposto aveva commentato della mancanza della ricerca, finirono il processo di test genuinamente convinti che la “maggior parte” delle persone stesse cercando la ricerca.

Tutti noi vogliamo che la ricerca fornisca una guida affidabile per i nostri team. La maggior parte di noi non distorcerebbe volontariamente i dati, ma l’imparzialità viene spesso introdotta senza saperlo, senza che il ricercatore ne sia cosciente. Nello scenario peggiore, risultati distorti o ingannevoli possono fuorviare la direzione del prodotto e danno al team un falsa fiducia nella sua decisione.

La ricerca di Capra e altri studi hanno mostrato che il preconcetto si palesa di solito nella fase di pianificazione (quando si abbozzano i task e gli scenari di testing), durante la sessione stessa (quando si interagisce con i partecipanti e se ne osserva il comportamento) e nella fase di analisi (quando si interpretano i dati e si tirano le conclusioni). Sapendo questo, il mio team in FutureLearn, una piattaforma online di learning, si è proposto di ridurre l’evenienza di preconcetti nella nostra ricerca, oltre a continuare a fare la ricerca rapida ed efficiente di cui il nostro team ha bisogno per progredire. Mi piacerebbe condividere con voi il processo e le tecniche che abbiamo stabilito.

Fate l’inventario delle vostre convinzioni e assunzioni#section2

Prima di cominciare riconoscete onestamente le vostre convinzioni personali, in particolar modo se state testando qualcosa verso cui nutrite “sentimenti forti”. Registrate tali convinzioni e assunzioni e poi trascrivetele.

Pensate che il pulsante “Save” dovrebbe stare sopra alla form piuttosto che alla fine dove non si vede? Vi hanno sempre dato fastidio i menu che scompaiono da un lato? Siete particolarmente compiaciuti e orgogliosi del nuovo elegante controllo che avete realizzato? Siete convinti che questa label confonda e che verrà malinterpretata? Prendendo nota di queste cose, ne avrete maggiore coscienza. Se possibile, lasciate che sia qualcun altro a condurre quando verranno fatti i test in queste aree.

Coinvolgete più revisori durante la pianificazione#section3

In FutureLearn, la nostra ricerca è molto collaborativa: tutti nel team di prodotto (e spesso negli altri team) sono coinvolti attivamente. Cerchiamo di invitare diverse persone ad ogni attività di ricerca e di includere svariati ruoli e competenze: designer, developer, project manager, produttori di contenuto, supporto e marketing.

Cominciamo col condividere un piano di test in due parti in un Google Doc con chiunque si offra volontario per partecipare. Questo include:

• Obiettivi del test: qui scriviamo da una a tre domande a cui speriamo i test aiutino a rispondere. I nostri test tipicamente sono brevi e si concentrano su specifici obiettivi di ricerca. Per esempio, invece di dire: “Vedere in che modo le persone usano il nuovo design del filtro per categorie”, puntiamo a una formulazione oggettiva che incoraggi dei risultati misurabili, come “Scoprire in che modo la presenza del filtro per categoria influenza l’uso dei sorting tab sull’elenco dei corsi”. Formulare gli obbiettivi in questo modo ci aiuta a focalizzare l’interpretazione (o l’interpretazione sbagliata) dei valutatori.
• Scenari di test: basandoci sugli obiettivi, scriviamo tre o quattro task e scenari da analizzare con i partecipanti. Facciamo in modo che si possa intervenire sui task e che questi siano quanto più simili al comportamento atteso nella vita reale, e ci assicuriamo che le istruzioni siano specifiche. Con ogni scenario, forniamo anche il contesto per aiutare i partecipanti ad interagire con l’interfaccia. Per esempio, invece di dire: “Trovate i corsi che iniziano in Giugno”, diciamo qualcosa sulla falsa riga di: “Immaginatevi di essere in vacanza per un mese e di voler vedere se c’è un qualche corso che vi può interessare in quel periodo.”

In una sessione passata, in cui ai partecipanti era stato chiesto di trovare dei corsi specifici, avevamo usato i verbi “trova” e “cerca” nella prima bozza. Un collega notò che chiedendo ai partecipanti di “cercare un corso”, li avremmo indotti a cercare un campo per la ricerca piuttosto che ad osservare il modo in cui si sarebbero mossi naturalmente per cercare un corso sulla piattaforma. Potrebbe sembrare ovvio adesso che “cercare” era il vocabolo sbagliato, ma può essere facile che chi prepara la bozza di uno scenario, se è anche coinvolto nel progetto, possa lasciarsi sfuggire queste sottili differenze. Per evitarlo, adesso facciamo leggere gli scenari a diverse persone autonomamente per essere sicuri che il linguaggio usato non devii le risposte in una direzione particolare.

Fate i test con più valutatori#section4

Nel suo paper, Capra sostiene che avere più osservatori riduce la possibilità di risultati deviati dai pregiudizi e che “avere più valutatori che ci passano meno ore è più efficace che averne di meno che ci passano più ore”. Nota che:

Aggiungere un secondo valutatore fa salire del 30-43% la percentuale dei problemi trovati… I guadagni diminuiscono con ogni valutatore in più, con un aumento del 12-20% dall’aggiunta di un terzo valutatore e un aumento del 7-12% per l’aggiunta di un quarto valutatore.

Nella mia esperienza passata, lo stesso piccolo gruppo di persone (o una singola persona) era sempre responsabile dei test utente. Tipicamente, quelle stesse persone stavano anche lavorando al progetto che stavano testando. A volte, questo portava i valutatori ad avere un atteggiamento difensivo, al punto che l’osservatore provava a dare la colpa ad un partecipante per una pecca del design. Inoltre, a volte rendeva scettici riguardo a risultati non desiderabili o inaspettati i membri del team non coinvolti nella ricerca.

Per evitare questo, abbiamo diverse persone che supervisionano tutte le fasi del processo, inclusa la moderazione delle sessioni. Solitamente, quattro di noi conducono la sessione in corso, due designer, uno sviluppatore e qualcun altro con interessi diversi (come un product manager o un copywriter). È cruciale che solo uno dei designer sia direttamente coinvolto nel progetto così che gli altri tre valutatori possano offrire una prospettiva nuova.

Ancora più importante, tutti sono attivamente coinvolti, non semplici osservatori passivi. Parliamo tutti con i partecipanti, prendiamo appunti e abbiamo un’opportunità di condurre la sessione.

Durante una sessione, impostiamo tipicamente due “stazioni” di test che funzionano indipendentemente. Questo ci aiuta a raccogliere più dati diversificati, dal momento che permette a due coppie di persone di intervistare i partecipanti.

Più valutatori partecipano in ciascuna sessione della user research, che avviene in stazioni come queste.

Le sessioni tendono ad essere brevi e strutturate attorno a specifici obiettivi identificati nel piano. L’intero processo dura non più di due ore, durante le quali le due stazioni combinate parlano a 10-12 partecipanti, ciascuna per 10 minuti circa.

Il preconcetto può assumere varie forme, inclusa la manipolazione dei partecipanti attraverso suggerimenti inconsci o selezionando persone che è più probabile che manifesteranno il comportamento atteso. Condurre un test in un posto pubblico come la British Library, dove opportunamente risiede il nostro ufficio, ci aiuta ad assicurare una gran varietà di partecipanti che rientrano nella nostra demografica target: studenti, professionisti, accademici e persone che vogliono imparare con interessi generici.

Far analizzare i risultati a più persone#section5

Anche l’interpretazione dei dati è incline alla parzialità: scegliere accuratamente i risultati ed essere fissati su alcune risposte ignorandone altre sono comuni tra i valutatori senza esperienza.

Nel nostro team, anche l’analisi dei dati che raccogliamo è un task condiviso. Almeno due di noi scrivono le note in Google Docs e riguardano i video della sessione, che registriamo usando Silverback.

La maggior parte del nostro team non ha esperienza con lo user testing. Dargli un foglio bianco e chiedergli di dare un senso ai risultati sarebbe intimidatorio e time-consuming: non saprebbero cosa cercare. Pertanto, il designer responsabile del test imposta tipicamente una form di Google di base in cui vengono fatte ai valutatori una serie di domande basate sui fatti. Usiamo la seguente struttura:

• Domande generali: nome del partecipante, fascia di età, livello di competenza tecnica, famigliarità con il nostro prodotto e occupazione. Poniamo queste domande proprio all’inizio e contemporaneamente facciamo firmare un modulo di consenso ai partecipanti.
• Performance dello scenario: questa sezione contiene domande specifiche in relazione alla performance dei partecipanti per ogni scenario. Tipicamente, usiamo poche domande a scelta multipla. Dal momento che i nostri test sono brevi, solitamente forniamo da due a quattro opzioni per ogni risposta, piuttosto che scale complesse per la valutazione. I valutatori possono poi fornire informazioni aggiuntive o commenti in un text field aperto.

Estratti dalla Google form che ogni valutatore compila mentre guarda i video della sessione.

Queste semplici form ci aiutano a ridurre l’eventualità di interpretazioni errate da parte del valutatore e rende più semplice per i valutatori senza esperienza condividere le proprie osservazioni. Inoltre, ci permettono di supportare le nostre analisi con dati quantitativi (e.g., quante persone hanno avuto un problema e con che frequenza? Quanto è stato semplice o difficile completare un particolare task? Quanto spesso è stato usato un particolare elemento nella maniera attesa piuttosto che ignorarlo o interpretarlo male?

Utilizzando queste form, un valutatore può tipicamente revisionare tutti i partecipanti delle cinque stazioni in un’ora circa. Facciamo questa cosa il prima possibile, idealmente nello stesso giorno delle sessioni, mentre le osservazioni sono ancora fresche nella memoria e prima di avere l’occasione di analizzarle troppo.

Una volta che i valutatori inviano le proprie form, Google Docs crea un riassunto automatico delle risposte, che include i dati non elaborati con le unità di misura, le citazioni, la performance per ogni task e altri dettagli.

Basandoci su queste risposte, video registrati e note scritte da tutti, il designer responsabile sintetizza i risultati del team. Solitamente io inizio raggruppando tutti i dati raccolti in temi correlati in un altro foglio di calcolo, che mi aiuta a vedere con un colpo d’occhio tutti i dati e mi assicuro così che niente andrà perso o sarà ignorato.

Raggruppare ed organizzare i dati in un foglio di calcolo rende più semplice individuare temi e pattern.

In questa fase, cerchiamo i pattern generali nel comportamento osservato. Inevitabilmente appariranno dei valori erratici e delle contraddizioni. Teniamo traccia di questi separatamente. Dal momento che facciamo ricerca regolarmente, nel tempo questi dati erratici si accumulano, rivelando anche dei nuovi ed interessanti pattern.

Poi, scriviamo un riassunto dei risultati, un breve documento che evidenzia questi pattern e spiega in che modo affrontano gli obiettivi della nostra ricerca. Contiene anche le metriche per la performance dei task, le citazioni memorabili, dettagli interessanti e altre cose che risaltano nel team.

Il riassunto viene condiviso con il team di ricerca per essere sicuri che le loro note siano state incluse ed interpretate correttamente. Il ricercatore responsabile mette poi tutto insieme in un report dello user testing, che viene condiviso con il resto dell’azienda. Questi report sono tipicamente dei brevi PDF (non più di 12 pagine) con una struttura semplice:

• Obiettivi del test e task e scenari: contenuto dal testing plan.
• Rispondenti: una breve panoramica della distribuzione demografica dei rispondenti (basata sulla sezione General Questions).
• Risultati e osservazioni: basati sui riassunti dei risultati registrati prima.
• Conclusioni: step successivi o suggerimenti per come utilizzeremo queste informazioni.

Alcuni team evitano di investire tempo nella scrittura di report ma noi li troviamo utili. Spesso torniamo a far riferimento a loro in fasi successive e li condividiamo con le persone al di fuori del progetto, così che possano anche imparare da quello che scopriamo. Inoltre, condividiamo i risultati in un formato più breve di presentazione durante le sprint reviews.

Rendetelo semplice ma regolare#section6

Condurre regolarmente delle brevi sessioni leggere è meglio che fare dei test lunghi e dettagliati una volta ogni tanto. Far sì che siano brevi e iterativi previene inoltre l’attaccamento da parte nostra ad una specifica idea. La ricerca (PDF) ha suggerito che più si investe su una particolare strada, meno sarà probabile che si prenderanno in considerazione delle alternative, e questo potrebbe anche far aumentare le possibilità che lo user testing si trasformi in una conferma delle proprie credenze.

Abbiamo anche dovuto imparare come rendere efficienti i test, in modo da poterli inserire nel nostro processo continuativo. Adesso passiamo non più di due o tre giorni sullo user testing durante uno sprint di due settimane, inclusa la scrittura del piano, la preparazione di un prototipo in Axure o Proto.io, il test, l’analisi dei dati e la scrittura del report. La ricerca collaborativa ci aiuta a far sì che il tempo di ogni singolo collaboratore sia focalizzato, evitandoci di passare del tempo a filtrare informazioni attraverso i deliverable e gli handoff e aumentando la qualità del nostro apprendimento.

Trovate il tempo per la ricerca#section7

Far rientrare la ricerca in ogni sprint non è facile. A volte vorrei che qualcuno mi desse semplicemente i risultati della ricerca così che io possa concentrarmi sul design invece che sulla raccolta dei dati, ma testare il proprio lavoro regolarmente può essere uno dei modi più efficaci per superare i preconcetti.

Il pregiudizio retrospettivo è un esempio interessante. Diventiamo più inclini a pensare che “abbiamo sempre saputo quelle cose” man mano che aumenta la nostra esperienza e che la nostra percezione del livello della nostra passata conoscenza aumenta. Questo può indurre alcuni designer a credere che l’esperienza “riduce il bisogno dei test di usabilità”. Tuttavia, il rischio è che la nostra esperienza nel design possa rendere più difficile per noi connetterci empaticamente con il nostro pubblico target, per metterci in correlazione con le loro difficoltà mentre usano il nostro prodotto (questo è anche il motivo per cui è così difficile insegnare una materia che padroneggiate molto bene).

Stando a quel che affermano ricercatori come Paul Goodwin, un professore di management science alla University of Bath, il modo più efficace che si conosca per superare il pregiudizio retrospettivo è l’educazione continua (PDF), particolarmente quando lavoriamo sodo per apprendere cose nuove.

Avendo investito sforzi per acquisire nuova conoscenza, ci sono meno possibilità che concludiate di “averlo sempre saputo”. Al contrario, le persone sentono che avevano avuto più conoscenza precedente quando avevano ricevuto nuova conoscenza passivamente e senza sforzi.

Il modo più efficace che conosco per imparare è partecipare attivamente ai test con gli utenti. È inoltre un gran modo per evitare l’arroganza e mettersi in relazione con le persone per cui si sta creando qualcosa. Minimizzare il pregiudizio richiede pratica, onestà e collaborazione, ma ne vale la pena.

Illustrazioni: {carlok}