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

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 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)

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.

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

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?

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

Ecco cosa dire:

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.

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:

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).

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:

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.

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.

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.

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 è:

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.

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

Inizia così:

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.

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à.