Usabilità, replicabilità e tasso di identificazione delle problematiche
Il lato quantitativo dei test con utenti.
L’usabilità a quattro dimensioni
Una comune definizione di usabilità esiste ed è chiaramente stabilita dalla ISO 9241–11 [1]. Questa definizione è l’ombrella comune sotto cui ci si ripara quando si vogliono misurare gli aspetti centrali dell’interazione. Tuttavia spesso c’è confusione anche fra gli esperti perché esistono diversi standard internazionali che parlano di usabilità facendo riferimento, apparentemente, a diversi aspetti da misurare per valutare l’usabilità. In realtà, in un recente articolo [2] ho identificato insieme a dei colleghi circa 54 standard che definiscono per differenti tipologie di prodotti le dimensioni della valutazione di usabilità. Tuttavia, tutti questi standard sono variazioni della ISO 9241–11 in un contesto specifico di interazione. Ovvero l’usabilità è flessibile e la definizione di usabilità si può allargare o restringere a seconda dei contesti applicativi. Per fare un esempio la ISO 25010 [3] riguardante l’usabilità dei software. Tuttavia questa non è una differente definizione di usabilità, ma una specifica della definizione di usabilità che allarga le dimensioni [per maggiori informazioni: 2] introducendo dimensioni come la facilità di apprendimento.
L’usabilità, secondo la definizione ISO 9241–11[1] deve essere misurata cercando di catturare tre dimensioni principali: efficacia, efficienza e soddisfazione d’uso. Io in realtà aggiungo sempre, seguendo proprio la ISO 9241–11 recentemente aggiornata, una quarta dimensione che per definizione dovrebbe essere riportata almeno descrittivamente in ogni valutazione di usabilità, ma che spesso viene minimizzata proprio perché complessa. Questa quarta dimensione è il contesto d’uso.
Il contesto d’uso è importante per due motivi:
1. Perché a seconda del contesto in cui un prodotto verrà utilizzato potrebbe essere necessario fare riferimento ad un standard specifico che potrebbe richiedere di misurare anche altri aspetti oltre a quelli di efficacia, efficienza e soddisfazione. Se parliamo, per esempio, di prodotti medici lo standard fondamentale è la ISO 62366 [4] che richiede oltre alla misurazione degli aspetti indicati nella ISO 9241–11 anche una complessa analisi dei fattori residuali di rischio descritti nella ISO 14971 [5].
2. Perché il contesto d’uso è un aspetto centrale per spiegare i risultai della valutazione. Mappare e saper descrive il contesto d’uso significa anche saper descrivere tutti quegli aspetti specifici del prodotto e le conseguenti scelte metodologiche, in modo da poter descrivere nel report perché si sono scelti certi metodi di valutazione invece di altri, quali sono i limiti di questi metodi, e perché sono stati coinvolti certi tipi di utenti (età, competenze ecc.) con quale tipo di strumenti si sono effettuati i test, con quali scenari e molto altro ancora. Tutto questo permette quindi di rendere trasparente e replicabile un test.
Sebbene il contesto d’uso non debba essere misurato durante il test ma descritto ed analizzato, questa analisi è parte integrate di un test di usabilità. La formalizzazione del contesto d’uso richiede sia di conoscere il prodotto sia una esplorazione, o mappatura, di dove il nuovo prodotto o servizio verrà utilizzato, per esempio attraverso l’analisi di come prodotti simili vengono usati dagli utenti nella quotidianità. Troppo spesso si preferisce evitare di essere troppo formali nella creazione dei test e nel report di usabilità soprattutto quando le eventuali conseguenze di un errore di usabilità sono accettabili. Infatti le potenziali conseguenze di un errore di usabilità sono differenti per diversi prodotti da valutare, per esempio un errore in un prodotto medico ha maggiore probabilità di creare conseguenze catastrofiche di un errore in un sito web. Tuttavia queste differenze nelle conseguenze per gli utenti non dovrebbero essere intese come la possibilità di essere meno formali in test di prodotti a basso rischio per gli utenti.
Riuscire a comprendere che la formalizzazione del contesto non è opzionale ma un punto centrale di una buona valutazione di usabilità risulta spesso contro intuitivo, eppure le conseguenze di errori nella formalizzazione del contesto non sono banali.
Per esempio possiamo parlare di un contesto d’uso poco formalizzato:
1. Quando un prodotto che vuole essere per un ampio pubblico, come un’applicazione per i cittadini fatta da una pubblica amministrazione, viene testato con un campione piccolo ed omogeneo di utenti (quelli più facili da reperire) in cui non sono state incluse, per esempio, persone con disabilità. Questo non significa che il test effettuato non sia valido, solo che i risultati del test non copriranno tutti i possibili aspetti problematici che potrebbero emergere effettuando test su una più larga base di possibili utenti. Non riportare questi limiti nel report è un errore che potrebbe indurre qualcuno a pensare che quel prodotto sia più usabile di quello che è in realtà.
2. Quando un prodotto viene testato con compiti e scenari selezionati non per testare funzioni rappresentative e centrali di un servizio o prodotto, ma quelle più ‘convenienti’ per svolgere velocemente un test. In questo modo certamente si troveranno pochi problemi di usabilità ma questo non significa che gli utenti finali non avranno problemi di interazione.
Escludendo i casi, purtroppo non rari, in cui un test di usabilità sia inficiato da errori metodologici e di misurazione, in generale, il rischio maggiore nell’errata definizione del contesto d’uso è il cercare di testare l’uso immaginato e non l’uso reale di un prodotto o servizio [6].
Quando per diversi motivi non si è fatto quel fondamentale lavoro che è proprio della user research per comprendere come i possibili soggetti coinvolti nell’uso di un prodotto o di un servizio (stakeholders) solitamente utilizzano i prodotti nella loro quotidianità, in modo da inglobare questo sapere nella selezione dei partecipanti, nella creazione degli scenari e di task realistici per il test. Quella fra stakeholders ed utenti è una differenza fondamentale. Ovviamente l’utente ha un ruolo centrale nei test, tuttavia nel suo contesto quotidiano l’utente spesso non è solo, e diverse variabili e processi paralleli possono inficiare la sua interazione con un prodotto. Riuscire a mappare il contesto d’uso significa anche conoscere tutti i possibili attori e processi che gravitano attorno ad un prodotto o servizio per creare scenari d’uso e task per i test ma anche per anticipare con soluzioni di design le problematiche d’uso. Alcune volte, purtroppo, si preferisce testare un servizio solo con quelli che si considerano gli utenti principali, assumendo che il servizio verrà utilizzato così come lo ha pensato il designer.
Per intenderci:
<<in circa quindici anni di esperienza come user researcher ed esperto di interazione in progetti con aziende ed università testando prodotti e servizi per web e mobile, automotive, e prodotti medico-diagnostici a me non è mai capitato di vedere l’utente tipo, o che qualcuno utilizzasse un prodotto esattamente in linea con le aspettative dei designers (uso immaginato), o che gli utenti non trovassero modi alternativi per raggiungere gli obiettivi di un test o fantasiosi per fallirli (uso reale).>>
Più spesso di quanto si pensi, in un test di usabilità cose che per i progettisti sono ovvie e scontate, possono diventare barriere insormontabili per i partecipanti del test, e cose che per i progettisti sono ritenute da migliorare o potenzialmente problematiche non presentano problemi per i possibili utenti. Infatti, in un test di usabilità gli utenti riescono spesso a pensare fuori dagli schemi portando un enorme valore aggiunto al design. Per questo in un libro di alcuni anni fa scritto insieme a colleghi ed amici [7] sostenevamo che mentre Krug dice che l’utente non vuole pensare durante utilizzo di un prodotto, ed è compito del designer quello di riuscire a non farlo pensare, il compito di un valutatore dell’usabilità è esattamente l’opposto, cioè quello di creare le condizioni per far pensare l’utente il più possibile liberamente entro una cornice delineata, controllabile e replicabile.
Troppo spesso nei report di usabilità la definizione del contesto d’uso manca o è molto limitata. E questo è uno, se non il maggiore, dei problemi dell’usabilità, sia in campo scientifico che industriale. Non di rado, leggendo un report di usabilità mancano quegli aspetti metodologici che permettono di capire come siano stati effettuati i test, di comprenderne l’affidabilità e di capire come i dati sono stati analizzati. Intendiamoci, ognuno ha la possibilità nel quadro teorico dell’usabilità di adattare la valutazione alle esigenze del prodotto o servizio che deve valutare, ma questo adattamento deve essere spiegato e dettagliato in termini di contesto d’uso in modo che le scelte metodologiche e i limiti della valutazione siano chiari e riproducibili [2], altrimenti non state facendo test di usabilità ma analisi quali-quantitative dell’interazione, utilissimi ad informare il design e ad adattarlo alle esigenze di mercato, ma non ad evitare che quel prodotto una volta immesso nel mercato crei problemi agli utenti.
Usabilità replicabile e comparabile: il ruolo del valutatore
<<Se state pensando che sia alquanto improbabile che qualche cliente legga, utilizzi o sia interessato al metodo più che al risultato, avete ragione ed è proprio questo l’enorme elefante invisibile su cui bisognerebbe puntare il dito>>
Una grossa porzione delle scienze (non solo sociali) si trova, e si troverà sempre di più, immerso in quello che a livello mondiale è noto come la crisi della replicabilità [8]. Uno tsunami di cui si parla poco, ma che investe dal punto di vista dell’usabilità anche una gran parte dell’industria odierna. Spesso le aziende che hanno l’esigenza di certificare come usabile un prodotto tendono a farlo in modo autoreferenziale, riportando i risultati senza mettere a disposizione o rendere noto le modalità con cui quei risultati sono stati ottenuti. Peggio ancora, le informazioni che permetterebbero di replicare e comparare risultati spesso mancano anche quando si tenta di fare analisi retrospettive sull’usabilità usando studi scientifici pubblicati. Intendiamoci, questo problema è trasversale a molte comunità, ma la cosa positiva è che nell’usabilità se pur (per ora) solo in ambito scientifico è un problema che si sta affrontando e su cui si discute.
Spesso si ha come l’impressione che nel campo dell’analisi dell’interazione la necessità di produrre il risultato sia anteposta al come quel risultato sia stato raggiunto, mentre il come nel campo dell’usabilità è forse anche più importante del risultato. Per esempio riportare che un prodotto è ritenuto usabile da un gruppo di utenti durante un focus group non è la stessa cosa di averlo testato con quegli utenti. Questo non significa che fare un focus group non permetta di avere informazioni rilevanti per il miglioramento di un prodotto o di un servizio, solo che questa è analisi dell’interazione, non è un test di usabilità. Così come una valutazione euristica fatta da esperti è, e sarà, sempre utile ma è una analisi esperta dell’usabilità, non un test di usabilità. La differenza fondamentale per esempio fra una valutazione euristica, o eseguita tramite un cognitive walkthrough, è quella di individuare problemi potenziali e di permettere di migliorare il prodotto prima del coinvolgimento degli utenti. Tuttavia, la capacità di pensare al di fuori degli schemi degli utenti e il numero di informazioni quantitative e qualitative che si riescono ad ottenere durante un test di usabilità ben organizzato offre un contributo al design del prodotto di molto superiore a qualsiasi analisi esperta. E’ per questo che quasi sempre invito i designer, spesso obbligo, ad osservare i test magari dandogli anche un ruolo soprattutto durante la discussione alla fine del test.
Certo non sempre è conveniente o necessario fare un test di usabilità formale, questo dipende dalle fasi di sviluppo e dagli obiettivi. In alcuni casi approcci più qualitativi tesi a raccogliere dati sull’interazione ed a migliorare il prodotto in modo più informale possono essere modi efficaci per raccogliere quelle informazioni necessarie a comporre il contesto d’uso che poi verrà formalizzato in test d’usabilità successivi. In questo senso, un altro aspetto fondamentale, che ancora non è pienamente entrato nella coscienza di tutte le comunità che gravitano attorno al modo dell’interazione è che l’usabilità sia un processo integrato e parallelo al design, alla user reasearch, all’accessibilità e alla UX dentro una prospettiva sistemica. Questo processo inizia dal momento in cui si parte a concettualizzare l’idea di un servizio e di un prodotto, e si concretizza nell’esecuzione e restituzione dei test.
<<Testare un prodotto con utenti per un valutatore significa assumersi la responsabilità etica di incidere sul design in base ad evidenze empiriche che devono essere replicabili. Ecco perché la replicabilità tramite una chiara, trasparente e dettagliata descrizione del contesto d’uso è importante indipendentemente dal prodotto o servizio che si sta testando.>>
Come dicevamo sopra, è differente testare l’usabilità (differenti standards) di una radiosveglia da quella di un robot per operazioni chirurgiche, tuttavia in entrambi i casi un valutatore ha l’obbligo di utilizzare ciò che è stato fatto prima in termini di design, ricerca su gli utenti, scenari ed analisi del contento invece di piegarlo alla propria convenienza o a quella altrui. In questo senso indipendentemente dalla tipologia prodotto o servizio e della conseguenze per gli utenti di un errore di usabilità il team di valutazione deve essere in grado, in qualsiasi momento, di chiarire, per esempio, il perché si è scelto di eseguire certi task o non altri nel test, oppure perché il test viene eseguito in un certo modo e con certi strumenti, o perché si utilizzi un protocollo verbale concorrente o retrospettivo, o perché si sceglie di misurare certi fattori come lo stress o il sovraccarico cognitivo ecc. Dettagliare le scelte effettuate significa definire le procedure ed i limiti di quanto il test sia rappresentativo del contesto in cui il prodotto verrà inserito, oltre a permettere a chiunque di poter ripetere quel test alle stesse o simili condizioni.
Rendere replicabile il contesto d’uso di un test di usabilità non ha un costo, se non il tempo di formalizzare un documento ed un processo.
Utilizzare un approccio di lavoro formale indipendentemente dalla tipologia di prodotto, imparando a rendere sempre esplicito il contesto e con esso la metodologia, il campionamento, la validità e i limiti dei propri risultati permette ad un valutatore di crearsi uno schema di lavoro (un template) che lo aiuta ad impostare velocemente il lavoro di valutazione indipendentemente dal prodotto ed di poter già visualizzare il report finale. Certo questo lavoro all’inizio richiede un po’ di tempo ma permette di ridurre il rischio errori metodologici. Certamente dovendo esplicitare metodologicamente perché si è scelto, per esempio, di usare un eye-tracker [9] per testare i movimenti oculari durante l’utilizzo di una radiosveglia diventa più difficile essere convincenti e dimostrare ad un cliente che non si è fatta una scelta impropria magari per aumentare il budget. Offrire risultati replicabili e comparabili, così come scegliere metodologie adeguate, deve essere un imperativo morale ed etico di un valutatore, se non si vuole perdere la fiducia dei propri clienti.
Il valutatore, anche quando lavora per la stessa organizzazione del designer, deve cercare di essere il più formale possibile perché la sua deve essere una prospettiva esterna (imparziale, se possibile) al progetto di design in modo da poter ottenere risultati attendibili. Il valutatore deve stressare e porre sotto pressione il prodotto, un po’ come si fa a livello software, sebbene lo si faccia a livello metodologico in modo da vedere se il servizio o prodotto risulti resiliente. Contemporaneamente al ruolo del valutatore, tuttavia è fondamentale che anche designers e produttori comprendano l’importanza della replicabilità e del ruolo del valutatore. Anzi, dovrebbero essere questi i primi a chiedere al valutatore di creare una documentazione trasparente relativa al contesto d’uso in fase di report, in modo da poter comprendere i limiti e le specificità, che sempre ci sono, in un test di usabilità e per poter meglio informare le decisioni strategiche sul come avanzare il lavoro di design e di re-test.
Compreso quindi il perché la replicabilità è una parte importante dell’usabilità e del lavoro del valutatore, cerchiamo di chiarire perché spesso quando si parla di usabilità le persone hanno in mente cose anche molto diverse e la prima paura che hanno è il rapporto costo benefici. Chiediamoci quindi: cos’è un test d’usabilità? E come si fa a dire che un test ha raggiunto il suo obiettivo?
Una metafora per i test d’usabilità: i funghi probabilistici
Tanti motovi storici e disciplinari possono spiegare perché l’usabilità venga spesso trattata come un insieme di metodi (anche molto diversi fra loro) che tendono al medesimo risultato: migliorare l’interazione. Sebbene questo non sia del tutto errato, occorre superare la vecchia impostazione che ha spinto sull’idea che l’usabilità fosse facile ed economica da fare (si sto parlando di Nielsen). Ovvero, quella necessità propria degli anni Ottanta e Novanta in cui, purché si facesse qualunque analisi per migliorare l’interazione con i prodotti, si accettava di tutto e lo si faceva rientrare nell’etichetta usabilità. Ancorché questa impostazione fosse probabilmente un fase necessaria alla diffusione del concetto di usabilità questo retaggio storico, oggi un po’ obsoleto, costituisce una delle maggiori barriere alla diffusione di una sana cultura e di buone pratiche sull’usabilità.
<<Purtroppo, un test di usabilità non va bene purché si faccia e riuscire a farlo anche alla rinfusa non è un successo, anzi spesso è uno sforzo economico che produce pochi risultati.>>
I metodi non sono tutti uguali, ma hanno scopi, vantaggi e svantaggi che bisogna saper considerare, e il modo (la procedura) con cui si svolge un test è forse anche più importante degli stessi risultati. Inoltre, come dicevamo prima, i test di usabilità sono un momento di un processo più grande teso a valutare la qualità dell’interazione. Semplificando al massimo, mentre una valutazione dell’interazione con un prodotto o servizio ha l’obiettivo di rendere il prodotto migliore, un test di usabilità è un momento di questa valutazione che ha lo scopo mirato di individuare in maniera formale tutte quelle problematiche in termini di interazione che possono diminuire la soddisfazione dell’utente ed in generale la sua esperienza d’uso [10]. In questo senso, un test di usabilità ha bisogno di misure oggettive o quantomeno standardizzate. Sebbene sia facile comprendere questa necessità quando parliamo di misurare, per esempio, le prestazioni dell’utente in termini di tempo (efficienza) o di problemi avuti durante l’interazione (efficacia), questa necessità di misure formali sembra meno comprensibile quando si tratta di soddisfazione.
<<Ancora troppo spesso la soddisfazione viene frettolosamente misurata con l’aggiunta di domande a fine test del tipo: quanto hai trovato usabile il prodotto?Non sapete la difficoltà per spiegarlo ai futuri esperti di valutazione: che no, chiedere ad un utente se è soddisfatto non è una misura di soddisfazione!>>
Sebbene non ci sia nulla di sbagliato nel creare un questionario qualitativo adattato alle peculiarità del prodotto per avere dati qualitativi sulla esperienza interattiva dall’utente, una cosa è raccogliere l’opinione degli utenti sul prodotto, un’altra è misurare la soddisfazione d’uso con una scala validata che permette di comparare i propri risultati rispetto ad un riferimento standardizzato. Scale, anche molto brevi, come il System Usability Scale [11] per misurare la soddisfazione (intesa come usabilità percepita) possono benissimo (e gratuitamente) essere utilizzate insieme a scale qualitative offrendo la possibilità di avere un dato comparabile e standardizzato, insieme ad uno adatto alla vostre esigenze specifiche.
Io credo che il problema principale sia che ogni persona, esperta o meno nel campo dell’interazione, abbia una visione differente sul perché e sul come fare un test di usabilità. Il mio punto di vista, maturato negli anni, è che un test di usabilità richieda una solida pianificazione e selezione dei metodi e di cosa misurare, ed una certa rigidità metodologica. Dopo questa considerazione personale, torniamo alla nostra domanda principale: Cosa è un test di usabilità e quando questo test ha successo?
Cercherò di spiegarlo con una metafora che sembrerà banale ma non lo è: quella dei funghi probabilistici [7]. Secondo questa metafora fare un test di usabilità è come mandare un gruppo di neofiti ad esplorare un bosco alla ricerca di funghi insieme ad un esperto raccoglitore e conoscitore di funghi (micologo). Lo so, sembra non ci azzecchi nulla, ma seguitemi!
Immaginate che voi in qualità di esperti di micologi dobbiate accompagnare un gruppo di neofiti in un bosco per insegnargli ad individuare i funghi. Arrivati al bosco decidete di far entrare con voi nel bosco una persona alla volta ed ogni persona ha una mappa con lo stesso percorso da seguire (scenario) e gli dite che voi starete dietro di loro passo dopo passo in silenzio se avessero bisogno di aiuto. Il compito (task) di ogni neofita sarà quello di seguire il percorso e segnare sulla mappa dove ha individuato i funghi, senza mai andare a raccoglierne uno. Alla fine di ogni passaggio nel bosco voi avrete una mappa con indicato dove ogni persona ha individuato i funghi in diverse posizioni nel bosco (problemi di usabilità).
Ogni persona avrà speso più o meno tempo nel fare il percorso, e qualcuno si sarà pure perso (efficienza). Alcuni si saranno molto divertiti ed altri meno, o per niente (soddisfazione), qualcuno si sarà completamente dimenticato di segnare dove ha individuato i funghi (fallimento del task), o avrà sbagliato nel segnarli o non avrà capito che dove segnarli (errore metodologico). Noterete che alcune persone avranno trovato i funghi in tanti posti diversi, altri avranno trovato pochi o nessun fungo (efficacia). Inoltre, rifacendo il percorso alla fine della giornata osservando le mappe con le indicazioni dei vostri utenti (analisi) noterete che qualcuno avrà trovato funghi velenosi, altri commestibili o di altissima qualità (tipologia di problemi indentificati). Immaginiamo di aver portato cinque persone nel bosco e che in totale queste persone abbiano trovato sette posti nel bosco in cui c’è almeno un fungo, e organizziamo questi dati visivamente in una tabella (Tabella 1)
Tabella 1 ci dice che in media i funghi nella posizione numero due e tre sono quelli più facili da trovare (media per funghi individuati) e che la quarta persona che abbiamo portato nel bosco non ha trovato alcun fungo, mentre i soggetti 1, 3 e 5 sono stati mediamente più capaci di trovare funghi (media individuale). In fine se calcoliamo la media delle medie individuali otteniamo la probabilità che una persona seguendo quel percorso nel bosco individui le stesse sette posizioni in cui si possono trovare dei funghi (solitamente indicata come: Pest).
Ora, fuor di metafora. Se proprio vogliamo ridurre al minimo oggettivo il successo di un test di usabilità possiamo misurarlo con il Pest, cioè un test avrà avuto tanto successo quanto alto sarà il numero di problemi totali che le persone coinvolte nel test saranno riuscite ad identificare per ogni task o scenario. Ovviamente poi dipenderà anche dall’importanza dei problemi rilevati e dalla possibilità di risolverli e dal poter escludere artefatti dovuti ad errori metodologici, per esempio errori di presentazione del task.
Se utilizziamo il Pest ricavato inTabella 1 e facciamo un calcolo veloce applicando la formula proposta da Nielsen e Landauer [12] per definire il tasso di scoperta dei problemi di usabilità in un test scopriamo che con i nostri 5 “cercatori” abbiamo identificato circa 84% di posti in cui in quel percorso è possibile individuare funghi, come mostrato in Tabella 2.
La procedura di calcolo del tasso di scoperta è il seguente:
Tasso di scoperta=(1- Pest)^n (dove n è uguale al numero di soggetti progressivo riportato in Tabella 2).
Lasciando il territorio della micologia che abbiamo usato impropriamente nella nostra metafora, nella disciplina dell’usabilità questo problema viene generalmente presentato come: quanti utenti devo coinvolgere in un test perché questo identifichi almeno l’80% di problemi di usabilità? Questa soglia (80–85% di problemi) in passato è stata stabilita per siti web o interfacce digitali proprio utilizzando il model del Pest [12, 13], e questa percentuale può salire fino a 90–97% in campo biomedicale [14].
Normalmente alla domanda quanti utenti devo coinvolgere in molti rispondono 5 utenti mentre altri, più cauti, rispondono 10 o 15. Evitando di dare troppo i numeri cerchiamo di rispondere a questa domanda
Un salto logico: da quanti utenti a come controllare le performance di scoperta del campione.
<<Rispondiamo subito alla domanda cha ci siamo posti sopra dicendo che la risposta non è 5, e che più in generale non c’è un numero magico [15] che garantisca di trovare un alto numero di problemi di usabilità durante un test. Anzi, l’unica risposta corretta a questa domanda è: dipende. In particolare dipende da chi coinvolgete nella valutazione e il perché, ma procediamo con ordine.>>
La questione del numero di utenti è stata (e forse è ancora) così importante perché al fine di massimizzare il rapporto costi (di reclutamento, di conduzione del test, di analisi) e percentuale stimata di errori, si cerca sempre di reclutare il numero minimo di persone che possa fare emergere il maggior numero di problematiche possibili. A questo scopo modelli probabilistici come il Pest e altri modelli (meno generosi) sono stati sviluppati per effettuare questi calcoli. Prima di guardare ai modelli alternativi dobbiamo però comprendere che la vera domanda che ci dobbiamo fare non è quanti utenti dobbiamo coinvolgere, ma piuttosto: quanta variabilità abbiamo bisogno di introdurre nei nostri test per sottoporre il prodotto o servizio ad un test realistico?
Una delle cose più difficili da comprendere nel calcolo probabilistico del Pest risiede nel fatto che il numero totale di problemi di usabilità (cioè il 100% dei problemi) è ignoto e probabilmente irraggiungibile. Ma assumiamo per un momento di poter conoscere il 100% dei problemi in anticipo, così come fatto da Laura Faulkner nel suo esperimento del 2003 [16].
Questa ricercatrice coinvolse 60 persone nel test di un software facendo un singolo task, individuando 45 problemi di usabilità. Il suo assunto fu di aver trovato il 100% degli errori nel prodotto poiché aveva utilizzato un ampio campione con differenti livelli di competenza con il prodotto. Dunque conoscendo il totale dei problemi (45 problematiche di usabilità) ed utilizzando tecniche di ricampionamento statistico, questa ricercatrice simulò il tasso di scoperta con campioni composti da 5, 10, 20, 30, 40, 50 partecipanti. I dati dimostrarono che con 5 utenti il totale dei problemi individuati era solamente del 55% mentre la percentuale saliva intorno ad un accettabile 80%-90% intorno a 12–15 partecipanti. Dopo questo esperimento molti esperti, specialmente nel campo dei prodotti medici, cominciarono a dire che un buon test di usabilità doveva essere fatto con almeno 12–15 utenti [14].
Sebbene questo esperimento sia esemplificativo dell’annosa questione (quanti utenti debbano essere coinvolti per avere un test affidabile di usabilità?), anche la risposta 12–15 utenti in realtà non è corretta. Per diversi motivi, primo (e più importante) i risultati del test di questa ricercatrice sono specifici per il prodotto testato e non sono generalizzabili a tutti i prodotti allo stesso modo. Per cui tentare di generalizzare i risultati di questo esperimento è quanto meno inappropriato. Inoltre, assumere di avere trovato il 100% dei problemi è un artefatto logico, sebbene altamente probabile che non vi siano più di 45 problemi nell’esperimento di Faulkner non si può neanche ragionevolmente escludere che un pool di nuovi utenti non ne possa trovare altri.
E qui ci riconnettiamo al tema della variabilità.
Certamente le performance degli utenti possono essere differenti per via della loro età, delle loro capacità d’uso di un prodotto o semplicemente del loro ruolo. Inoltre, non tutti gli utenti che invitiamo a far un test sono uguali nella loro capacità di individuare problemi, alcuni sono più motivati di altri, o semplicemente più attenti a verbalizzare o scovare problemi. Per questo motivo in un test di usabilità si dovrebbe cercare sempre di conoscere non solo gli utenti principali o il target ma in generale tutti coloro che per diversi motivi utilizzano ed entrano in contatto con il prodotto (stakeholders). Prendiamo, per esempio, uno strumento medico per test diagnostici. Sicuramente gli utenti target sono i medici con una specifica specializzazione e con diverse fasce di esperienze cumulata negli anni (mettiamo fra uno e 3 anni, e più di 3 anni), ma quel prodotto medico molto probabilmente verrà maneggiato, e spesso anche preparato pulito e predisposto all’uso, da altro personale per esempio infermieristico con diversi gradi di specializzazione ed esperienza. Già solo seguendo questo esempio un test di usabilità (fatto bene) dovrebbe coinvolgere almeno un gruppo di medici con da 1 a tre anni di esperienza, un gruppo di professionisti con più di tre anni, e un gruppo o più di assistenti sanitari.
Fate dunque voi i conti! Se, nonostante tutto quello di cui abbiamo discusso sopra, decidete arbitrariamente di utilizzare un numero fisso di utenti (diciamo 5 seguendo Nielsen), allora ricordate tutta la storia: ovvero che dovreste testare almeno 5 persone per tipologia di utente, non 5 utenti in totale.
Quello che vi propongo è un salto logico, ovvero non chiedetevi quanti utenti dovete utilizzare, ma come potete controllare le performance del tasso di scoperta del vostro campione introducendo più variabilità possibile nel vostro campione in modo da rappresentare al meglio il contesto in cui quel prodotto verrà utilizzato. A questo sono realmente utili i modelli probabilistici come il Pest.
Analizzare i dati di un test creando tabelle come quelle che abbiamo utilizzato per il calcolo probabilistico del tasso di scoperta sono infatti un ottimo modo per controllare l’andamento del test e per decidere quando è il caso di fermarsi e rivedere le strategie di selezione dei partecipanti. Per esempio, se dopo i primi cinque utenti di un test è stato trovato un solo problema di usabilità, è possibile che il prodotto sia già molto usabile o che gli utenti coinvolti siano molto simili per attitudini e competenze o che ci sia qualcosa da rivedere nella metodologia. Oppure, potrebbe capitare di individuare 30 problemi di usabilità già dopo i primi tre utenti, cosa che solitamente indica che qualcosa non funziona nel design o nei tasks.
Quando tutto è allineato, ovvero la metodologia è ben disegnata, gli utenti sono stati selezionati in modo comprensivo, magari includendo anche persone con disabilità [7] e non ci sono risultati estremi, il calcolo probabilistico del tasso di scoperta ci permette di definire un obiettivo, una soglia a cui tendere (80–85% per interfacce digitali oppure fino a 90–97% in campo biomedicale). Queste soglie sono senz’altro facilmente raggiungibili con il modello the Pest basato sulle medie, tuttavia altri modelli più compresivi sono oggi disponibili fra cui: il Boostrap Discovery Behaviour Model [BDB model, 17], il zero-truncated model [15, 18], e il Good-Turing model [19].
I primi due sono modelli matematici che possono essere fatti girare: uno in MatLab (BDB) e l’altro in R (zero-truncated model) mentre il terzo, il modello Goot-Turing, è una variazione del Pest che considera anche quante volte un problema è stato identificato. In tutti questi casi il valore del Pest, e quindi del tasso di scoperta dei problemi, viene solitamente abbassato.
Io nei miei test, prettamente in campo medico, ma anche con tecnologie di realtà virtuale ed aumentata in altri settori, tendo ad utilizzare tutti questi modelli nei miei report di usabilità riportando il valore più ottimistico (Pest) e quello più basso risultante dai tre modelli, riportando così che un test ha individuato una percentuale di problemi entro un certo intervallo. Per fare un esempio, calcolando il tasso di scoperta con il modello Good-Turing (PGTadj) utilizzando i dati della Tabella 1 è facile ottenere che il valore della probabilità media che una persona trovi un problema di usabilità eseguendo lo stesso scenario sia compreso fra 0.31 (Pest) a 0.27 (PGTadj), come riportato in Tabella 3.
Come indicato in Tabella 4 il modello Good-Turing abbassa la stima del tasso discoperta da 84% a 79%. Questo perché nel PGTadj, diversamente dal Pest, il numero dei problemi individuati da una sola persona viene considerato nel calcolo solitamente abbassando il tasso di scoperta.
L’utilizzo congiunto di più modelli permette, come in questo caso, di riportare per esempio che il test ha individuato fra 79% (PGTadj) e 84% (Pest) dei problemi potenziali in quello scenario con cinque utenti suggerendo che, probabilmente, vi è la necessità di allargare il campione per raggiungere un soglia più alta fra 80–85%. Questi metodi di calcolo probabilistico, che sembrano complessi giochi matematici fini a se stessi, in realtà sono strumenti che ci permettono di monitorare il comportamento del campione durante la fase di testing.
Conclusione: Quantificare i test di usabilità per favorire la replicabilità
<<Ci sono più cose in cielo e in terra, Orazio, di quante ne possa immaginare la tua filosofia>>
Fare un test di usabilità significa predisporre un test empirico solido, controllabile e ripetibile. Molto è cambiato dagli anni Novanta, ma ancora oggi c’è molto più da scoprire sull’usabilità di quanto si pensi e molti vecchi preconcetti devono ancora essere abbandonati. Se vogliamo fare un piccolo riassunto dei nodi principali del discorso, direi che ci sono almeno cinque punti su cui riflettere:
- L’usabilità ha quattro dimensioni che devono essere considerate prima e riportate dopo un test: efficacia, efficienze, soddisfazione e il contesto d’uso. Efficacia, efficienza e soddisfazione possono e devono essere misurate in maniera formale, il più oggettiva o standardizzata possibile in un test. Il contesto d’uso deve essere analizzato e riportato descrittivamente in modo da favorire comparazioni e analisi della qualità dei test effettuati;
- Un test di usabilità è il momento più quantitativo del processo di analisi dell’interazione e c’è differenza fra un test con utenti ed altri tipi di analisi dell’usabilità;
- I test di usabilità devono poter essere replicabili ed è compito degli esperti che si occupano di valutazione rendere possibile la replicabilità rendendo chiari procedure, metodi e dati per favorire la crescita della cultura dell’usabilità;
- Non esistono numeri magici nell’usabilità. Cinque, dieci o cento utenti non possono garantirvi che un prodotto sia usabile. Quello che potete fare è cercare di rappresentare il contesto d’uso del prodotto nel test coinvolgendo gruppi di utenti rappresentativi degli stakeholder. Ed utilizzare modelli probabilistici per prendere decisioni riguardo a quali e quanti partecipanti coinvolgere.
- La capacità di un test di identificare un certa percentuale di problemi può essere stimata con semplici formule o con applicazioni disponibili gratuitamente.
Referimenti bibliografici
1. ISO, ISO 9241–11:2018 Ergonomic requirements for office work with visual display terminals — Part 11: Guidance on usability. 2018, CEN: Brussels, BE.
2. Borsci, S., et al., Shaking the usability tree: why usability is not a dead end, and a constructive way forward. Behaviour & Information Technology, 2019. 38(5): p. 519–532.
3. ISO/IEC, ISO/IEC 25062 Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Common Industry Format (CIF) for usability test reports. 2006, CEN: Brussels, BE.
4. IEC, IEC 62366–1:2015 Medical devices — Part 1: Application of usability engineering to medical devices. 2015, CEN: Brussels, BE.
5. ISO, ISO 14971:2007 Medical devices — Application of risk management to medical devices. 2007, CEN: Brussels, BE.
6. Blandford, A., D. Furniss, and C. Vincent, Patient safety and interactive medical devices: realigning work as imagined and work as done. Clinical risk, 2014. 20(5): p. 107–110.
7. Borsci, S., et al., Computer systems experiences of users with and without disabilities: an evaluation guide for professionals. 2013, New York: CRC Press.
8. Pashler, H. and C.R. Harris, Is the replicability crisis overblown? Three arguments examined. Perspectives on Psychological Science, 2012. 7(6): p. 531–536.
9. Bojko, A., Eye tracking the user experience: A practical guide to research. 2013: Rosenfeld Media.
10. ISO, ISO 9241–210:2010 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems. 2010, CEN: Brussels, BE.
11. Borsci, S., et al., Short Scales of Satisfaction Assessment: A Proxy to Involve Disabled Users in the Usability Testing of Websites, in Human-Computer Interaction: Users and Contexts, M. Kurosu, Editor. 2015, Springer International Publishing. p. 35–42.
12. Nielsen, J. and T.K. Landauer. A mathematical model of the finding of usability problems. in Proceedings of the INTERACT’93 and CHI’93 conference on Human factors in computing systems. 1993. ACM.
13. Virzi, R.A., Refining the Test Phase of Usability Evaluation: How Many Subjects Is Enough? Human Factors, 1992. 34(4): p. 457–468.
14. Food and Drug Administration, Draft guidance for industry and Food and Drug Administration staff — Applying human factors and usability engineering to optimize medical device design. 2011, U.S. Food and Drug Administration: Silver Spring, MD.
15. Schmettow, M., Sample size in usability studies. Commun. ACM, 2012. 55(4): p. 64–70.
16. Faulkner, L., Beyond the five-user assumption: Benefits of increased sample sizes in usability testing. Behavior Research Methods, Instruments, & Computers, 2003. 35(3): p. 379–383.
17. Borsci, S., A. Londei, and S. Federici, The Bootstrap Discovery Behaviour (BDB): a new outlook on usability evaluation. Cognitive Processing, 2011. 12(1): p. 23–31.
18. Schmettow, M. Controlling the usability evaluation process under varying defect visibility. in Proceedings of the 23rd British HCI Group Annual Conference on People and Computers: Celebrating People and Technology. 2009. British Computer Society.
19. Turner, C.W., J.R. Lewis, and J. Nielsen, Determining usability test sample size. International encyclopedia of ergonomics and human factors, 2006. 3(2): p. 3084–3088.
