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

I test di usabilità sono condotti da UX Designers. Generalmente questi intervistano un campione che è sugli 8–12 candidati, chiedono agli intervistati di fare determinati compiti sul sito, registrano il materiale che raccolgono e forniscono al cliente una presentazione molto dettagliata sui flussi critici del sito, e un report con i fix di questi. Il tutto può richiedere più o meno tre settimane.

Noi parleremo della versione “light” di tutto questo, della durata di un giorno, conducibile da chiunque, e che non è da meno. Anzi..

Il test “light”, o “do-it-yourself”, differisce in questo modo:

1. Lo fai in un giorno
2. I candidati sono solo tre.
3. Lo fai una volta al mese.
4. Non importa che lo faccia uno UX Designer.

Chiarisco: Se possiamo permetterci di pagare un professionista dell’usabilità per fare i test, bene. Sicuramente farà un lavoro migliore di chiunque si cimenti in quello che stai per leggere.

Ma noi vogliamo:

1. Un test di usabilità al mese.
2. Che questi test definiscano la road map di sviluppo del tuo prodotto.
3. Che sia una risorsa interna al team.
4. E che chiunque possa condurre questi test.

E’ difficile pagare un esterno una volta al mese per questo. E soprattutto i test che stai per conoscere sono molto più magri. Può farli chiunque.

Come dice Jacob Nielsen:

Tutti dovrebbero fare “_simple user testing (debugging a design)_”, mentre gli esperti di usabilità nemmeno dovrebbero dedicarsi a tecniche così semplici. Hanno cose molto più difficili da fare, come i test qualitativi, comparativi, sviluppare nuove metodologie, ecc.

D’altronde, chi ha UX Designer nel proprio team? Alzi la mano. Intendo figure che si occupano di personas, user stories, heuristic evaluations, user testing, user flows, site flows, ecc. e conducono studi nel tempo.

Per la startup italiana media lo UX Designer è chi fa i wireframes. Questo è piuttosto grave, e servirebbe un articolo solo per questo. La maggioranza delle startup in Italia sta costruendo una casa senza architetto. Questa è la realtà. Non vuole essere una critica, ma uno spunto per procedere altrove.

Per tornare a Nielsen, “Debugging a design” non significa solo far vedere i proposal al team. E’ necessario uscire dalla scatola il prima possibile. E’ necessario far testare i propri prodotti il prima possibile e costantemente nel tempo.

Dobbiamo ricordarci che il termine MVP (Minimum Viable Product) nasce per fornire un prodotto il prima possibile testabile da esseri umani esterni al nostro team.

1. Fra tutte le cose che si possono fare, i test di usabilità sono tra le cose migliori che possiamo fare per il nostro sito web.
2. L’idea che abbiamo del nostro prodotto è molto diversa da quella che hanno gli altri.
3. Vedere una persona dal vivo che usa il proprio prodotto è illuminante, e allinea maggiormente tutto il team (dove spesso ci sono discrepanze di opinioni).

Perché una startup coltiva un singolo prodotto, e i test di usabilità vanno condotti nel tempo, continuativamente, mensilmente. Andranno di pari passo con la storia del prodotto.

E’ più difficile impostare questo lavoro per un’agenzia che costruisce siti per terzi. E’ difficile che il cliente comprenda l’importanza dei test, e di conseguenza non ci sarà budget per questo.

Ci sarebbero un sacco di altre cose da dire prima di iniziare (precisazioni sulle iterazioni Agile, fare i test da remoto, costi delle risorse, comparazioni fra i test “light” e i test veri, ecc.), ma per questo consiglio di leggere direttamente il libro di Steve Krug.

L’articolo che stai leggendo è realmente la sintesi di un libro, farina del sacco di Steve Krug. Steve Krug ha condotto migliaia di test di usabilità nella sua vita, e ha testato e ri-testato la versione “light” che stiamo per trattare.

Fare piccoli test di usabilità ogni mese invece che uno grande ogni sei, o ogni anno, è un vero e proprio approccio Agile. Potremmo chiamarlo Agile User Testing.

Che senso ha passare mesi e mesi a sviluppare prodotti per l’umanità, quando non conosciamo nemmeno una persona che utilizza il nostro sito? Per chi stiamo sviluppando questi prodotti? Forse per la propria gloria personale? Avere il coraggio di aprirsi il prima possibile allo user-testing diventa anche mettere le nostre tecnologie al servizio dell’umanità, definire nobilmente il nostro lavoro di informatici. Pochi comprendono o condividono questo. Ma non adesso possiamo approfondire questo tema..

Bene, passiamo alla guida.

1. Cos’è un test di usabilità “do-it-yourself”
2. Materiale da procurarsi
3. Reclutare partecipanti
4. Preparare tasks e scenari
5. Il test
6. Il briefing
7. Una riflessione finale

Partiamo dal nome, “do-it-yourself”: significa che ce lo facciamo da soli.

L’altro nome, “light”: significa che è una versione sintetizzata.

Ecco come si svolgerà la nostra giornata di testing:

Reclutiamo tre partecipanti (solo tre? Sì, è spiegato fra poco).

Spendiamo una mattina con loro, un’ora a testa intervallate da un quarto d’ora.

Per ognuno, tu (che prendi il nome di Facilitator) affiancherai e condurrai il test. Condurrai quest’ora seguendo una struttura ben definita (di cui parleremo più avanti nell’articolo).

Mentre tu in una stanza (detta Test Room) fai questo, un’altra stanza (detta Observation Room) ospita i tuoi colleghi di lavoro, il tuo team.

Nella Observation Room una parete bianca sarà adibita alla proiezione del monitor che stai condividendo con loro. Stessa cosa per l’audio, che verrà catturato nella Test Room, e condiviso nella Observation Room.

Perché l’audio? Perché il partecipante penserà ad alta voce (_Thinking Aloud Protocol_), e il suo flusso di coscienza interesserà alle nostre analisi.

Finita la mattinata ci sarà una pausa pranzo, per poi proseguire con un briefing con tutti gli osservatori della mattina (il team). Tu dovrai coordinare il briefing, il cui svolgimento spiegheremo tra poco.

Per la Test Room dobbiamo procurarci:

1. Computer per il test
2. Accesso a internet
3. Software di screen sharing
4. Software di screen recording
5. Microfono
6. Casse
7. Software di audio sharing (tipo Skype)

Per la Observation Room:

1. Proiettore
2. Computer per lo screen sharing
3. Altoparlanti per audio sharing

La prima domanda può essere: Ma solo tre utenti?

Sì. O meglio, Steve Krug nell’arco di anni (e migliaia di test di usabilità) ha concluso che è un numero che funziona.

Le motivazioni sono:

1. I primi tre utenti il più delle volte individuano già la gran parte delle problematiche, perché queste sono più frequentemente legate a questioni di layout grafico.
2. Meglio fare più test piccoli che meno test grandi.
3. Lavorare con tre utenti permette di fare tutto in un giorno (mattina test, pomeriggio briefing).
4. Avere meno risultati dei test permette di elaborare tutto nel giro di un briefing pomeridiano, e di fare le cose un po’ per volta. Troppi risultati creano confusione e stress, soprattutto in sede di briefing, e richiedono maggior tempo.

La seconda cosa che può venire in mente è: Ma i tre utenti devono essere targettizzati?

Vale a dire, tipologie di utenti che generalmente utilizzano il sito?
La risposta è no, non proprio, non sempre.

Nel senso che non ci dobbiamo incaponire su questa cosa. Molte volte i problemi riguardano disposizioni tecniche di layout, navigabilità, leggibilità, e a meno che il tuo sito non sia scritto in giapponese il tuo raggio di reclutamento partecipanti è molto ampio.

Cerca di variare l’audience, soprattutto perché il più delle volte tu pensi di sapere chi sia il tuo audience, e pensi anche di conoscere il loro livello tecnico rispetto alla rete, ma così non è.

Detto questo, dovresti trovare tre partecipanti a cui darai appuntamento:

1. Il primo alle ore 09:00.
2. Il secondo alle ore 10:15.
3. Il terzo alle ore 11:30.

Proseguiamo.

Prima di cominciare il test è necessario scrivere i task e gli scenari.

Cosa sono?

Devono essere molto chiari, e rimangono lato Facilitator (tu) e Observation Team. Non verranno comunicati al partecipante.

Saranno gli scenari invece ad essere letti al partecipante.

Ad esempio, stiamo testando un sito che dà consulenze per le energie rinnovabili:

Qualcuno potrebbe conoscere i tasks anche sotto il nome di Use Cases.

1. Parti dai task più fondamentali. I compiti più importanti del tuo sito.
2. Scrivi i problemi che ti tengono sveglio la notte, che non ti hanno mai convinto.
3. Fai un giro di tutto il team e di tutte le persone che conoscono il tuo sito per indagare nuovi task.

Gli scenari sono semplici, servono a semplificare il lavoro al partecipante. Gli esempi precedenti ti bastano per capire. Basta aggiungere un contesto ed eventuali informazioni aggiuntive ad un task di partenza. Sii sempre chiaro e sintetico, e non utilizzare termini tecnici.

Stampa task e scenari per ogni osservatore del team e per te.

Tutto è settato per la giornata di test. Nella parte due di questa guida vediamo come effettuare la sessione di test, e come condurre il briefing. [Continua a leggere](/blog/2016/11/02/guida-pratica-test-usabilita-parte-2/)