Guida Pratica ai Test di Usabilità “Light” — Parte 2

Questo è il cuore della nostra guida: la sessione di test.

E' importante leggere la prima parte della guida, che ci permette di preparare tutto ciò che serve alla nostra giornata di test.

Stiamo per vedere come condurre tre sessioni di test, e il briefing di analisi dei risultati.
Tempo di lettura: 13 minuti

Guida Test

Il test

Finalmente cominciamo con la parte più importante. Entriamo nella singola ora dedicata ad ogni partecipante e dividiamola in fasi.

Adesso ci troviamo nella Test Room (non sai cos'è la Test Room? Leggi la parte uno della guida), il nostro partecipante è di fronte al computer, e noi lo affianchiamo con il nostro blocco note e qualche foglio in più che spiegheremo.

Image

Image Source: Stippen Consulting

Tutto è settato, hai già verificato la connessione audio e lo screen sharing con la Observation Room.

Ecco come si svolge il test:

  1. Presentazione (4 min)
  2. Chi è il partecipante (2 min)
  3. Homepage tour (3 min)
  4. I task (35 min)
  5. Nostre domande (5 min)
  6. Domande del partecipante (5 min)
  7. Intervallo (15 min)
Fase 1: Presentazione

Fase 1 Presentazione

Il partecipante si è accomodato e stiamo iniziando la seduta.

Come prima cosa leggeremo il testo riportato qui sotto. E’ consigliabile attenersi ai testi e non improvvisare, questo perché può capitare che alcune parole possano avere significati molteplici ed essere fraintese, soprattutto all’inizio.

Ciao, ________

Il mio nome è ________ e mi occuperò di guidare questa sessione di test oggi.

Prima di cominciare ho qualche informazione da leggerle per assicurarmi che lei abbia compreso tutto.

Molto probabilmente sa già perché è qui ma mi permetta di riassumerglielo brevemente. Stiamo chiedendo a più persone di utilizzare un sito web (di nome ________) a cui stiamo lavorando in modo da vedere se funziona come vogliamo. La sessione con lei durerà un’ora.

La prima cosa che voglio chiarire è che stiamo testando il sito, non lei. Lei non può fare nulla di sbagliato qui. Di fatto oggi questo per lei è un posto dove non si deve preoccupare affatto di commettere errori.

Mentre utilizza il sito le chiederò di pensare ad alta voce, per comunicare cosa sta guardando, cosa sta cercando di fare, e cosa sta pensando. Questo ci aiuterà tanto.

Infine, non si preoccupi se rischia di ferire i nostri sentimenti. Stiamo facendo questo per migliorare il sito, quindi abbiamo bisogno di ascoltare le sue oneste reazioni.

Se nel corso della sessione le viene in mente qualsiasi domanda, chieda pure. Potrei non essere in grado di rispondere subito, dal momento che siamo interessati nel vedere come agiscono le persone quando non hanno qualcuno accanto che le aiutano. Sicuramente sarò in grado di rispondere a fine sessione. E se ha bisogno di fare una pausa in qualsiasi momento basta chiederlo.

Potrebbe aver già notato il microfono. Con il suo permesso, stiamo per registrare quello che accade sul monitor, e la nostra conversazione. La registrazione sarà utilizzata solo allo scopo di comprendere come migliorare il nostro sito web, e non verrà ascoltata o visionata da nessuna persona esterna al nostro progetto. E mi aiuterà con il lavoro, in modo da non dover dedicare l’intera sessione a scrivere appunti.

Inoltre, ci sono alcune persone del nostro team tecnico che stanno osservando questa nostra sessione dall’altra stanza. Non sono in grado di vedere noi, ma solo il monitor e l’audio.

Se per lei non è un problema, le chiederà di firmare per noi un piccolo modulo di consenso. Dice semplicemente che abbiamo il permesso di registrare, e che questa registrazione sarà fruita solo dalle persone interne a questo progetto.

Ha qualche domanda prima di iniziare?

Qui trovi il form di consenso in inglese, alla voce “Recording Consent Form”.

Fase 2: Chi è il partecipante

Rooms situation

Prima di iniziare con i task è necessario fare qualche domandina al partecipante. Questo serve a rodare un po’ la sua parlantina (fra poco dovrà pensare ad alta voce, Thinking Aloud Protocol), fargli vedere che tu sei in suo totale ascolto, e a capire il suo livello di conoscenza tecnica di internet, e la sua vicinanza alla tua idea di audience che utilizza il sito in questione. Servirà anche ad avere un vago profilo utente della persona che stiamo intervistando.

Ok, prima di entrare nel sito vorrei farti qualche domanda veloce.
1. Di cosa ti occupi? Cosa fai tutto il giorno?
2. Sapresti stimarmi più o meno quante ore spendi alla settimana utilizzando internet, inclusa la navigazione web e l’email, sia a casa che a lavoro?
3. Sapresti dirmi in percentuale quanto utilizzi maggiormente la navigazione rispetto all’e-mail, o viceversa?
4. Che tipologia di siti visiti generalmente?
5. Hai qualche sito preferito?

Fase 3: Homepage tour

Rooms situation

Iniziamo. L’homepage è la prima cosa che affrontiamo.

Ecco cosa dire:

Ok, perfetto. Abbiamo finito con le domande, e possiamo cominciare a dare un’occhiata al sito web.

Come prima cosa vorrei chiederti di guardare questa pagina e dirmi cosa te ne pare, cosa ti colpisce, che sito pensi che sia, cosa puoi fare qui, a cosa serve questo sito web. Insomma, dai un’occhiata in giro e facci un po’ di narrazione.

Puoi scrollare la pagina se vuoi, ma ancora non cliccare da nessuna parte per favore. Rimani sulla pagina.

Questo servirà a capire se la comunicazione nella pagina base del nostro sito è ben correlata al servizio che offre il sito in generale.

La copertina del nostro prodotto ci indica o no di cosa si occupa il prodotto? Cosa ne pensa un essere umano medio?

Sarà importante attenersi a questo: stiamo chiedendo al partecipante di capire di cosa tratta il sito a partire dall’homepage, non vogliamo ricevere opinioni grafiche o stilistiche su come secondo lui è l’homepage.

In questa fase l’utente potrà soltanto scrollare la pagina senza cliccare da nessuna parte.

Fase 4: Task

Rooms situation

Siamo arrivati al cuore del nostro test.

Come prima cosa dai una copia del primo scenario al partecipante, e leggilo tu ad alta voce.

Ecco cosa dire:

Adesso sto per chiederti di provare ad effettuare qualche piccolo compito. Sto per leggerne uno a voce alta del quale ti darò anche una copia stampata.

Ti sto anche per chiedere di effettuare questi compiti senza utilizzare la Ricerca. Questo ci aiuterà molto a capire come funziona il sito web.

E ci terrei a ripetere che per noi è importante che tu conduca questo compito pensando ad alta voce.

Una volta che il partecipante comincia a svolgere il task cerca di non interromperlo e al limite ricordargli di pensare sempre a voce alta se tende a non farlo.

Mentre naviga osserva in silenzio e scrivi eventuali appunti che ti vengono in mente. Stessa cosa vale per il team che sta nell’Observation Room.

Quando è tempo di passare al prossimo scenario? Chiaramente quando il partecipante ha completato correttamente la mansione, ma anche quando il processo comincia a diventare un tunnel senza uscita e il partecipante prova troppa frustrazione, e quando ti rendi conto di avere poco tempo e di voler approfondire bene i restanti tasks.

Procedi con questo format per tutti gli scenari, tieni sempre d’occhio il tempo.

Ti verranno in mente delle domande aggiuntive da fargli (del tipo, cos’è più importante per te rispetto a questa mansione? Quali informazioni vuoi avere prima di..? Cosa non hai capito di quello scenario? Non conoscevi questo termine tecnico? ecc.).

Segnatele, le porgerai nella prossima fase.

Concludi tutti gli scenari, e se non c’è tempo per qualcuno, purtroppo lo salterai e andrai avanti (con il prossimo candidato avrai un’idea migliore del tempo).

Fase 5: Nostre domande

Rooms situation

In questa fase farai le eventuali domande che ti sei segnato.

Mettiti in comunicazione con la Observation Room e senti se i tuoi colleghi hanno qualche domanda da fare. Trova una tua gestione del tempo, questa è una fase che può essere molto lunga come molto breve, gestiscila in base alle tue circostanze (Steve Krug consiglia cinque minuti).

Ecco cosa dire:

Grazie, la nostra sessione è stata molto di aiuto per noi.

Se mi concede un minuto, vorrei chiedere al team se ha qualche domanda in particolare che le piacerebbe fare.

Fase 6: Conclusioni

Rooms situation

Abbiamo finito. Ringrazia il partecipante, senti se ha qualche ultimo appunto da fare. Prendi con le pinze tutti i suoi consigli stilistici, dai importanza alle sua difficoltà e incomprensioni.

Fase 7: Intervallo

Rooms situation

Ci sarà un intervallo di dieci o quindici minuti nel quale:

  1. Salverai l’audio
  2. Salverai lo screen recording
  3. Ripulirai cronologia e cache browser
  4. Riordinerai i tuoi appunti
  5. Scriverai altre eventuali cose che ti vengono in mente

E dopodiché aprirai le porte al prossimo partecipante.

Una volta finiti i tre test, passiamo al briefing.

Il briefing

Bene, abbiamo finito le tre sessioni di test. Il team ha già pranzato e adesso sono le 15:00, ci apprestiamo a iniziare il briefing, che dovrebbe durare un’ora.

Rooms situation

Due sono le cose che dobbiamo tirare fuori da questa riunione:

  1. Una lista dei problemi di usabilità più seri
  2. Una lista dei fix decisi in base ai problemi

Il briefing dovrebbe avere luogo realmente lo stesso giorno, in modo che l’esperienza con i partecipanti sia ancora fresca nella mente di tutti.

Si consiglia di permettere l’accesso al briefing solo a chi ha fatto parte dell’ Observation Team. Questo per evitare “dibattiti religiosi” (così li chiamano) fondati su opinioni personali.

Una massima alla base del meeting è:

Concentrati principalmente sui problemi evidentemente più seri.

Visto che di problemi ce ne saranno tanti. Molti cercheranno di dare la loro opinione che molte volte esulerà dalla reale esperienza del mattino.

Molti ingigantiranno problemi che in realtà sono minori, e che riguardano più una loro personale visione stilistica o fastidio che si portano dietro da tempo, rispetto che un’ oggettiva constatazione sulle conseguenze di quel problema.

Ricordiamoci che stiamo raccogliendo l’esperienza degli utenti, e non del team.

E’ necessario saper fare un’oggettiva scala di “pericolosità” dei problemi.

In UX Design è necessario imparare ad essere oggettivi e mettere da parte quanto ci sentiamo esperti di internet o bravi con le visioni progettuali. Bisogna saper essere realistici e scientifici.

Tuttavia chi conduce il briefing deve essere bravo a mantenere un clima di condivisione tranquillo e a far sì che quanto scritto sopra non diventi un comandamento stacanovista. Anzi, i test di usabilità sono sempre abbastanza delicati, perché si mette in dubbio il duro lavoro di molte persone, quindi è necessaria serietà ma anche delicatezza e comprensione.

Programma del briefing

Ecco come più o meno può andare un briefing, in ordine:

Inizia così:

Benvenuti al briefing di rielaborazione dei dati analizzati stamattina. Questo meeting non dovrebbe durare più di un’ora. Quello che faremo adesso sarà stilare una lista dei dieci maggiori problemi individuati stamani. Dopodiché stileremo una scala di priorità su questi, e una rispettiva lista con i fix. ”

Dopodiché, in ordine:

  1. Chiedi a tutti di riguardare la propria lista dei problemi che si sono segnati stamani durante i test, e chiedi di scegliere i tre che considerano più urgenti.
  2. Chiedi ad ognuno di leggere i loro tre problemi uno alla volta.
  3. Segnali tutti su una lavagna.
  4. Una volta che hai l’intera lista davanti comincia a segnare te (con dei checkmark) i dieci problemi che ritieni più urgenti, chiedendo dopodiché al team se sono d’accordo con le scelte. Eventualmente modifica.
  5. Riordina la lista sulla base delle priorità che avete discusso per ogni task. Scrivi (1) sul problema più grande, e così via.
  6. Rileggi la lista dal primo punto al decimo, e per ognuno di questi discuti con il team i relativi fix.
  7. Scrivi la lista dei fix.

Ringrazia tutti e termina la seduta.

Raccogli tutto il materiale e manda un e-mail di riepilogo a tutti. Rielaborerai il materiale secondo la tua esperienza e le tue circostanze. Non importerà fare grossi report con presentazioni, all’interno del tuo team saprai cosa è realmente utile e come presentarlo. E’ inutile dedicare tante ore a report quando si tratta di test di usabilità effettuati così frequentemente.

Conclusioni

So che non è semplice proporre una cosa del genere al proprio team, far stare tutti una mattina intera a guardare un monitor. Se sei arrivato a leggere fin qui evidentemente sei la persona più adatta per fare questo. Perché per fare “simple testing” non servono grandi abilità, ma serve di aver compreso l’importanza di condurre questi test.

Chiediamoci una cosa. Che senso ha sviluppare prodotti per utenti che non conosciamo? Non vorrei chiamarli utenti, vorrei precisare che sono esseri umani. In realtà voglio affermare che ci sono persone al mondo che stanno nobilmente sviluppando tecnologie per l’umanità oggi, e che l'Italia non deve essere da meno. Dobbiamo conoscere questi esseri umani. Perché delle volte stiamo sviluppando dei nostri giocattolini personali, dei nostri sfizi, e nemmeno ce ne rendiamo conto.

Chiediamoci: è davvero utile il mio prodotto? Per chi? Ho mai osservato da vicino un essere umano che utilizza il mio prodotto, la cui vita è realmente semplificata da esso?

Se non ho mai incontrato un utente finale, in base a cosa sto sviluppando? Google Analytics? Sondaggi? Sto passando mesi della mia vita a sviluppare una mia idea di prodotto, forse. Su quale base idealistica dovrebbe essere un prodotto utile il mio? Dobbiamo valutare i fatti, non le idee. Google Analytics, Kiss Metrics, Mix Panel, ci danno numeri. Ma dove sono le persone? Siamo realmente utili all’umanità con quello che sviluppiamo ogni giorno?

Conducendo test di usabilità conosciamo le persone senza le quali il nostro prodotto, il nostro ufficio, le nostre ore di lavoro, non esisterebbero. Personalmente amo come mi semplificano la vita tanti tool che utilizzo. Ad esempio, sto amando utilizzare Sketch al posto di Photoshop, simulare i prototipi su InVision, gestire un e-commerce su Shopify, gestire mailing list su Mailchimp; e vorrei che i founder di Sketch, Photoshop, InVision, Shopify fossero qui accanto a me adesso.

Un giorno manderemo un e-mail a un utente storico della nostra piattaforma, gli regaleremo delle premium subscriptions, dei gadget, lo intervisteremo da remoto con le tecniche di cui abbiamo parlato oggi. Non sono solo i nostri wireframes e prototipi a essere user-centered, ma anche il nostro approccio mentale sempre. La nostra missione è user-centered, è human-centered, è humanity-centered. Senza idee o cose astratte, ma intervistando l’umanità, lavorando per l’umanità.

Senza dubbio fare “simple testing” è anche connettersi con il cuore dei nostri progetti: l’umanità.

Hai trovato questo post interessante?Scopri chi siamo

Made with Middleman and DatoCMS, our CMS for static websites