Docs Italia beta

Documenti pubblici, digitali.

Linee guida di design per i servizi web della Pubblica Amministrazione

Usabilità

Definizione

Per usabilità si intende «il grado in cui un prodotto può essere usato da particolari utenti per raggiungere certi obiettivi con efficacia, efficienza, soddisfazione in uno specifico contesto d’uso» (ISO 9241-210:2010). L’usabilità focalizza la dimensione funzionale dell’interazione tra un sistema (ad es. un sito web) e l’utente, in relazione a precisi obiettivi e contesti d’uso. Non una caratteristica del sistema, ma una proprietà risultante (dall’interazione tra sistema e persona). In questo senso è fondamentale utilizzare un approccio human/user centered per cui la progettazione, del sistema sia guidata dall’analisi e dalla conoscenza articolata dei bisogni, delle caratteristiche degli utilizzatori e dei contesti d’uso. Nella progettazione è necessario pensare a chi utilizzerà realmente il servizio, e il modello di riferimento del progettista deve coincidere con quello dell’effettivo utilizzatore.

User-centered design

Lo user centered design è un insieme di tecniche usate per far emergere i bisogni effettivi delle persone per cui si sta progettando un contenuto, coinvolgendo le persone stesse nel processo di progettazione. Per «persone» si intendono tutti i portatori di interesse (stakeholder) del progetto. Nel caso della pubblica amministrazione:

  • Cittadini
  • Aziende
  • Dipendenti di altre amministrazioni o istituzioni
  • Committenti

I vantaggi dell’usabilità

L’aderenza in fase progettuale e implementativa ai criteri di usabilità consente al cittadino di:

  • esercitare i propri diritti
  • ridurre gli errori e aumentare la soddisfazione di fruizione

Inoltre l’usabilità consente alle PA di:

  • evitare la produzione di servizi inadeguati
  • incentivare i cittadini a ritornare sul sito
  • aumentare la fiducia dei cittadini nei confronti dell’amministrazione

SI DOVREBBE

Data l’importanza che l’usabilità riveste nell’interazione tra utente e applicazione web, è necessario riservare la massima attenzione alla progettazione orientata all’usabilità e alla relativa misurazione, mediante un processo di inclusione degli utenti sin dalla fase di progettazione dei servizi, secondo un modello centrato sulla persona (human-centered).

Criteri di valutazione

Per garantire la fruibilità delle informazioni e contribuire a migliorare l’usabilità dei siti e delle applicazioni, le pubbliche amministrazioni sono tenute a rispettare i criteri qui elencati:

Percezione
Le informazioni e i comandi necessari per l’esecuzione delle attività devono essere sempre disponibili e percettibili.
Comprensibilità
Le informazioni e i comandi necessari per l’esecuzione delle attività devono essere facili da capire e da usare.
Operabilità
Le informazioni e i comandi devono consentire una scelta immediata delle azioni necessarie al raggiungimento dell’obiettivo.
Coerenza
I simboli, i messaggi e le azioni devono avere lo stesso significato in tutto il sito.
Tutela della salute
Il sito deve possedere caratteristiche idonee a salvaguardare il benessere psicofisico dell’utente.
Sicurezza
Il sito deve possedere caratteristiche idonee a fornire transazioni e dati affidabili, gestiti con adeguati livelli di sicurezza.
Trasparenza
Il sito deve comunicare all’utente lo stato, gli effetti delle azioni compiute e le informazioni necessarie per la corretta valutazione delle modifiche effettuate sul sito stesso.
Facilità di apprendimento
Il sito deve possedere caratteristiche di utilizzo di facile e rapido apprendimento.
Aiuto e documentazione
Le funzionalità di aiuto, quali le guide in linea e la documentazione sul funzionamento del sito devono essere di facile reperimento e collegate alle azioni svolte dall’utente.
Tolleranza agli errori
Il sito deve essere configurato in modo da prevenire gli errori; ove questi, comunque, si manifestino, occorre segnalarli chiaramente e indicare le azioni necessarie per porvi rimedio.
Gradevolezza
Il sito deve possedere caratteristiche idonee a favorire e a mantenere l’interesse dell’utente.
Flessibilità
Il sito deve tener conto delle preferenze individuali e dei contesti.

Usabilità come costrutto misurabile

Efficacia, efficienza e soddisfazione dell’utente sono proprietà misurabili e osservabili attraverso questionari, interviste e scale di misurazione, una volta stabilite le tipologie di utenti e gli obiettivi che essi devono raggiungere. Gli standard definiscono come segue i fattori misurabili:

  • l’efficacia: è il grado in cui una persona riesce a completare le operazioni richieste per raggiungere il proprio obiettivo in modo corretto e completo
  • l’efficienza: corrisponde alla quantità di risorse che la persona spende nelle operazioni richieste per raggiungere un dato obiettivo
  • la soddisfazione soggettiva: è la dimensione più complessa da valutare e da raggiungere, poiché riguarda il livello di gratificazione che l’esperienza d’uso offre. Un sistema può funzionare molto bene ma può non bastare a rendere l’interazione confortevole e piacevole. Rientrano in questa dimensione aspetti come l’estetica, la qualità relazionale

La misurazione del livello di usabilità dei siti web dovrebbe essere effettuata a partire dalla fase di prototipazione dell’interfaccia grafica.

Le statistiche d’uso di siti già online forniscono indicazioni utili, seppur parziali, sull’efficacia dei contenuti. È essenziale anche consentire agli utenti di poter inviare facilmente, e in via informale, commenti e opinioni sul sito dell’amministrazione.

Protocollo eGLU LG per la realizzazione di test di usabilità

Quest” opera è distribuita con licenza Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0).

Realizzato dal gruppo di lavoro per la revisione del protocollo eGLU del Gruppo di Lavoro per l’Usabilità (GLU).

Coordinatori del gruppo di lavoro: Simone Borsci, Maurizio Boscarol.

Gruppo di lavoro: Stefano Federici, Jacopo Deyla, Domenico Polimeno, Josè Compagnone, Marco Ranaldo, Maria Laura Mele.

A cura di: Alessandra Cornero.

Il Gruppo di Lavoro per l’Usabilità (GLU) è coordinato da: Emilio Simonetti.

Introduzione alla procedura

Il Protocollo eGLU LG, versione 2018.1, è uno strumento pensato per coloro che lavorano nella gestione dei siti istituzionali e tematici di tutte le pubbliche amministrazioni e che può essere utilmente adottato anche da chi, nelle PA; realizza servizi online, siti web, software.

Questo protocollo ha due obiettivi:

  • descrivere una procedura per incoraggiare il coinvolgimento diretto e l’osservazione di utenti nella valutazione dei siti e dei servizi online. In tal modo si potranno raccogliere evidenze sulle criticità, senza necessariamente far ricorso a risorse esterne. Tali evidenze potranno dar luogo a modifiche immediate delle criticità più evidenti e a investimenti successivi in redesign e valutazioni effettuate tramite esperti.
  • favorire una maggiore attenzione da parte degli operatori pubblici sul tema dell’usabilità, anche in riferimento a disposizioni esistenti (si vedano i criteri di valutazione di cui all’allegato B del Decreto Ministeriale 8 luglio 2005, in attuazione della Legge 9 gennaio 2004, n. 4., criteri illustrati in questa sezione delle Linee Guida.

Poiché nata dalla fusione delle procedure 2.1 (generalista) e M (mobile), la procedura eGLU LG, versione 2018.1, qui delineata è, nelle sue linee generali, indipendente dalla tecnologia e dal mezzo. Ciò significa che è pronta per essere applicata, eventualmente con minimi aggiustamenti, a una varietà di prodotti e servizi su diversi canali distributivi e con diverse tecnologie: siti web informativi, servizi online erogati attraverso tecnologie web, documenti cartacei e modulistica finalizzati alla comprensione e all’utilizzo da parte di un ampio pubblico, applicazioni multipiattaforma (applicazioni software che possono essere usate in un ambiente web-based da desktop e da tablet, o in concorso con un’apposita App), App specifiche per tablet o smartphone.

La procedura eGLU, di seguito descritta, per brevità fa più spesso riferimento ai siti. Ma può allo stesso modo essere adattata alla più ampia varietà di dispositivi, situazioni, canali e materiali.

La procedura di osservazione degli utenti si svolge con le seguenti modalità:

  • il conduttore dell’osservazione stila dei compiti da sottoporre ad alcuni partecipanti. I compiti, chiamati task dagli esperti, possono riguardare, per esempio, la ricerca di specifiche informazioni, la compilazione di moduli online, lo scaricamento di documenti;
  • alcuni utenti vengono selezionati e invitati a partecipare;
  • si chiede a ciascun utente di eseguire i task assegnati. Durante l’osservazione non si pongono domande dirette, ma si osservano le persone interagire col sito e le eventuali difficoltà che incontrano. I task possono essere eseguiti con successo o meno. Al termine dell’esecuzione si usano dei questionari per raccogliere informazioni sul gradimento e sulla facilità d’uso percepita;
  • sulla base dei dati raccolti si può avere un’idea dei punti di forza del sito e delle sue criticità. Questo consente di apportare da subito modifiche in base ai problemi riscontrati, di approfondire le criticità con test avanzati condotti da esperti o di confrontare fra loro le criticità di versioni successive del medesimo prodotto.

La procedura contempla l’uso di 9 allegati, disponibili nel Kit Usability Test.

L’intera procedura, se condotta correttamente, può essere considerata un test minimo di usabilità, benché semplificato e di primo livello (esplorativo), e può essere svolta anche da non esperti.

Per raccogliere e analizzare dati in modo più approfondito o per svolgere test con obiettivi più complessi è opportuno, nonché necessario, rivolgersi a un esperto di usabilità.

Il protocollo eGLU LG, versione 2018.1, serve così anche a dare al personale delle PA una visione più realistica dei problemi di interazione presenti in un sito web o in un servizio online. Tale consapevolezza, fondata su una cultura centrata sull’utente, è il perno principale utile a riferire poi, a chi deve decidere del redesign, dove e come dovranno operare gli esperti.

Le fasi della procedura

Di seguito vengono descritte le diverse fasi nelle quali si articola la procedura:

  1. Preparazione;
  2. Esecuzione;
  3. Analisi dei risultati.

1. Preparazione

Questa fase prevede i seguenti aspetti:

  • analisi preliminari del sito e dei destinatari;
  • quanti utenti selezionare;
  • quali tipologie di utenti scegliere;
  • quali e quanti task preparare;
  • come preparare i moduli per la raccolta dati;
  • cosa fare prima dell’osservazione: il test pilota;
  • prendere appuntamento con i partecipanti.

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.

Analisi tramite strumenti online per il mobile

Un buon punto di partenza è condurre un’analisi attenta di come il sito si modifica in base ai diversi dispositivi. Per fare questo è possibile utilizzare un insieme di strumenti disponibili online che vi permettono di vedere come il sito sarà visualizzato tramite diversi dispositivi e di fare una valutazione preliminare di cosa funziona e cosa può essere migliorato dal punto di vista del codice di programmazione.

Strumenti di supporto validi per quest’analisi preliminare sono:

  • Mobiletester.it: permette la simulazione su telefoni e tablet ed anche un test minimo di quanto la versione mobile sia funzionale;

  • Developers tools di Google:

    • Mobile-Friendly Test di Google: offre un veloce test che certifica che la versione mobile del sito è rilevabile online;
    • PageSpeed Insights: offre un test abbastanza dettagliato con una valutazione da 0 a 100 della velocità del sito mobile (Speed) e della esperienza utente (UX) garantita dal sito in termini strutturali;
    • Google Chrome, inoltre, offre un set di strumenti per emulare sul proprio computer l’utilizzo di un dispositivo mobile;
  • Firefox offre una versione del proprio browser per lo sviluppo, anch’essa dotata di molti strumenti per simulazione e testing;

  • Anche il W3C offre un validatore con molti test utili.

Dopo essersi accertati che l’interfaccia mobile del sito risponda adeguatamente ai diversi dispositivi e aver risolto eventuali problemi individuati tramite i vari strumenti, occorre assicurarsi che l’interfaccia mobile funzioni adeguatamente, cioè che le funzioni progettate (bottoni, link, form, ecc.) siano eseguibili da mobile (dispositivi mobili) e che l’architettura dell’informazione del sito mobile sia adeguata.

Analisi ispettive da svolgersi prima del test con metodologia eGLU

I test di usabilità, come quello della procedura eGLU, si applicano a una grande varietà di situazioni e di progetti, e in momenti diversi del ciclo di progetto. Alcuni progetti con elevata complessità di programmazione e molte funzionalità, possono soffrire di alcuni bug in certi momenti del ciclo di sviluppo. Per questo genere di progetti è spesso consigliabile svolgere, prima del test, un’analisi preliminare secondo varie possibili modalità, ma che comprenda almeno una prova passo passo dei task prima di sottoporli ai partecipanti.

L’analisi ha dei precisi vantaggi:

  • si identificano errori di funzionamento che potrebbero rendere impossibile l’esecuzione del test con i partecipanti e si può passare alla loro immediata risoluzione;
  • si evita di far perdere tempo ai partecipanti per scoprire bug e problemi funzionali che possono essere identificati con metodologie di ispezione svolte prima del coinvolgimento degli utenti. Questo consente di utilizzare il test per identificare problemi di usabilità e di interazione, anziché funzionali;
  • consente di adattare i task ai limiti di funzionamento che il prodotto ha in quel determinato momento; per esempio, se sappiamo che una procedura non esegue un controllo di congruità sui dati inseriti dall’utente, possiamo tenerne conto sia nel task che durante l’esecuzione.
Analytics per l’analisi dell’audience

Un ultimo tipo di analisi che può essere effettuata è quella degli Analytics. Questa analisi può darci informazioni importanti sulle modalità di fruizione degli utenti, sulle sezioni più navigate, sulle eventuali criticità del sito, sulle chiavi di ricerca utilizzate più spesso. Per approfondimenti si rimanda al capitolo sui Web Analytics delle Linee Guida.

Quanti e quali tipologie di partecipanti selezionare

Quanti partecipanti

Con 5 partecipanti appartenenti alla stessa tipologia di utenti, è possibile far emergere circa l’85% dei problemi più frequenti di un sito, per quella tipologia di utenti. In particolare, i problemi che si presentano con una frequenza almeno del 31%. Aumentando il numero dei partecipanti, la percentuale di problemi con quella frequenza si incrementa di poco, perché ogni nuovo partecipante identifica sempre più problemi già incontrati dai partecipanti precedenti.

Si consideri però che l’aggiunta di nuovi partecipanti aumenta la probabilità di rilevare problemi con frequenza inferiore, il che in certe situazioni può essere desiderabile o addirittura importante. Un problema poco frequente non è necessariamente poco grave, se è in grado di invalidare l’esecuzione di alcuni compiti cruciali in alcune situazioni particolari. Si valuti dunque, caso per caso, in base all’importanza di identificare:

  1. una quota più alta, rispetto al teorico 85%, di problemi frequenti;
  2. un certo numero di problemi più rari.
Quali tipologie di partecipanti

Oltre al numero, è bene preoccuparsi della tipologia di partecipanti da invitare. È importante che questi siano rappresentativi del bacino di utenza del sito.

Se il nostro bacino di utenti ha conoscenze o caratteristiche differenziate (ad esempio, se ci rivolgiamo in parte ad un pubblico indistinto di cittadini, ma in parte anche ad uno specifico settore professionale, come consulenti del lavoro, o commercialisti, o avvocati, ecc.), sarà bene rappresentare, nel nostro piccolo campione di partecipanti, queste diverse categorie. Così, il nostro gruppo potrebbe essere composto, ad esempio, da tre partecipanti che rappresentino il pubblico più ampio e tre che rappresentino i consulenti del lavoro.

Più è differenziato il nostro bacino di utenza, più difficile sarà rappresentare in un piccolo campione tutte le tipologie di utenti. In tal caso possiamo condurre l’osservazione con la consapevolezza che i risultati non possono coprire tutti i possibili usi del sito e rimandare ad un’osservazione successiva eventuali verifiche sulle tipologie di utenti che non siamo riusciti ad includere nel nostro campione.

In sintesi:

  1. Se ci si rivolge a una sola tipologia di utenti, è consigliato avere almeno 5 partecipanti;
  2. Se ci si rivolge a più tipologie di utenti, è utile avere almeno 3-5 partecipanti in rappresentanza di ciascuna tipologia;
  3. Se tuttavia il reperimento di partecipanti appartenenti a tutte le tipologie non è possibile o non è economico, si terrà conto di questa impossibilità nella valutazione dei risultati (che evidenzieranno quindi solo i problemi comuni alle tipologie di utenti che sono state rappresentate) e ci si limiterà ad un numero maneggevole di utenti, comunque complessivamente non inferiore a 5.
Controlli preliminari sui partecipanti

Oltre alle caratteristiche del bacino d’utenza del sito, è bene accertarsi che gli utenti invitati abbiano capacità e abitudine ad utilizzare il computer e a navigare in internet. Nella Scheda Partecipanti è presente un questionario da somministrare in fase di selezione o comunque prima di iniziare il test, utile per scegliere i possibili partecipanti. Se dalle risposte si evidenziano differenze tra un certo utente e gli altri, è bene scartare quell’utente e sostituirlo con un altro che abbia lo stesso livello di competenze di base della maggioranza, e che appartenga al medesimo bacino d’utenza.

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.

Tipologie di task

Per ciascuna delle tipologie di attività che è possibile svolgere sul sito, è bene scegliere almeno uno o due task tra le seguenti tipologie:

  • trovare informazioni online;
  • scaricare e/o consultare documenti (diversi da contenuti html) disponibili per il download;
  • compilare moduli online.

I task possono riguardare anche altro, ad esempio l’uso del motore di ricerca, i pagamenti online, o l’iscrizione ad aree riservate, se presenti.

Uso del motore di ricerca interno

Se si è consapevoli del fatto che il motore non funziona adeguatamente, si può decidere di non consentire il suo utilizzo, oppure, al contrario, di farlo utilizzare per poterne avere o meno conferma. Se, invece, la maggior parte dei partecipanti ricorre sistematicamente alla ricerca tramite motore, si può eventualmente chiedere loro durante il test e dopo l’uso del motore di provare a raggiungere gli obiettivi proposti navigando nel sito. In ogni caso, non è da ammettere mai la ricerca tramite motori esterni al sito (per es. Google).

Criteri di successo per i task

Durante l’osservazione dei partecipanti bisogna essere sicuri di poter capire se un task è stato completato o fallito. Per far ciò, oltre a individuare, studiare e simulare bene il task, prima del test, è importante:

  • stilare un elenco degli indirizzi URL di ciascuna pagina del sito che consente di trovare le informazioni richieste;
  • identificare la pagina di destinazione di una procedura di registrazione/acquisto/ iscrizione/scaricamento. A volte i partecipanti possono trovare le informazioni anche in parti del sito che non erano state considerate, oppure seguendo percorsi di navigazione intricati o poco logici: bisognerà decidere prima, in tal caso, se il compito vada considerato superato. Specularmente, a volte gli utenti sono convinti di aver trovato l’informazione anche se non è quella corretta. In questo caso è importante indicare con chiarezza che il compito è fallito;
  • definire il tempo massimo entro il quale il compito si considera superato. Molti utenti infatti possono continuare a cercare l’informazione anche oltre un ragionevole tempo, per timore di far brutta figura. Questi casi vanno presi in considerazione: non è sempre possibile interrompere gli utenti per non creare loro l’impressione che non siano stati capaci di trovare l’informazione, dunque, è spesso consigliato lasciarli terminare. Tuttavia, se superano un certo limite temporale, anche qualora trovino le informazioni, il compito va considerato fallito. Un tempo congruo, per la maggior parte dei task, è da considerarsi dai 3 ai 5 minuti. Il tempo esatto va considerato sia in relazione alla complessità del compito stesso, che al tempo stimato durante la prova preliminare;
  • definire il numero di tentativi massimi entro il quale il compito si considera fallito. 3 o 4 tentativi falliti sono spesso sufficienti a definire il compito come fallito, anche se, proseguendo, l’utente alla fine lo supera.

Il focus del test è capire i problemi: task che richiedono molto tempo o molti tentativi per essere superati, segnalano un problema ed è dunque giusto considerarli dei fallimenti.

Si veda come esempio la Guida alla Conduzione del test.

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

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 (almeno due, 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 qui. Non è necessario che l’aspetto del sito sia identico sui diversi dispositivi; va tuttavia garantita un’esperienza utente equivalente.

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.

2. Esecuzione

Una volta effettuati i passi preparatori per una corretta osservazione, si passa alla fase di esecuzione vera e propria. Tale fase richiede:

  • la preparazione di un ambiente idoneo;
  • la corretta interazione con i partecipanti e conduzione dell’osservazione;
  • la raccolta dei dati;
  • il congedo dei partecipanti al termine del test.

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.

Ambiente strutturato (desktop e mobile)

L’ambiente strutturato è ottimale per lo svolgimento di un’approfondita analisi esplorativa, poiché l’accesso può essere controllato dal conduttore e garantire che l’analisi non sia interrotta da eventi esterni. La strutturazione dell’ambiente è consigliabile quando c’è la necessità di valutare prodotti in fase di sviluppo o di riprogettazione.

Al fine di procedere al test è necessario:

  • un tavolo su cui l’utente possa utilizzare un dispositivo mobile con connessione a Internet (smartphone o tablet) o il computer desktop con cui navigare il sito web;
  • una sedia per il partecipante e una per il conduttore, che sarà seduto di lato, in posizione leggermente arretrata;
  • cancellare la cronologia del browser prima e dopo ciascun test, per evitare che i link già visitati possano costituire un suggerimento.

Al fine di procedere al test inoltre e soprattutto nel caso di test complessi, è consigliabile, benché non sempre indispensabile, utilizzare strumenti di videoregistrazione poiché consentono di verificare, in un momento successivo, l’effettivo andamento della navigazione e l’interazione dell’utente con l’interfaccia.

Strumenti gratuiti utili per la registrazione desktop possono essere:

  • la funzione “registra schermo” offerta da Apple Quick Time in ambiente Macintosh, per la registrazione dello schermo e del partecipante tramite webcam;
  • Screencast-O-Matic (per Windows, Macintosh e Linux).

Esistono, inoltre, vari software che permettono di registrare le sessioni direttamente su dispositivi mobile. Tali software permettono di registrare sia la sessione d’utilizzo che in taluni casi, attraverso la camera frontale del device, anche il volto della persona. Essendo i dispositivi molto vari consigliamo di effettuare una ricerca sui relativi app store per cercare le soluzioni migliori negli specifici casi.

Registrando le azioni e gli eventuali commenti del partecipante è necessario che questo firmi una liberatoria sulla privacy e sul consenso all’utilizzo dei dati (Liberatoria). In mancanza di sistemi di registrazione, si consiglia al conduttore di effettuare il test insieme a un assistente che, in qualità di osservatore, possa impegnarsi nella compilazione delle schede e riscontrare l’andamento delle prove. Anche in caso di registrazione, l’eventuale assistente annoterà comunque l’andamento delle prove, per mettere a confronto in seguito le sue annotazioni con quelle del conduttore.

Ambiente non strutturato (solo mobile)

La valutazione in un contesto non strutturato è consigliabile quando il prodotto da valutare è in fase avanzata di sviluppo o è già online. Questo tipo di valutazione permette di raccogliere velocemente l’opinione degli utenti sul prodotto, tramite NPS (Net Promoter Score ), e tramite un questionario breve di usabilità UMUX o UMUX-LITE (Domande UMUX Lite ).

L’obiettivo è osservare le reazioni, le modalità di interazioni con un prodotto, i comportamenti e le reazioni ai problemi degli utenti in un contesto di vita quotidiana. Si tratta di una valutazione in cui il conduttore ha poco o scarso controllo dell’ambiente. E’ quindi molto più agevole dal punto di vista organizzativo, ma i dati raccolti sono di solito minimali e non generalizzabili.

Per fare un esempio di test in ambiente non strutturato: il conduttore può portare un partecipante in un luogo pubblico e chiedergli di svolgere, seduti a un tavolino e con il proprio smartphone (o con uno messo a disposizione dal conduttore), da uno fino a un massimo di tre task. Il conduttore si siede accanto all’utente chiedendogli di svolgere i task e informandolo che, nell’eventualità lui riscontrasse dei problemi, sarà disposto a discuterne con lui ed eventualmente ad aiutarlo per risolverli. Terminati i task, il conduttore somministra i questionari e congeda l’utente. Il conduttore quindi riporta su un foglio, da allegare ai questionari compilati dall’utente, una breve descrizione delle problematiche più importanti che ha avuto l’utente nell’interazione nonché gli eventuali suggerimenti proposti dall’utente per migliorare l’interfaccia.

Interazione con i partecipanti e conduzione del test

Accoglienza

Al momento dell’arrivo, il partecipante viene accolto e fatto accomodare alla sua postazione nella stanza predisposta.

Prima di avviare il test, è necessario instaurare un’atmosfera amichevole, rilassata e informale; il test deve essere condotto in modo da minimizzare l’effetto inquisitorio che il partecipante potrebbe percepire.

Al partecipante deve essere spiegato chiaramente che può interrompere la sessione di test in qualsiasi momento. Se per il disturbo è previsto di offrire un gadget, va consegnato in questo momento, spiegando che è un segno di ringraziamento per il tempo messo a disposizione.

Istruzioni

Il conduttore chiarisce al partecipante che la sua opinione è importante per migliorare il servizio e che verrà tenuta in grande considerazione; gli spiega cosa fare e come farlo. A tal fine il conduttore può utilizzare come traccia il testo presente nella Scheda Partecipanti. È fondamentale insistere sul fatto che non è il partecipante ad essere sottoposto a test, ma lo è l’interfaccia e che gli errori sono per il conduttore più interessanti dei task portati a termine con successo.

In questa fase, se l’uso del motore di ricerca interno è stato escluso dal piano di test, il conduttore chiarisce che non è possibile utilizzarlo. Inoltre, informa che non si possono utilizzare motori di ricerca esterni per trovare informazioni sul sito, né uscire dal sito per rivolgersi a siti esterni.

Il conduttore, applicando il protocollo del Thinking Aloud (o TA, pensare ad alta voce) chiede ai partecipanti, man mano che questi eseguono i task, di esprimere a voce alta dubbi e problematiche legate alle azioni necessarie per raggiungere lo scopo. L’obiettivo è quello di indurre il partecipante a verbalizzare le difficoltà dovute all’interfaccia, offrendo così al conduttore di raccogliere informazioni rispetto ad eventuali problematiche d’uso del prodotto. In questo modo è più facile capire quali parti di un’interfaccia o di un processo d’uso generino problemi, dubbi e fraintendimenti. Il conduttore dovrà evitare domande dirette che possono guidare il partecipante al raggiungimento dei loro obiettivi, oltre che astenersi da esprimere sorpresa, delusione o gioia per i comportamenti del partecipante, in modo da non influenzarne aspettative e comportamenti. L’indicazione di pensare a voce alta va fornita prima dell’esecuzione dei task ed eventualmente ripetuta un paio di volte, se il partecipante se ne dimenticasse. Se il partecipante avesse difficoltà a pensare a voce alta, è bene non insistere nell’incoraggiamento diretto e porre domande per incoraggiarlo a verbalizzare, per esempio: “Stai avendo delle difficoltà di cui vuoi parlarci?”.

Nei prossimi mesi pubblicheremo un approfondimento su come comportarsi durante i test.

Avvio del test

A questo punto viene letto il primo task, si avvia la registrazione e si inizia l’osservazione del partecipante mentre esegue il compito. Si continua, poi, leggendo via via i task successivi.

È importante ricordarsi di non far trasparire soddisfazione o frustrazione in seguito a successi o fallimenti del partecipante. La reazione del conduttore dovrebbe essere naturale e non trasmettere segnali che facciano capire se il compito è fallito o superato.

Relazionarsi con i partecipanti durante il test

Se un partecipante commette un qualsiasi errore questo non deve mai essere attribuito a lui, ma sempre a un problema del sistema. Occorre quindi fare attenzione a non dire mai al partecipante che ha sbagliato, ma piuttosto utilizzare frasi come: “l’interfaccia non è chiara”, “l’obiettivo è nascosto”, “il percorso da fare è confuso”.

Durante il test il conduttore deve saper gestire la propria presenza in modo da non disturbare il partecipante e, allo stesso tempo, deve alleggerire la tensione di silenzi prolungati, intervenendo se nota che il partecipante si blocca troppo a lungo, ad esempio oltre qualche minuto.

Nota: se il partecipante spende più di due minuti per cercare un’informazione che un buon conoscitore del sito raggiunge in pochi secondi, allora, solo in questo caso, il conduttore può chiedere al partecipante: “Come sta andando la tua ricerca?” oppure “Pensi che sia possibile raggiungere questo obiettivo?” o anche “Ricorda che devi essere tu a decidere e che non c’è un modo giusto o sbagliato: se per te non si può raggiungere l’obiettivo, basta che tu me lo dica”. Inoltre, è possibile congedare, ringraziandolo, un partecipante che è chiaramente annoiato o nervoso, senza però far trasparire l’idea che il partecipante stesso non abbia adeguatamente risposto alle nostre aspettative.

Nei prossimi mesi pubblicheremo un approfondimento su come comportarsi con i partecipanti durante i test.

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.

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

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.

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.

3. Analisi dei risultati

In questa sezione si spiega come riassumere i dati raccolti e stilare un report.

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:

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

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.

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.

Check-list di riepilogo per l’organizzazione del test

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.

Fase 2

  1. Ricevere uno a uno i partecipanti, somministrando i task, mentre un assistente si occupa della registrazione;
  2. interagire con i partecipanti, influenzandoli il meno possibile;
  3. annotare i task riusciti e quelli falliti;
  4. annotare ogni problema, apparentemente incontrato dal partecipante, che si riesca a identificare;
  5. 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;
  6. somministrare inoltre il Net Promoter Score (NPS) per ottenere dati sull’intenzione d’uso;
  7. dopo i questionari, chiacchierare con il partecipante, anche ritornando su punti critici ed errori incontrati, per valutare se a posteriori offra indicazioni utili;
  8. 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;
  9. per il successivo partecipante, ripartire dal punto 8 e così fino all’ultimo partecipante;
  10. al termine di tutte le attività, raccogliere tutti i dati, per ciascun task e per ciascun partecipante nella Tabella dei risultati.

Fase 3

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