5.1.6.3.1. Analisi preliminari del sito e dei destinatari¶

I test di usabilità, come quello che si può realizzare con la procedura eGLU, si applicano a una grande varietà di situazioni e di progetti, e in momenti diversi del ciclo di progetto. La procedura è comune, ma alcuni controlli possono cambiare a seconda del tipo di progetto.

Questa analisi preliminare va attuata ogni volta che si deve testare un sito online e funzionante (e non, ad esempio, se si intende testare un semplice prototipo semifunzionante), e serve a verificare che si visualizzi correttamente su tutti i dispositivi, in particolare quelli mobili, che si intendono utilizzare per i test. Come previsto da il “Piano Triennale per l’Informatica nella Pubblica Amministrazione 2017-2019”, tutti i progetti delle PA devono infatti essere realizzati secondo una strategia mobile-first.

5.1.6.3.2. Quanti e quali tipologie di partecipanti selezionare¶

5.1.6.3.3. Quali e quanti task preparare¶

Il conduttore deve preparare le descrizioni dei task da assegnare ai partecipanti. Ogni task deve descrivere degli obiettivi che i partecipanti devono cercare di raggiungere utilizzando l’interfaccia. Non c’è una regola assoluta, ma un numero di task tra 4 e 8 offre una buona copertura delle possibili attività sul sito e un numero di dati sufficienti per valutare la facilità d’uso dello stesso.

Il conduttore sceglie e descrive i task cercando di individuare e rappresentare una situazione il più possibile concreta. Nella formulazione bisogna essere chiari e usare sempre espressioni comuni, evitando di utilizzare parole chiave che potrebbero facilitare il partecipante nel raggiungimento dell’obiettivo e falsare, quindi, il risultato del test: ad esempio, vanno evitati il nome del link corrispondente, o richiami al testo del link o di qualunque altro link nei menu, il formato del file da trovare. Se il task contiene la parola “imposte” e c’è un link “imposte” sul sito, è molto probabile che anche chi non capisce cosa voglia dire il task scelga il link “imposte” per semplice riconoscimento. In tal caso usare una parafrasi.

È importante che tutti i partecipanti eseguano gli stessi task, uno alla volta, ciascuno per conto proprio. Ma affinché il test dia qualche indicazione utile, è necessario che i task siano significativi, scelti cioè fra le attività che plausibilmente gli utenti reali svolgerebbero sul sito.

Per capire quali attività gli utenti svolgono effettivamente sul sito - attività questa preliminare alla identificazione e formulazione dei task - ci sono diversi metodi:

• parlare con utenti reali conosciuti e chiedere loro per cosa usano più spesso il sito;
• raccogliere informazioni con un questionario online che chieda la stessa cosa;
• analizzare le pagine più viste;
• analizzare le chiavi di ricerca utilizzate più spesso nel motore interno al sito;
• formulare degli scenari d’uso.

La copertura delle tipologie di task è affidata comunque all’analisi del sito, delle sue necessità, dei suoi usi e delle sue statistiche.

5.1.6.3.4. Come preparare i moduli per la raccolta dei dati¶

Prima di eseguire la procedura, devono essere adattati e stampati tutti i documenti necessari:

• un’introduzione scritta per spiegare gli scopi del test. Lo stesso foglio va bene per tutti perché non c’è necessità di firmarlo o annotarlo (Guida alla Conduzione del test);
• un modulo di consenso alla eventuale registrazione audiovideo per ciascun utente (Liberatoria);
• per ciascun utente, un foglio con i task, dove annotare se gli obiettivi sono raggiunti o meno e i comportamenti anomali (Guida alla Conduzione del test);
• può risultare utile stampare un task per foglio e consegnare ogni volta il foglio corrispondente, poiché è importante che gli utenti, mentre eseguono un task, non abbiano conoscenza dei task futuri;
• i fogli per il questionario di soddisfazione finale, in copie sufficienti per tutti gli utenti (a seconda delle scelte, uno o più fra il Net Promoter Score , il Questionario SUS e le Domande UMUX Lite ; N.B.: il Questionario SUS e le Domande UMUX Lite sono da considerarsi in alternativa).

5.1.6.3.5. Cosa fare prima dell’osservazione: il test pilota¶

Prima di iniziare l’osservazione con i partecipanti al test, è importante che il conduttore esegua i task e li faccia eseguire ad un collega, per realizzare quello che si chiama “test pilota”. Questo consente di verificare se ci sono problemi nell’esecuzione o altre problematiche che è bene risolvere, prima di coinvolgere i partecipanti. Il test pilota, inoltre, serve anche a:

• accertarsi che siano ben chiari i criteri di successo per ogni task;
• notare se il sito presenta malfunzionamenti o se la formulazione dei task debba essere migliorata;
• apportare le eventuali necessarie modifiche ai criteri di successo o alla formulazione dei task.

Al fine di effettuare questi controlli è consigliabile utilizzare diversi dispositivi mobili, con differenti tipi di connessione internet e diversi tipi di browser. Una lista aggiornata di browser, con i quali è suggerita la compatibilità dei siti e applicazioni pubbliche, è disponibile nella sezione dedicata. Non è necessario che l’aspetto del sito sia identico sui diversi dispositivi; va tuttavia garantita un’esperienza utente equivalente.

5.1.6.3.6. Prendere appuntamento con i partecipanti¶

I partecipanti vanno contattati e con ciascuno di loro va preso un appuntamento. Se si intende procedere a più test nello stesso giorno, la distanza tra l’appuntamento di un partecipante e l’altro deve essere di almeno un’ora. Infatti, per ogni sessione di test bisogna calcolare il tempo per eseguire con calma l’osservazione, per effettuare la revisione degli appunti e, infine, per la preparazione della nuova sessione di test da parte del conduttore.

5.1.6.4.1. Preparazione di un ambiente idoneo per test mobile e desktop¶

La caratteristica principale dei dispositivi mobile è la loro portabilità ovvero il fatto che permettono ad un utente di interagire ovunque tramite internet.

Per i dispositivi mobile quindi, al fine di controllare l’uso del servizio in contesti diversi, il conduttore può predisporre valutazioni al di fuori del classico ambiente chiuso che solitamente si utilizza nelle valutazioni con dispositivi desktop.

Definiamo quindi un ambiente di valutazione strutturato e non strutturato:

• Ambiente strutturato: Ideale per valutazioni desktop, ma idoneo anche per quelle mobile. Questo è un ambiente chiuso ed organizzato per effettuare il test in modo da poter tenere sotto controllo fattori come il rumore di fondo o le interruzioni dovute ad agenti esterni.
• Ambiente non strutturato: Ideale per valutazioni mobile, ma spesso non idoneo per test desktop. Questo è un ambiente di vita comune in cui si può decidere di effettuare il test per vedere come il prodotto viene utilizzato dall’utente in circostanze più vicine alla realtà. Esempi di ambienti non strutturati possono essere: ambienti comuni o di vita quotidiana in mobilità come un luogo pubblico, un bar, un ristorante, un autobus ecc. In questo tipo di ambienti risulta più difficile controllare interruzioni o altri fattori, per cui un ambiente non strutturato sarà anche meno controllato.

Di seguito sono descritte le fasi esecutive del test, distinte tra ambiente strutturato e non strutturato.

5.1.6.4.2. Interazione con i partecipanti e conduzione del test¶

5.1.6.4.3. Dati da raccogliere¶

Durante la conduzione è necessario che il conduttore del test (preferibilmente con l’aiuto di un assistente) raccolga i seguenti dati:

• prima di iniziare, una scheda personale anagrafica, se la stessa non è stata già compilata nella fase di reclutamento. Si veda nel kit Usability Test la Scheda Partecipanti;
• per ogni partecipante e per ogni task, il dato relativo al superamento o meno del task. Si suggerisce, per semplicità, di stabilire un criterio dicotomico, sì o no. In caso di task parzialmente superati, è necessario definire in maniera univoca il successo parziale come un successo o come un fallimento;
• per ogni partecipante, un questionario generale, fatto compilare al termine di tutti i task (ma prima di svolgere un’eventuale intervista di approfondimento con il partecipante): si consiglia per la sua rapidità di utilizzare almeno uno fra il System Usability Scale (Questionario SUS ) e lo Usability Metric for User Experience (Domande UMUX-LITE). Tali questionari servono per avere indicazioni sulla percezione di facilità d’uso da parte dei partecipanti, un aspetto che va analizzato assieme alla capacità di portare a termine i task;
• accanto ai predetti questionari di usabilità, vista la facilità di somministrazione, è possibile utilizzare anche il Net Promoter Score (NPS), che mostra elevata correlazione con il SUS;
• durante l’esecuzione dei task, schede per annotare eventuali difficoltà o successi del partecipante (nello spazio apposito previsto dopo ogni task, come indicato nel Kit nella Guida alla Conduzione del test);
• al termine del test e dopo la compilazione dei questionari, si può richiedere al partecipante di raccontare eventuali difficoltà e problemi incontrati (che vanno anche essi annotati) ed eventualmente chiedere chiarimenti su alcune difficoltà che l’osservatore potrebbe aver notato.

Prevediamo nei prossimi mesi di pubblicare degli approfondimenti sui questionari.

Proprio perché potrebbe essere difficile annotare tutti i dati e contemporaneamente effettuare altre operazioni come, ad esempio, avviare e fermare la registrazione o svuotare la cache al termine di ogni sessione, è consigliabile che siano almeno 2 persone a condurre il test, con ruoli complementari definiti a priori. È auspicabile che l’annotazione dei comportamenti e delle verbalizzazioni del partecipante venga svolta, per quanto possibile, sia dal conduttore che dall’eventuale assistente.

5.1.6.4.4. Osservare e annotare i problemi¶

Durante il test è molto importante, oltre a interagire in modo corretto con il partecipante (evitando di influenzarlo), annotare i problemi che questo incontra o le sue reazioni positive rispetto a funzionalità o contenuti del prodotto. Potrebbe, ad esempio, non essere sempre semplice identificare un problema, se il partecipante non lo esprime direttamente. Si indicano perciò, di seguito, alcune categorie di eventi che si possono classificare come problemi o difficoltà del partecipante, oppure come apprezzamenti del partecipante:

• problemi

  • il partecipante si blocca;
  • il partecipante dichiara di essere confuso da elementi di layout, immagini, video, ecc.;
  • il partecipante dichiara di essere confuso dalla sovrabbondanza di opzioni;
  • il partecipante sceglie un percorso del tutto errato;
  • il partecipante non riconosce la funzione di testi, bottoni;
  • il partecipante travisa il significato di testi, bottoni;

• apprezzamenti

  • il partecipante esprime di sua iniziativa apprezzamenti su un contenuto/servizio specifico;
  • il partecipante esprime di sua iniziativa un apprezzamento rispetto alla ricchezza/completezza/utilità di un contenuto/servizio;
  • il partecipante esprime di sua iniziativa la soddisfazione rispetto a un task completato con successo e facilità.

Si veda anche il paragrafo a seguire «Elenco dei problemi osservati».

5.1.6.4.5. Congedare i partecipanti al termine del test¶

Terminata la navigazione, il conduttore ringrazia il partecipante per la sua disponibilità, sottolineando quanto sia stato prezioso il suo aiuto e risponde a tutte le eventuali domande e curiosità riguardo alla valutazione. Il conduttore fornisce inoltre al partecipante i propri contatti invitandolo a segnalargli, anche successivamente, le sue ulteriori impressioni sull’utilizzo del sito.

5.1.6.4.6. Prima del partecipante successivo: note sulla temporizzazione¶

Prima di accogliere il partecipante successivo, il conduttore e il suo eventuale assistente salvano la registrazione eventualmente acquisita; quindi rivedono e riordinano gli appunti e le note raccolte, relative al partecipante appena congedato. Ciò serve a rafforzare le osservazioni evitando di dimenticarne alcuni aspetti, ma anche alla disambiguazione e alla interpretazione condivisa dei fatti osservati, nel caso sia presente un assistente. A questo punto viene preparata la sessione successiva, predisponendo di nuovo il browser, di cui si consiglia di cancellare la cache. Vengono preparati i documenti per il partecipante successivo, vengono riavviati e preparati i programmi o l’hardware per la video o audio registrazione.

È consigliabile una pausa tra un partecipante ed un altro. In questo modo il conduttore potrà riorganizzare le idee, riposarsi e effettuare una sorta di “reset mentale” in vista del successivo partecipante. Si consiglia perciò di prevedere tra ogni partecipante una finestra temporale di almeno 15 minuti. Tuttavia, partecipanti differenti potrebbero impiegare tempi anche sensibilmente differenti a eseguire il test. Dunque, si consiglia di prevedere un tempo congruo per ogni partecipante (che includa accoglienza, esecuzione e riorganizzazione-preparazione del successivo), in ogni caso non inferiore a un’ora. Prendendo fin da subito appuntamenti con i partecipanti a distanza di almeno un’ora tra di loro, si eviterà l’arrivo del successivo partecipante quando non si sono ancora sbrigate tutte le pratiche del precedente. La temporizzazione qui indicata è quella minima e potrebbe essere modificata verso l’alto in caso di test più impegnativi.

5.1.6.5.1. Dati di prestazione e questionari di valutazione¶

I dati di successo nei task, raccolti durante l’osservazione, vanno inseriti nella Tabella dei Risultati dopo la fine dell’esecuzione della procedura.

Questo kit serve:

• a calcolare il tasso di successo complessivo del sito (calcolato su K task x N utenti totali);
• a dare un dettaglio anche di quale task abbia avuto il tasso di successo più alto.

Inoltre, i dati soggettivi di intenzione d’uso (NPS), o di usabilità percepita (SUS e UMUX-LITE), espressi attraverso i questionari post-test, vanno elaborati manualmente utilizzando le formule fornite o automaticamente con le tabelle di calcolo presenti nel kit:

• il Net Promoter Score per il Net Promoter Score (NPS);
• il Questionario SUS per il System Usability Scale (SUS);
• le Domande UMUX Lite nel caso si sia usato lo Usability Metric for User Experience (UMUX-LITE).

Prevediamo nei prossimi mesi di pubblicare degli approfondimenti in merito.

Circa i criteri di valutazione del punteggio nei questionari, si consideri quanto segue:

• il punteggio NPS (che può distribuirsi fra -100 e 100) dovrebbe essere almeno positivo, e quanto più possibile vicino al 100;
• il punteggio del SUS (che va da 0 a 100) dovrebbe essere almeno maggiore di 68, e idealmente più alto;
• il criterio per valutare il punteggio UMUX-LITE è al momento il medesimo adottato per il SUS (>68).

5.1.6.5.2. Elenco dei problemi osservati¶

Bisogna stilare un elenco dei problemi osservati, sulla base dell’elenco visto nella Fase 2. Esecuzione, paragrafo «Osservare e annotare i problemi». Per ogni problema è utile indicare il numero di partecipanti che lo ha incontrato. In questo modo è possibile avere una stima dei problemi più frequenti. Pur se esula dallo scopo del protocollo, può essere utile provare ad assegnare, ove possibile, un giudizio di gravità o di impatto per ciascun problema, a discrezione del conduttore e dell’eventuale assistente.

I problemi osservati andrebbero tutti affrontati e discussi dai responsabili del sito, che sono i principali candidati a indicare le modifiche da effettuare.

Se necessario, bisogna avvalersi della consulenza di un esperto per l’interpretazione dei problemi o per l’identificazione delle migliori soluzioni.

5.1.6.5.3. Stesura di un report¶

Il report conterrà i seguenti dati minimi:

• Il numero di partecipanti e di task;
• la descrizione dei task e pagine di completamento (o criterio di successo) del task;
• il tasso di successo del sito;
• il tasso di successo per ciascun task e per ciascun partecipante;
• il SUS o lo UMUX-LITE - Misure dirette dell’usabilità percepita;
• il NPS - Misura di intenzione d’uso del sito web;
• un elenco dei problemi riscontrati.

Un ulteriore livello di approfondimento del report può prevedere:

• una valutazione dei problemi per numero di partecipanti e gravità;
• dei suggerimenti per la risoluzione dei problemi;
• una connessione dei problemi riscontrati ai principi euristici violati dall’interfaccia.

Si può fare riferimento all’allegato Report dei risultati presente nel Kit per un semplice modello di report da utilizzare.

5.1.6.6.1. Fase 1¶

1. Effettuare prove preliminari sul sito mobile con alcuni tool per verificarne le funzionalità di base;
2. effettuare delle verifiche con metodi euristici per verificare lo stato attuale;
3. utilizzare i dati degli Analytics del sito per ottenere utili indicazioni sulla popolazione di riferimento e sui browser e dispositivi più utilizzati;
4. identificare la popolazione fra cui scegliere i partecipanti;
5. identificare un numero minimo di 5 partecipanti e massimo di 8, se presente un’unica tipologia di utenti e di 3 partecipanti per ogni tipologia, se presenti da 2 a 3 tipologie distinte;
6. definire i task (gli stessi per tutti i partecipanti) da far svolgere ai partecipanti;
7. per ciascun task definire i criteri di successo o di fallimento, nonché un tempo limite oltre il quale considerare il task fallito, anche se il partecipante continua e alla fine riesce a raggiungere il successo;
8. prendere appuntamento con i partecipanti. Nel caso di un ambiente strutturato organizzare una stanza dedicata dove approntare browser e software di registrazione;
9. svolgere un test pilota con un collega.

5.1.6.6.2. Fase 2¶

10. Ricevere uno a uno i partecipanti, somministrando i task, mentre un assistente si occupa della registrazione;
11. interagire con i partecipanti, influenzandoli il meno possibile;
12. annotare i task riusciti e quelli falliti;
13. annotare ogni problema, apparentemente incontrato dal partecipante, che si riesca a identificare;
14. al termine dell’esecuzione dei task somministrare il System Usability Scale (Questionario SUS) o lo Usability Metric for User Experience (Domande UMUX-LITE) per ottenere dati sull’usabilità percepita;
15. somministrare inoltre il Net Promoter Score (NPS) per ottenere dati sull’intenzione d’uso;
16. dopo i questionari, chiacchierare con il partecipante, anche ritornando su punti critici ed errori incontrati, per valutare se a posteriori offra indicazioni utili;
17. interrompere la registrazione, salvarla, congedare il partecipante, quindi azzerare la cache del browser, ripuntare il browser alla pagina iniziale e preparare una nuova registrazione. Si precisa che la registrazione può essere interrotta anche prima della somministrazione dei questionari, per ridurre il peso del file, ma può essere utile includere nella registrazione anche l’intervista;
18. per il successivo partecipante, ripartire dal punto 8 e così fino all’ultimo partecipante;
19. al termine di tutte le attività, raccogliere tutti i dati, per ciascun task e per ciascun partecipante nella Tabella dei risultati.

5.1.6.6.3. Fase 3¶

20. Riunire tutti i problemi annotati con tutti i partecipanti in un unico elenco, indicando quali e quanti partecipanti hanno incontrato ciascuno degli specifici problemi;
21. produrre il report riepilogativo, usando il Report dei risultati;
22. discutere in équipe risultati e singoli problemi incontrati, per valutare possibili azioni correttive. Se necessario, approfondire con un esperto.