Come fare Test di Usabilità “Agile” — Parte 1
Quella che stiamo per leggere è una vera e propria guida pratica ai test di usabilità “Agile”. Pochi in Italia parlano dei test di usabilità “agile version”, chiamati “do-it-yourself” da Steve Krug, o “simple testing” da Jacob Nielsen.
E’ importante sapere che tutto ciò che sto per scrivere proviene dagli studi di Steve Krug, che affronta tecnicamente l’argomento nel suo libro Rocket Surgery Made Easy.
Entriamo nel dettaglio.
Di cosa stiamo parlando?
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 “agile” di tutto questo, della durata di un giorno, conducibile da chiunque, e che non è da meno. Anzi..
Il test “agile”, o “do-it-yourself”, differisce in questo modo:
- Lo fai in un giorno
- I candidati sono solo tre.
- Lo fai una volta al mese.
- Non importa che lo faccia uno UX Designer.
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:
- Un test di usabilità al mese.
- Che questi test siano la guida delle nostre scelte progettuali.
- Che chi faccia i test sia una risorsa interna al team.
E’ difficile pagare un esterno una volta al mese per questo, ma soprattutto è davvero importante che chi faccia i test sia uno dei protagonisti che si vive il prodotto. Questa è la forza dell’Agile Testing.
Infine, 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.
Altri vantaggi del simple testing mensile?
- 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.
- L’idea che abbiamo del nostro prodotto è molto diversa da quella che hanno gli altri.
- Vedere una persona dal vivo che usa il proprio prodotto è illuminante, e allinea maggiormente tutto il team (dove spesso ci sono discrepanze di opinioni).
La guida
- Cos’è un test di usabilità “do-it-yourself”
- Materiale da procurarsi
- Reclutare partecipanti
- Preparare tasks e scenari
- Il test
- Il briefing
- Una riflessione finale
Cos’è un Test di Usabilità “do-it-yourself”
Partiamo dal nome, “do-it-yourself”: significa che ce lo facciamo da soli.
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.
Lista del materiale
Per la Test Room dobbiamo procurarci:
- Computer per il test
- Accesso a internet
- Software di screen sharing
- Software di screen recording
- Microfono
- Casse
- Software di audio sharing (tipo Skype)
Per la Observation Room:
- Proiettore
- Computer per lo screen sharing
- Altoparlanti per audio sharing
Reclutare partecipanti
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:
- 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.
- Meglio fare più test piccoli che meno test grandi.
- Lavorare con tre utenti permette di fare tutto in un giorno (mattina test, pomeriggio briefing).
- 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:
- Il primo alle ore 09:00.
- Il secondo alle ore 10:15.
- Il terzo alle ore 11:30.
Proseguiamo.
Preparare task e scenari
Prima di cominciare il test è necessario scrivere i task e gli scenari.
Cosa sono?
I task sono frasi che sintetizzano la mansione che deve compiere il partecipante.
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.
Gli scenari sono una o più frasi che ipotizzano un contesto nel quale compiere il task.
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.
Consigli per scrivere i task
- Parti dai task più fondamentali. I compiti più importanti del tuo sito.
- Scrivi i problemi che ti tengono sveglio la notte, che non ti hanno mai convinto.
- Fai un giro di tutto il team e di tutte le persone che conoscono il tuo sito per indagare nuovi task.
Consigli per scrivere gli scenari
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.
Bene! Adesso è tutto pronto.
Abbiamo:
- Una lista dei task
- Una lista degli scenari
- Test room attrezzata
- Observation room attrezzata
È uscita la seconda parte del nostro articolo, quindi vai pure e immergiti nella parte più divertente, la sessione di test!
Vedremo cosa dire, come dirlo, e tutti i dettagli che servono per il cuore dei nostri test.
