P Cap.14: Valutare l'usabilità

download P Cap.14: Valutare l'usabilità

of 19

Transcript of P Cap.14: Valutare l'usabilità

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    1/19

    14.Valutare lusabilit

    Sintesi del capitolo

    Questo capitolo descrive le due tecniche pi utilizzate per valutare lusabilit dei sistemi: le cosiddette valutazionieuristiche e i test di usabilit. Nel primo caso, la valutazione eseguita da esperti di usabilit, con laiuto di regole pi omeno dettagliate, che riflettono lo stato delle conoscenze del settore. Si citano le euristiche di Nielsen, molto conosciute.Nel secondo caso, i test sono effettuati da un campione di utenti, che utilizzano il sistema in un ambiente controllato,sotto osservazione da parte dei valutatori. I test di usabilit si possono classificare in formativi e sommativi; in test di

    compito e di scenario. Il capitolo termina con una serie di indicazioni pratiche per la preparazione e la esecuzione di untest di usabilit, e per la preparazione del rapporto di valutazione.

    Verifiche e convalide

    Nel modello di progettazione e sviluppo iterativi descritto nella Figura 3 del Capitolo 6, ad ogni ciclo di iterazione sieffettuano dei test di valutazione dellultimo prototipo prodotto. Come specifica lo standard ISO 13407, la valutazione un passo essenziale in una progettazione human-centred. Allinizio del progetto, lobiettivo principale sar la raccoltadi indicazioni per orientare le attivit di progettazione successive. Nelle fasi pi avanzate, con la disponibilit di prototipi pi completi, sar invece possibile quantificare il livello di raggiungimento degli obiettivi dellutente edellorganizzazione. Dopo il rilascio del sistema, sar possibile monitorarne ladeguatezza ai nuovi contesti di utilizzo.

    I termini generici valutazione o test possono denotare due attivit molto diverse:

    il controllo che il prodotto sia congruente con quanto espresso nei documenti di specifica dei requisiti. Perquesto tipo di test si usa normalmente il termine verifica (verification);

    il controllo che il prodotto soddisfi effettivamente le esigenze per le quali stato concepito. Per questo tipo ditest si usa, invece, il termine convalida (validation).

    Nel primo caso si tratta, come si usa dire nella lingua inglese, di verificare che il gruppo di progetto made the thingsright; nel secondo caso che made the right things. La differenza fra verifica e convalida sostanziale, perch non detto che i documenti di specifica dei requisiti esprimano sempre correttamente le esigenze che il prodotto dovrebbesoddisfare. Infatti, lestensore delle specifiche potrebbe avere male interpretato le richieste degli stakeholder del

    prodotto, che peraltro nel corso del progetto potrebbero cambiare.

    Le attivit di convalida sono molto pi difficili delle verifiche. Non si tratta, infatti, di controllare la congruenza (o,come si dice, la tracciabilit) fra le caratteristiche del prodotto e le indicazioni contenute nel documento dei requisiti,ma di controllare che il prototipo soddisfi effettivamente le esigenze espresse (o, a volte, ancora inespresse) delcommittente. Per questo, la convalida non pu essere condotta soltanto dal team di progetto, ma richiedenecessariamente il coinvolgimento dellutente e degli altri stakeholder del prodotto.

    In questo libro ci occuperemo, in particolare, delle attivit di valutazione dellusabilit, rimandando per gli altri aspettiallampia letteratura esistente sul testing in generale. Per compierle si possono impiegare diverse tecniche, che rientranoin due grandi categorie:

    Valutazioni effettuate da parte di esperti di usabilit, senza alcun coinvolgimento dellutente.Queste valutazioni prendono il nome di ispezioni (inspection). Le pi note sono le cosiddette valutazioni

    1

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    2/19

    euristiche (euristic evaluation).

    Valutazioni effettuate con il coinvolgimento dellutente.

    Sono le pi importanti e le pi utilizzate. Fra queste, nel seguito saranno descritti i test di usabilit (usability test).

    Valutazioni euristicheLaggettivo euristico si usa, in matematica, per denotare un procedimento non rigoroso che consente di prevedere orendere plausibile un determinato risultato, che in un secondo tempo dovr essere controllato e convalidato con metodirigorosi. Nellingegneria dellusabilit, si chiamano euristiche quelle valutazioni di usabilit effettuate da esperti,analizzando sistematicamente il comportamento di un sistema e verificandone la conformit a specifiche regole doro(chiamate, appunto, euristiche), derivanti da principi o linee guida generalmente accettati. In pratica, per eseguire unavalutazione euristica, lesperto di usabilit dovrebbe considerare una regola euristica alla volta, ed esaminaredettagliatamente le funzioni del sistema, per verificarne la conformit.

    Le euristiche impiegate sono diverse. In letteratura se ne trovano alcune costituite da centinaia di regole dettagliate. evidente che valutare un sistema in base a una tale quantit di regole risulta impraticabile. Si preferisce quindi, pi

    spesso, utilizzare euristiche costituite da pochi principi guida generali. Fra queste, sono molto note le euristiche diNielsen, costituite da dieci regole che, sebbene molto generali, permettono al valutatore di inquadrare i problemi rilevatiin categorie bene individuate.

    Le dieci euristiche di Nielsen, spiegate con le sue stesse parole, sono le seguenti1:

    1. Visibilit dello stato del sistema

    Il sistema dovrebbe sempre informare gli utenti su ci che sta accadendo, mediante feedback appropriati in untempo ragionevole.

    2. Corrispondenza fra il mondo reale e il sistema

    Il sistema dovrebbe parlare il linguaggio dellutente, con parole, frasi e concetti familiari allutente, piuttosto chetermini orientati al sistema. Seguire le convenzioni del mondo reale, facendo apparire le informazioni secondo unordine logico e naturale.

    3. Libert e controllo da parte degli utenti

    Gli utenti spesso selezionano delle funzioni del sistema per errore e hanno bisogno di una uscita di emergenzasegnalata con chiarezza per uscire da uno stato non desiderato senza dover passare attraverso un lungo dialogo.Fornire allutente le funzioni di undo e redo.

    4. Consistenza e standard

    Gli utenti non dovrebbero aver bisogno di chiedersi se parole, situazioni o azioni differenti hanno lo stessosignificato. Seguire le convenzioni della piattaforma di calcolo utilizzata.

    5. Prevenzione degli errori

    Ancora meglio di buoni messaggi di errore unattenta progettazione che eviti innanzitutto linsorgere delproblema. Eliminare le situazioni che possono provocare errori da parte dellutente, e chiedergli conferma prima dieseguire le azioni richieste.

    6. Riconoscere piuttosto che ricordare

    Minimizzare il ricorso alla memoria dellutente, rendendo visibili gli oggetti, le azioni e le opzioni. Lutente nondovrebbe aver bisogno di ricordare delle informazioni, nel passare da una fase del dialogo a unaltra. Le istruzioniper luso del sistema dovrebbero essere visibili o facilmente recuperabili quando servono.

    7. Flessibilit ed efficienza duso

    Acceleratori invisibili allutente novizio possono spesso rendere veloce linterazione dellutente esperto, inmodo che il sistema possa soddisfare sia lutente esperto sia quello inesperto. Permettere allutente di

    1 Nielsen, J., and Molich, R., Heuristic evaluation of user interfaces, Proc. ACM CHI'90 Conference, pagg.249-256. Le 10euristiche citate sono state riprese, in nostra traduzione, dal libro di J.Nielsen, Usability Engineering, 1994.

    2

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    3/19

    personalizzare le azioni frequenti.

    8. Design minimalista ed estetico

    I dialoghi non dovrebbero contenere informazioni irrilevanti o necessarie solo di rado. Ogni informazioneaggiuntiva in un dialogo compete con le unit di informazione rilevanti e diminuisce la loro visibilit relativa.

    9. Aiutare gli utenti a riconoscere gli errori, diagnosticarli e correggerli

    I messaggi di errore dovrebbero essere espressi in linguaggio semplice (senza codici), indicare il problema conprecisione e suggerire una soluzione in modo costruttivo.

    10. Guida e documentazione

    Anche se preferibile che il sistema sia utilizzabile senza documentazione, pu essere necessario fornire aiuto edocumentazione. Ogni tale informazione dovrebbe essere facilmente raggiungibile, focalizzata sul compitodellutente, e dovrebbe elencare i passi concreti da fare, senza essere troppo ampia.

    La mostra una possibile corrispondenza fra le euristiche di Nielsen e le regole dellISO 9241 descritte nel Capitolo 10.Si noti che pi euristiche possono derivare da uno stesso principio e, daltro canto, pi principi possono giustificare unastessa euristica. Per esempio, leuristica flessibilit ed efficienza duso pu essere associata anche al principioadeguatezza allindividualizzazione.

    Figura 1. Confronto fra i principi del dialogo dellISO 9241e le euristiche di Nielsen

    La valutazione euristica ha il vantaggio di essere relativamente poco costosa. Tuttavia fornisce risultati piuttostosoggettivi. Quanto pi le euristiche sono generali, tanto pi il risultato della valutazione dipender dallesperienza, dallasensibilit e, a volte, dalle preferenze personali del valutatore. Le esperienze condotte in molti progetti hanno mostratoche valutatori diversi tendono a trovare problemi diversi. La mostra i risultati della valutazione euristica di un sistemabancario effettuata da 19 valutatori, descritta dallo stesso Nielsen.2 Il diagramma riporta in verticale i valutatori, e inorizzontale i 16 problemi di usabilit da questi individuati. Ogni quadratino nero indica un problema segnalato da unvalutatore. I problemi sono ordinati lungo lasse orizzontale: pi sono a destra, pi valutatori li hanno individuati. Lafigura mostra chiaramente che i diversi valutatori hanno trovato problemi diversi. Nessun problema stato segnalato datutti i valutatori, e solo 4 sono stati segnalati da pi della met dei valutatori. Alcuni problemi facili da trovare (quelli

    2http://www.useit.com/papers/heuristic/heuristic_evaluation.html.

    3

    http://www.useit.com/papers/heuristic/heuristic_evaluation.htmlhttp://www.useit.com/papers/heuristic/heuristic_evaluation.html
  • 8/3/2019 P Cap.14: Valutare l'usabilit

    4/19

    sulla destra) sono stati individuati da quasi tutti i valutatori, altri (quelli sulla sinistra) soltanto da pochi. Infine, ivalutatori che hanno segnalato alcuni dei problemi pi difficili da scoprire, non ne hanno invece segnalati alcuni chesono stati individuati da molti valutatori.

    Figura 2. Risultati di una valutazione euristica di un sistema bancario (http://www.useit.com)

    In sintesi, con la valutazione euristica possibile ottenere buoni risultati solo impiegando pi valutatori sullo stessoprogetto, che analizzino separatamente il sistema senza comunicare fra loro. In ogni caso, questa tecnica non garantisceche vengano rilevati tutti i problemi di usabilit, e pu capitare che vengano segnalati problemi che, in realt, nonesistono. Ci dovuto al fatto che i valutatori possono avere delle preferenze personali su come determinate funzionidel sistema debbano essere sviluppate, e non detto che queste corrispondano a criteri oggettivamente verificabili. anche evidente che i risultati saranno tanto pi affidabili quanto pi i valutatori saranno esperti nel particolare ambito inesame. Di conseguenza, la valutazione euristica pu aggiungersi, ma non sostituirsi ai test con gli utenti, che devonocomunque essere condotti. I due tipi di valutazioni sono complementari, e possono dare risultati diversi ().

    Figura 3. a) Risultati della valutazione euristica; b) confronto fra valutazione euristica e test di usabilit

    4

    http://www.useit.com/http://www.useit.com/
  • 8/3/2019 P Cap.14: Valutare l'usabilit

    5/19

    Test di usabilit

    Un test di usabilit consiste nel far eseguire a un gruppo di utenti dei compiti tipici di utilizzo del sistema in unambiente controllato. Si sceglie un campione di utenti che sia rappresentativo della categoria di utenti cui il sistema si

    rivolge, e si chiede a tutti di svolgere, separatamente, gli stessi compiti. Chi conduce il test osserva e analizza il lorocomportamento per comprendere se, dove e perch essi hanno incontrato delle difficolt. Il test coinvolge, oltreallutente che prova il sistema, almeno due altre persone: un facilitatore, che ha il compito di gestire la regia dellaprova, e uno o pi osservatori, che assistono al test, annotando i comportamenti dellutente che ritengono significativi.Il ruolo degli osservatori critico: essi dovrebbero conoscere bene il sistema, e avere eseguito personalmente i compitichiesti agli utenti. Solo in questo modo saranno in grado di interpretarne e valutarne correttamente i comportamenti.Facilitatori e osservatori potranno essere degli esperti di usabilit, oppure dei membri del team di progetto, a secondadei casi.

    Quando si usino prototipi di carta o tecniche con il mago di Oz (vedi Capitolo 9), servir una terza persona, con ilcompito di simulare il sistema. Come abbiamo gi osservato, si tratta di un compito piuttosto impegnativo, che richiede

    preparazione e attenzione; pertanto, non potr essere svolto n da chi coordina il test n da chi ne osserva losvolgimento. A simulare il sistema sar molto spesso un progettista, che conosca ne bene il funzionamento previsto.

    Un test di usabilit ha lo scopo di ricavare indicazioni concrete per il miglioramento del sistema. Chi lo conduce dovresaminare in dettaglio le operazioni svolte dagli utenti per capire dove nascono le difficolt, da che cosa sono causate ein quale modo possano essere rimosse. Per questo, molto utile la cosiddetta tecnica del pensare ad alta voce ( thinkaloud), che consiste nel chiedere allutente di esprimere a voce alta ci che pensa mentre compie le varie operazioni.Questo molto utile, perch permette agli osservatori di raccogliere informazioni sulle strategie messe in attodallutente nellesecuzione dei compiti, e sulle difficolt che egli incontra durante il test.3

    Lanalisi del comportamento degli utenti non pu essere condotta in tempo reale durante lo svolgimento del test, madeve essere compiuta dopo, con la necessaria tranquillit. Anche se lutente esprime ad alta voce, durante la prova, le

    difficolt che sperimenta, le cause di queste difficolt possono non essere evidenti. Per identificarle, e comprenderecome possano essere rimosse, sar necessario riesaminare con attenzione la sequenza di azioni eseguite dallutente.Durante il test, losservatore dovr quindi prendere appunti, registrando le situazioni in cui lutente manifesta incertezzao commette degli errori. Questi appunti saranno riesaminati in seguito, per individuare le cause del problema e studiarele correzioni pi opportune.

    Se possibile, preferibile eseguire una registrazione (audio e video) della sessione di test, per rivedere in seguito tuttoci che avvenuto durante la prova. La tecnica pi comune consiste nel riprendere con una telecamera il visodellutente mentre esegue il test, registrando contemporaneamente le sue parole e, con unaltra telecamera, il sistema.Le due registrazioni dovranno poi essere viste in modo sincronizzato: spesso le espressioni del viso dellutente sonoaltrettanto rivelatrici delle sue parole e delle sue azioni. Le e sono tratte, rispettivamente, dalla registrazione di un test

    con un prototipo di carta e con un prototipo PowerPoint per unapplicazione iPhone. In entrambe, sulla sinistra appare ilviso dellutente, sulla destra le operazioni che compie sul sistema. Nella prima figura, sono stati inseriti insovraimpressione, per comodit, i nomi dei compiti in esecuzione (Leggi lavviso pi recente).

    3

    La tecnica viene correntemente utilizzata, anche se non esente da difetti. Essa infatti piuttosto intrusiva, e crea un contestosostanzialmente diverso dalla esecuzione silenziosa. Infatti, modifica il carico cognitivo dellutente, e pu portarlo a modificare lastrategia di esecuzione dei vari compiti.

    5

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    6/19

    Figura 4. Registrazione di un test di usabilit con prototipo di carta

    Figura 5. Registrazione di un test dusabilit per unapplicazione su iPhone

    Nel caso di sistemi eseguiti al computer, tutto questo si pu fare, molto semplicemente, con una sola webcam cheriprenda il viso dellutente, un microfono e un programma in esecuzione sullo stesso computer usato per il test, cheregistri le immagini che appaiono sul video, in modo sincronizzato con le registrazioni audio e video. Tali programmi(ne esistono anche di gratuiti) permettono poi di esaminare in dettaglio, per cos dire alla moviola, le azioni effettuatedallutente e metterle in corrispondenza con le espressioni del viso e le parole pronunciate. La mostra una immagine

    dalla registrazione di un test di un sito web.

    6

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    7/19

    Figura 6. Registrazione di un test di usabilit con un programma apposito

    Fino a qualche anno fa era diffusa la convinzione che per fare un buon test di usabilit fosse indispensabile usare unlaboratorio appositamente attrezzato (usabilitylab). Esso costituito da due stanze contigue: una per lutente che provae una per gli osservatori (). Nella prima, lutente esegue il test da solo; nella seconda, il facilitatore e gli osservatori lopossono vedere (non visti) attraverso un finto specchio, che permette a chi si trova nella sala di osservazione di vederelinterno della sala prove, ma non viceversa. La sala osservazione contiene inoltre tutti gli apparati necessari percontrollare la registrazione audio e video delle prove: una vera e propria sala di regia.

    Figura 7. Usability lab

    Laboratori di questo tipo sono piuttosto costosi, e sono usati dalle organizzazioni che devono condurre molti test, inmodo professionale. Tuttavia, per condurre dei buoni test di usabilit non indispensabile disporre di una struttura diquesto tipo, e ci si pu organizzare in modo molto pi semplice. Oggi quasi ogni computer dotato di una webcamintegrata e, come abbiamo detto, esistono numerosi pacchetti software che gestiscono la registrazione senza che sianonecessarie apparecchiature e competenze particolari. Utente, facilitatore e osservatori si possono semplicementedisporre attorno a un tavolo, come in .

    7

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    8/19

    Figura 8. Test di usabilit informale

    Se si dispone di una stanza riservata dove condurre il test, tanto meglio, ma neanche questo indispensabile: la mostraun test di usabilit condotto con successo in un laboratorio universitario molto affollato. Ovviamente, in una situazionedi questo tipo sar pi difficile fare seguire il test da pi osservatori: la logistica non lo consente. In effetti, uno deiprincipali vantaggi di uno usability lab come quello di che si pu fare assistere alle prove anche qualche progettista.Vedere con i propri occhi come lutente si blocchi tentando di usare il sistema, e sentirne i commenti a volteesasperati - pu rivelarsi veramente molto istruttivo.

    Figura 9. Test di usabilit di fortuna

    Test formativi e test sommativi

    Vedremo in dettaglio, pi oltre, come un test di usabilit debba essere organizzato e condotto. Per il momento,segnaliamo che i test di usabilit possono essere classificati, in funzione dei loro obiettivi, in due grandi categorie: test

    formativi (formative) e testsommativi (summative).I primi sono utilizzati durante il ciclo iterativo di progettazione, per sottoporre i vari prototipi a prove duso con gli

    8

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    9/19

    utenti, allo scopo di identificarne i difetti e migliorarne lusabilit. Si chiamano formativi perch, appunto,contribuiscono a dare forma al prodotto: il loro scopo individuare il maggior numero possibile di problemi. Essisono particolarmente utili nelle fasi iniziali della progettazione, quando il design concept appena abbozzato. spessoconveniente eseguire questi test in modo rapido e approssimativo (quick & dirty), facendo esercitare a un piccolonumero di utenti le funzionalit principali del sistema. Questo perch nelle fasi iniziali del progetto, quando il design

    concept appena abbozzato, i test mettono in luce rapidamente i difetti macroscopici, che richiedono una parziale (ototale) riprogettazione dellinterfaccia. Quindi non conviene andare troppo per il sottile: si sprecherebbe del tempoprovando a tappeto funzioni che, nella riprogettazione, saranno probabilmente modificate.

    Inoltre, si verifica spesso un effetto di mascheramento: ogni problema di usabilit nel quale incappiamo monopolizza,per cos dire, la nostra attenzione e ci impedisce spesso di vederne altri, soprattutto se di pi lieve entit. Li scopriremoalliterazione successiva, quando il problema iniziale sar stato rimosso (). Quindi si prova in fretta, si modificarapidamente il prototipo eliminando i difetti pi evidenti, e si prova ancora, e cos via. Per il primo test di un prototipoiniziale di carta, 2-3 utenti sono in genere sufficienti.

    Figura 10.Effetto di mascheramento: i difetti macroscopici impediscono di vedere difetti di minoreentit

    Jakob Nielsen ha introdotto il termine discount usability (usabilit scontata)per indicare queste tecniche, rapide, pococostose e non troppo sistematiche per individuare i problemi di usabilit. Gi in un articolo del 1993 4aveva osservatoche utilizzare molti utenti nei test di usabilit inutilmente costoso, e che sono in genere sufficienti da 3 a 5 utenti perrilevare pi del 75% dei problemi di usabilit in un sistema ().

    Figura 11. La regola di Nielsen per i test di usabilit (da www.useit.com)

    4

    J.Nielsen, T.K.Landauer, A Mathematical Model of the Finding of Usability Problems, in Proceedings of the ACM INTERCHI 93Conference, Amsterdam, Aprile 1993, pp.206-213. Per una sintesi, si veda lAlertbox di J.Nielsen del 19 marzo 2000, Why YouOnly Need to Test With 5 Users, in www.useit.com, da cui tratta la .

    9

    http://www.useit.com/http://www.useit.com/http://www.useit.com/http://www.useit.com/
  • 8/3/2019 P Cap.14: Valutare l'usabilit

    10/19

    Questa semplice indicazione pratica (chiamata regola di Nielsen) stata in seguito criticata da diversi autori, che nehanno contestato la validit generale. Lo stesso Nielsen lha parzialmente modificata, portando il numero suggerito diutenti a 5. In pratica, dice Nielsen, i primi 5 utenti metteranno in evidenza la maggior parte dei problemi di usabilit pisignificativi: gli utenti successivi non farebbero altro che confermare gli stessi risultati, aggiungendo ben poco di nuovo.

    I test della seconda categoria si chiamano sommativi. Il termine deriva dal verbo sommare, ed indica una valutazionepi complessiva del prodotto, al di fuori o al termine del processo di progettazione e sviluppo. Sono test picompleti di quelli formativi, che non hanno lo scopo di fornire indicazioni ai progettisti, ma di valutare in modosistematico pregi e difetti del prodotto, o sue particolari caratteristiche.5 Sono di solito condotti quando il sistema completamente funzionante, per esempio per indicarne i punti deboli e valutare lopportunit di un redesignmigliorativo. Oppure per confrontarne le caratteristiche con quelle di sistemi concorrenti. Anche se non si possono dareregole fisse, un test di usabilit ben strutturato, di tipo sommativo, coinvolge di solito un numero maggiore di utenti, peresempio 10-15, o anche di pi.

    Qualunque sia la strategia adottata, i soggetti da utilizzare nei test dovranno sempre essere scelti con cura, affinch

    rappresentino utenti tipici. Per poter interpretare correttamente lesito di ciascun test, chi lo conduce dovr conoscere,per ciascun soggetto, il livello di esperienza nelluso di sistemi analoghi a quello in esame. Il suo profilo dovrebbeessere classificato su due dimensioni: il livello di conoscenza del dominio applicativo del sistema, e il livello difamiliarit con la tecnologia utilizzata (). Queste due dimensioni sono largamente indipendenti. Per esempio, nel test delsito web di una compagnia aerea, alcuni utenti potrebbero avere una lunga esperienza di viaggi in aereo, ma non averemai fatto un acquisto online. La conoscenza del profilo degli utenti impiegati nelle prove indispensabile, perinterpretarne correttamente i risultati.

    Nella scelta degli utenti, si potranno scegliere rappresentanti di tutti i quadranti della figura, o solo di alcuni, a secondadegli obiettivi del test e della natura del sistema. In genere conviene scegliere utenti con caratteristiche diverse. In talmodo, probabile che essi affronteranno i compiti assegnati con strategie differenti, esercitando aspetti diversi delsistema. In ogni caso, tutti gli utenti dovrebbero avere almeno un potenziale interesse nelle funzioni svolte dal sistema.

    Non ha senso chiedere a chi non mai salito su un aereo di prenotare un volo sul sito di una compagnia aerea. Sirischierebbe di incontrare delle difficolt che non derivano dal sistema, ma dalla poca dimestichezza che lutente ha conil problema che gli stato sottoposto. I risultati della prova ne saranno probabilmente inquinati. sbagliato, per farenumero, reclutare le persone pi facilmente disponibili, senza altri accertamenti: si devono proprio selezionare deipotenziali clienti del sistema.

    Figura 12.Le due dimensioni del profilo degli utenti

    5 Il termine valutazione sommativa derivato dalla docimologia, dove si usa per indicare le verifiche praticate a conclusione deiprocessi didattici sulla validit delle attivit effettuate, in rapporto a determinati obiettivi formativi.

    10

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    11/19

    Naturalmente, gli utenti per le prove non dovranno mai essere scelti allinterno del gruppo di progetto. I progettisticonoscono troppo bene il sistema per fornirci delle indicazioni significative. Anche se ci assicurassero che faranno ilpossibile per ignorare quello che sanno e di mettersi nei panni dellutente, le loro prove sarebbero inevitabilmentepoco attendibili.

    Test di compito e test di scenario

    Rispetto alle attivit condotte dagli utenti durante le prove, i test di usabilit possono essere classificati in due grandicategorie: test di compito e test di scenario.

    Neitest di compito, gli utenti svolgono singoli compiti, che permettono di esercitare funzioni specifiche del sistema. Peresempio, nel caso di un sito web di un supermercato:

    Compito 1: Ricerca nel catalogo dei prodotti una scatola di pomodori pelati da 500 grammi;

    Compito 2: Comprane due, pagando con la tua carta di credito;

    Compito 3: Verifica lo stato del tuo ordine precedente.

    Questi test possono essere eseguiti anche quando il sistema non completamente sviluppato. Per esempio, per eseguirela ricerca nel catalogo dei prodotti, non necessario che le funzioni per lacquisto siano gi disponibili. Essi sono tantopi utili quanto pi i compiti riflettono i casi duso reali del sistema. Un errore frequente dei conduttori inesperti quello di suggerire implicitamente agli utenti le operazioni da eseguire, dando loro, in pratica, una serie di istruzioni,invece che un problema da risolvere. Lutente deve, invece, essere posto in situazioni simili a quelle in cui si trovernelluso reale del sistema, quando dovr decidere, da solo, che cosa fare. Se lutente troppo guidato, i problemi diusabilit, anche se presenti, non emergeranno, e il test non sar di alcuna utilit. Per esempio, consideriamo la seguenteriformulazione dei due compiti dellesempio precedente:

    Compito 1: Registrati al sistema, fornendo il tuo indirizzo di email e una password;

    Compito 2: Entra nella sezione per gli acquisti online e ricerca la sottosezione dei prodotti in scatola;

    Compito 3: Ricerca una scatola di pomodori pelati da 500 gr e caricala nel carrello della spesa;

    Compito 4: Conferma lacquisto fornendo questo indirizzo di consegna e questi dati per laddebito su carta di credito.

    Procedendo in questo modo, daremmo allutente troppe indicazioni sul funzionamento del sistema, anche se in modoimplicito. Per esempio, gli faremmo sapere che, per comprare qualcosa, deve prima registrarsi, fornendo come user-id ilsuo indirizzo di posta elettronica. Poi che esiste una sezione per gli acquisti online, e che questa organizzata insottosezioni, una delle quali riguarda i prodotti in scatola. Quindi che per comprare qualcosa bisogna caricarlo nelcarrello, e cos via. Tutte queste informazioni non sono invece disponibili allutente in un contesto di acquisto reale,soprattutto se egli non ha mai utilizzato un sistema simile. In definitiva, in un contesto reale lutente potrebbe incontraredelle difficolt che in un test cos formulato non si presentano mai.

    La seconda categoria costituita dai test di scenario. In questo caso, agli utenti viene indicato un obiettivo daraggiungere attraverso una serie di compiti elementari, senza indicarli esplicitamente. Lutente dovr quindi impostareuna propria strategia di azione. Per un test pi realistico, allutente potr essere indicato uno scenario complessivo chedefinisca meglio il contesto in cui dovr immaginare di muoversi. Per esempio, per il sito del supermercato, lo scenarioproposto agli utenti potrebbe essere il seguente:

    Domani sera hai due amici a cena, ma non hai il tempo di andare al supermercato. Decidi quindi di fare la spesa online,pagando con la tua carta di credito. Collegati al sito e ordina gli ingredienti per una cena veloce e poco costosa, masimpatica.

    Come si vede da questo esempio, i test di scenario possono mettere alla prova lutente (e il sistema) in modo molto pi

    11

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    12/19

    impegnativo dei test di compito. In particolare, permettono agli utenti di utilizzare il sistema in relazione alle propriespecifiche necessit, preferenze e abitudini. Nello scenario indicato, gli utenti terranno conto delle loro preferenzealimentari, e di quelle dei loro amici. Utilizzeranno la loro carta di credito, e chiederanno la consegna al loro veroindirizzo, verificando se questa potr essere effettuata in tempo utile per la cena. Cos, la strategia che gli utentiseguiranno per raggiungere lobiettivo potrebbe essere molto diversa da quella prevista dai progettisti. Per questo

    motivo, i test di scenario possono essere molto utili per individuare eventuali carenze nellimpostazione della strutturacomplessiva dellinterazione, o mancanze di funzionalit utili. Dunque, si dovrebbe cercare di anticipare, per quanto possibile, i test di scenario allinizio del progetto, usando anche prototipi parziali o a bassa fedelt. I test di compitopermettono, invece, una verifica di usabilit pi fine, perch localizzata a specifici casi duso. Quindi possono esserepi utili quando larchitettura funzionale del sistema sia gi ben consolidata, per provare lusabilit di specifichefunzioni.

    indispensabile che le istruzioni agli utenti (lelenco dei compiti da svolgere o la descrizione degli scenari) siano dateper iscritto, nel modo pi chiaro possibile. Solo in questo modo tutti gli utenti partecipanti al test si troveranno nellemedesime condizioni: le spiegazioni date a voce, inevitabilmente diverse di volta in volta, potrebbero influenzare ipartecipanti in modo differente, rendendo i risultati dei test poco confrontabili.

    MisureOltre allosservazione qualitativa dei comportamenti degli utenti, durante un test di usabilit utile raccogliere anchedelle misure oggettive. Quelle pi significative sono il tempo impiegato da ogni utente per lesecuzione di ciascuncompito, e il tasso di successo (success rate), cio la percentuale di compiti che ciascuno riesce a portare a termine.

    Il calcolo del tasso di successo pu tener conto anche dei compiti eseguiti solo in parte. Si consideri, per esempio, il testdescritto in , in cui 4 utenti eseguono 6 compiti. Su 24 compiti, 9 sono stati portati a termine (S), e 4 sono stati eseguitisolo in parte (P). Per i rimanenti, gli utenti hanno fallito (F).

    Figura 13.Sintesi risultati di un test di usabilit

    In questo caso, il tasso di successo potrebbe essere calcolato cos:

    Tasso di successo = (9 + (4 * 0,5)) / 24 = 46%

    In questa formula, ogni successo parziale stato conteggiato, convenzionalmente, come la met di un successo pieno. Ilrisultato di questo calcolo ci dice che gli utenti non sono riusciti a portare a termine pi della met dei compitiassegnati. Questo dato ci d una indicazione piuttosto significativa sulla usabilit del sistema. Esso andrebbe poi megliointerpretato con laiuto di informazioni pi dettagliate sugli utenti e su quali compiti hanno avuto i problemi maggiori.

    Come condurre un test di usabilit

    Come abbiamo gi detto, preferibile che il team che conduce il test sia costituito da almeno due persone. Una avr ilcompito di dirigere le attivit e di interloquire con gli utenti, e nel frattempo verificare che le registrazioni, se vengono

    12

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    13/19

    fatte, procedano correttamente. Laltra osserver con attenzione il comportamento dellutente durante il test, senzainterferire, prendendo appunti sulle situazioni pi significative. Questattivit molto importante, anche nel caso in cuiil test venga registrato. Infatti, lesame di una registrazione pu richiedere molto tempo (diverse ore per ogni ora diregistrazione). Se losservatore ha gi localizzato durante il test i problemi principali, nellanalisi della registrazione sipotr concentrare sui punti critici, con un significativo risparmio di tempo.

    Un test di usabilit viene condotto in quattro fasi successive, come indicato in . Esaminiamole separatamente.

    Figura 14.Le fasi di un test di usabilit

    Pianificazione

    Lorganizzazione di un test di usabilit dipende in modo sostanziale dagli scopi da raggiungere, che dipendono dallanatura del prodotto e dalla strategia della sua realizzazione. Come abbiamo visto nel Capitolo 9, i prototipi prodotti inun ciclo di sviluppo iterativo possono essere di tipo diverso, e dovrebbero essere realizzati in accordo a un piano di

    lavoro definito allinizio del progetto. Il piano dovrebbe specificare la natura e lo scopo di ogni prototipo: i test su diesso dovrebbero essere progettati di conseguenza.

    Anche lo standard ISO 13407 raccomanda che lintero processo di valutazione sia pianificato in anticipo, precisando,tra laltro, quali parti del sistema devono essere valutate e come; quali prototipi dovranno essere realizzati, come deveessere eseguita la valutazione e con quali risorse; quali dovranno essere le interazioni con gli utenti e come dovr esserecondotta lanalisi dei risultati.

    Preparazione del test

    Nella fase di preparazione del test, il team di valutazione deve innanzitutto definire il numero e il profilo degli utenticampione e i compiti (o gli scenari, nel caso dei test di scenario) che si richieder loro di svolgere. Sono decisioni molto

    delicate, poich da esse dipender in larga misura lutilit del test.

    Nel caso di un test formativo inserito nel processo di sviluppo, si seguir spesso la regola di Nielsen di cui abbiamoparlato pi sopra. Il lavoro potr anche essere svolto dagli stessi progettisti, se lo sanno fare, senza il supporto di unesperto di usabilit. Nel caso, invece, in cui il test di usabilit costituisca un evento a s stante, per esempio per valutarelopportunit di interventi migliorativi su un sistema esistente, occorrer unorganizzazione pi robusta. La durata diogni singolo test potr essere pi lunga (ma di solito non durer pi di unora o unora e mezza al massimo per ciascunutente). Il numero degli utenti sar maggiore, tenendo comunque presente che normalmente si ritiene pi produttivo faretanti test con pochi soggetti che pochi test con molti soggetti. In questi casi anche lorganizzazione del team divalutazione dovr essere potenziata. In un test di una certa ampiezza si raccolgono informazioni in grande quantit, e bisogna poi saperne trarre le dovute conclusioni. In questo caso, linserimento nel team di un professionistadellusabilit fortemente consigliabile.

    13

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    14/19

    Proseguendo nella preparazione del test, il team di valutazione decider quindi le misure da raccogliere, e predisporrtutti gli aspetti relativi alla logistica per lesecuzione delle prove (postazione di lavoro e di osservazione, strumenti diregistrazione, e cos via), in modo che queste possano avvenire senza troppi disturbi. Preparer infine i materialinecessari allo svolgimento dei test, e in particolare:

    un modulo per raccogliere le informazioni sugli utenti: informazioni anagrafiche, livello di esperienza,competenze nellambito specifico del sistema;

    il testo con le istruzioni per lo svolgimento delle prove da consegnare agli utenti: la descrizione di compiti escenari dovrebbe essere concisa, ma particolarmente chiara, per evitare chiarimenti e spiegazioni durante losvolgimento della prova;

    la modulistica che gli osservatori utilizzeranno per raccogliere le misure relative allesecuzione di ciascuncompito, e le loro annotazioni durante il test. Questi moduli devono permettere di annotare rapidamente leinformazioni utili, e quindi dovrebbero essere predisposti in funzione delle caratteristiche del test. Per esempio,si possono preparare stampe delle schermate video del sistema, su cui annotare gli aspetti critici, e una tabellacome quella di per raccogliere le misure relative ai singoli utenti e compiti;

    un questionario per le interviste finali degli utenti, di cui parleremo fra poco.

    Esecuzione del test

    La fase di esecuzione del test vera e propria, se tutto gi bene organizzato e ci si limita a un test con pochi utenti, nondura in genere pi di qualche ora complessivamente. Un test pi ampio richieder, al massimo, una o due giornate dilavoro.

    molto importante che, durante il colloquio di spiegazione iniziale con ciascun utente, sia chiarito molto bene chelobiettivo della prova valutare il sistema, e non la capacit dellutente di svolgere bene e rapidamente i compitiassegnati. indispensabile che il facilitatore metta ogni utente a suo agio, per ridurre al massimo lo stress da esameche non sar mai del tutto eliminabile, e che potrebbe compromettere lesito della prova. Bisogna spiegare bene che seuna persona trova difficile usare il sistema, questo non avviene perch incapace, ma perch il sistema progettato

    male. A ogni utente dovr poi essere esplicitamente garantita la riservatezza delle eventuali registrazioni che sarannoeffettuate, che dovranno essere visionabili esclusivamente dai team di valutazione e di progetto, a meno che egli nonfirmi unesplicita liberatoria che autorizzi una diffusione pi ampia.

    I test devono essere condotti singolarmente, un utente alla volta. opportuno prevedere, per ciascuno, un breve periododi familiarizzazione con il sistema, prima del test vero e proprio. Durante lo svolgimento della prova i valutatoridovranno interferire il meno possibile: solo il facilitatore autorizzato a parlare con lutente, e i suoi interventidovranno essere limitati allo stretto indispensabile, per non influenzarne il comportamento. Il suo scopo saresclusivamente quello di rassicurarlo in caso di difficolt, incitandolo a proseguire con tranquillit, senza mai suggerirele azioni da compiere e senza fornire o chiedere spiegazioni. Dovr invece, quando necessario, ricordargli il thinkingaloud, cio di commentare ad alta voce ci che sta facendo: che cosa si propone di fare, che cosa vede sullo schermo,

    come pensa di dover proseguire, quali difficolt sta incontrando, quali dubbi ha, e cos via. Questo sar molto utile agliosservatori che prendono appunti, e che dovranno poi ricostruire, anche con laiuto delle eventuali registrazioni, lecause dei problemi incontrati. Il facilitatore avr poi il compito di interrompere lutente nel caso che, durantelesecuzione di un certo compito, abbia incontrato difficolt che non riesce a superare.

    Al termine del test dusabilit, utile intervistare gli utenti sullesperienza che hanno appena fatto. In queste interviste,che conviene condurre utilizzando un questionario appositamente predisposto, lintervistatore chieder, a ogni utente,quali sono, a suo parere, i punti di forza e di debolezza del sistema, gli aspetti che dovrebbero essere migliorati, e quelliche ha gradito maggiormente. Queste interviste possono fornire ulteriori indicazioni, ma non devono sostituire le proveduso del sistema. Infatti gli utenti si limitano spesso a indicazioni generiche, e sono raramente in grado di individuarecon precisione le cause delle loro dfficolt.

    14

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    15/19

    Analisi dei risultati e proposte migliorative

    Lultima fase del test quella in cui si analizza il materiale raccolto (appunti ed eventuali registrazioni audio/video) e sitraggono le conclusioni. la fase pi delicata, e richiede tempo e grande cura. Anche una sessione di test breve, seriesaminata con attenzione, pu fornire molte informazioni. Ogni gesto, ogni frase, ogni esclamazione dellutente unindizio importante, che va considerato e discusso dal team di valutazione, per individuarne cause e implicazioni.

    Ci sono alcuni errori tipici dei valutatori poco esperti, che vanno evitati. Il primo di limitarsi sostanzialmente ariportare i giudizi espressi dagli utenti nelle interviste successive al test. Questi sono utili, ma costituiscono solo unaporzione abbastanza marginale dei risultati di un test ben condotto. Infatti spesso lutente tende a esprimere giudizi osensazioni di carattere generale (es.: la fase di login troppo complicata e mi chiede informazioni inutili), senzaessere in grado di risalire con precisione a tutte le cause di tali giudizi o sensazioni. Se lo fa, la sua analisi potrebberivelarsi sbagliata: non possiamo pretendere che lutente sia un esperto di usabilit. Pu capitare anche che lutente,dopo una sessione di prova che ha mostrato evidenti difficolt, esprima un giudizio sostanzialmente positivo sulsistema. Quindi il valutatore non deve mai accontentarsi dei commenti degli utenti, ma deve sempre compiere unanalisidiretta e dettagliata dei loro comportamenti, esaminando il materiale registrato o gli appunti presi durante le sessioni diprova. Il secondo errore tipico quello di limitarsi allelencazione di poche difficolt macroscopiche, senza andare in

    profondit. Occorre, invece, elencare analiticamente tutti i problemi individuati, grandi e piccoli: solo cos il test ci daril massimo rendimento.

    Il risultato di questanalisi un elenco dei problemi incontrati nello svolgimento di ciascun compito, descritti in modocircostanziato. A ciascun problema il team di valutazione assegna un livello di gravit, in base a considerazioni di variotipo: il numero di volte che tale problema stato evidenziato nei test, il livello desperienza degli utenti che hannosperimentato il problema, leffetto che il problema ha avuto sul completamento del compito (il problema ha impedito diportarlo a termine, o lutente ha trovato comunque una soluzione o un percorso alternativo che gli ha permesso diarrivare al risultato desiderato?).

    Lelenco dei problemi rilevati sar poi riesaminato per produrre un elenco di interventi proposti per migliorare ilprodotto (o il prototipo). Esse dovranno essere organizzate in diversi livelli di loro priorit, per esempio:

    Priorit 1: intervento indispensabili e urgenti

    Sono interventi per risolvere problemi bloccanti, senza i quali il sistema non pu essere utilizzato per gli scopi percui stato progettato.

    Priorit 2: interventi necessari

    Interventi che risolvono problemi di usabilit gravi, ma che non impediscono allutente di utilizzare il sistema. Peresempio, possono esistere dei percorsi alternativi che permettono comunque allutente di raggiungere i suoiobiettivi.

    Priorit 3: interventi auspicati

    Interventi che risolvono problemi di usabilit di minore gravit. Per esempio, problemi che si verificano insituazioni particolari e poco frequenti, e che comunque sono superabili con difficolt limitate.

    Il rapporto di valutazione

    Lesito di una valutazione di usabilit dovrebbe essere descritto in modo accurato, non solo per test di tipo sommativo,ma anche nel caso dei test effettuati durante il processo iterativo di progettazione e sviluppo. Per questo, si utilizza undocumento chiamato rapporto di valutazione. Esso non solo descrive i risultati dei test effettuati, ma fornisce ancheevidenza del fatto che essi siano stati condotti con metodi adeguati. In particolare, che gli utenti utilizzati nelle provesiano rappresentativi delle categorie identificate nei requisiti e che siano in numero adeguato, che i test effettuati sianosufficienti per fornire indicazioni attendibili nei vari casi e contesti duso e, infine, che siano stati usati metodiappropriati sia nella conduzione del test sia nella raccolta dei dati.

    Lo standard ISO 13407 identifica tre tipi fondamentali di rapporti di valutazione, a seconda che il loro scopo sia fornirefeedback per la progettazione, o provare la conformit a specifici standard oppure, infine, fornire evidenza del

    raggiungimento di obiettivi human-centred, per esempio in termini di usabilit o salute o sicurezza per lutente.

    15

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    16/19

    Uno schema generale per la stesura del rapporto di valutazione, un po pi semplice di quello suggerito dallISO 13407,pu essere il seguente.

    Identificazione del documento

    Riportare i nomi degli autori, la data e la versione del documento.

    Sommario

    Riportare una sintesi dello scopo del documento e delle sue conclusioni.

    Prodotto valutato

    Descrivere brevemente il prodotto o il prototipo sottoposto a test, con ogni informazione che lo identifichi con precisione.Indicare le aree funzionali sottoposte al test.

    Obiettivi della valutazione

    Descrivere gli obiettivi specifici perseguiti nella valutazione descritta nel documento.

    Metodologia utilizzata

    Specificare quanti utenti hanno partecipato al test, il loro livello di esperienza e le loro caratteristiche in relazione alprodotto in esame. Specificare i compiti o gli scenari assegnati, il contesto in cui si svolto il test e la strumentazioneutilizzata. Descrivere come stato condotto il test e da chi, quanto tempo durato (per ciascun utente e complessivamente),quali misure sono state raccolte, il ruolo degli osservatori e come sono stati analizzati i risultati.

    Sintesi delle misure

    Fornire una tabella di sintesi delle misure raccolte. Per esempio, i tempi di esecuzione e la percentuale dei vari compiti chesono stati portati a termine con successo, complessivamente e per ciascun utente. Aggiungere commenti ove opportuno.

    Analisi dei risultati

    Descrivere analiticamente i problemi incontrati da ciascun utente durante il test, compito per compito, allegando oveopportuno degli screen shot significativi e assegnando ad ogni problema un livello di gravit. Ogni problema sar

    numerato, per un pi facile riferimento. Descrivere in dettaglio, se significativi, reazioni e commenti degli utenti, registratidurante le prove. Questa la sezione principale del documento, e dovr contenere tutte le informazioni utili a formulare i

    possibili interventi per rimuovere i problemi descritti, senza che sia necessario tornare a esaminare il prodotto. Consisterin genere di molte pagine.

    Sintesi delle interviste agli utenti

    Sintetizzare i risultati delle interviste effettuate a ciascun utente dopo lesecuzione del test.

    Raccomandazioni

    Inserire la descrizione analitica degli interventi migliorativi proposti, raggruppati per livelli di priorit (per esempio: priorit 1: interventi indispensabili e urgenti; priorit 2: interventi necessari ma meno urgenti; priorit 3: interventiauspicati). Per ogni intervento proposto si far riferimento al problema relativo, descritto nella sezione precedente. Gli

    interventi saranno numerati, per una facile tracciabilit.

    Allegati

    Allegare i moduli anagrafici compilati dagli utenti, la descrizione dei compiti/scenari data agli utenti prima del test, e tutti iquestionari compilati nelle interviste finali. Allegare anche il materiale rilevante prodotto durante il test (per esempio, leriprese video).

    Test di usabilit: costi e benefici

    Qualunque sia la tecnica utilizzata, i test con gli utenti sono indispensabili. Infatti, le cause delle difficolt incontrate

    dagli utenti possono essere moltissime. Analizzare un sistema a tavolino, come nelle valutazioni euristiche, anche se

    16

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    17/19

    pu permetterci dindividuare numerosi difetti, non mai sufficiente. I problemi possono essere nascosti e verificarsisoltanto con certi utenti, in relazione alla loro esperienza o formazione. Cose ovvie per chi gi conosce il sistema osistemi analoghi possono rivelarsi difficolt insormontabili per utenti meno esperti. Un test di usabilit ben condottomette subito in evidenza queste difficolt. La necessit del coinvolgimento degli utenti affermata con chiarezza dallastessa ISO 13407:

    La valutazione condotta soltanto da esperti, senza il coinvolgimento degli utenti, pu essere veloce ed

    economica, e permettere di identificare i problemi maggiori, ma non basta a garantire il successo di un

    sistema interattivo. La valutazione basata sul coinvolgimento degli utenti permette di ottenere utili indicazioni

    in ogni fase della progettazione. Nelle fasi iniziali, gli utenti possono essere coinvolti nella valutazione di

    scenari duso, semplici mock-up cartacei o prototipi parziali. Quando le soluzioni di progetto sono pi

    sviluppate, le valutazioni che coinvolgono lutente si basano su versioni del sistema progressivamente pi

    complete e concrete. Pu anche essere utile una valutazione cooperativa, in cui il valutatore discute con

    lutente i problemi rilevati.

    In Italia i test di usabilit sono ancora poco praticati. I motivi principali sono due. Il primo senzaltro costituito

    dallinsufficiente diffusione di una cultura dellusabilit, sia presso gli utenti sia presso gli stessi progettisti Lasensibilit verso questi problemi tuttora molto bassa, e gli esperti di usabilit, nelle universit e nelle aziende, sonopochi. Il secondo motivo che si sostiene i test di usabilit costano troppo. Si tratta di una convinzione diffusa masbagliata: i test di usabilit si possono fare rapidamente e con costi veramente molto contenuti. Un test di usabilit benstrutturato, di tipo sommativo, pu coinvolgere 10-15 utenti, o pi. Ma, come abbiamo visto, i test di tipo formativopossono essere fatti in modo molto pi snello, con ottimi risultati.

    Esiste anche un terzo motivo che a volte viene addotto per non fare test di usabilit. Si sostiene, in sostanza, che i test diusabilit non ci danno dei risultati oggettivi, ma ci segnalano soltanto le risposte soggettive di determinati individui difronte al sistema. Questa la tipica reazione di autodifesa dei progettisti: la colpa dei problemi non nel sistema, diquel particolare utente, che non capace di usarlo come dovrebbe. Altri utenti, pi in gamba, non incontrerebberodifficolt. Il ragionamento insidioso, perch, apparentemente, difendibile. Pi o meno, questo: test scientifici, conrisultati statisticamente validi, dovrebbero coinvolgere moltissimi utenti: almeno molte diecine. Questo non si pu fare,sarebbe troppo lungo e costoso. I test con pochi utenti non sono significativi: le persone sono troppo diverse lunadallaltra. Perch dovremmo dar peso alle reazioni soggettive di pochi individui e avviare costose modifiche soltantosulla base di queste reazioni?

    Il fondamento di queste obiezioni formalmente inappuntabile: un esperimento o condotto con il necessario rigore, o inutile: non permette di trarre alcuna conclusione valida. Ma dal punto di vista pratico non regge: un test di usabilit a meno che non sia condotto su una popolazione vasta di utenti e con metodi statistici rigorosi, il che non succede praticamente mai non un esperimento scientifico, fatto per confermare determinate ipotesi. Il suo scopo diverificare le reazioni di certi soggetti a determinati stimoli. Queste reazioni sono un fatto oggettivo, si possono vedere eregistrare con la telecamera. Anche le reazioni di pochi individui ci possono insegnare qualcosa, se opportunamente

    decodificate e interpretate. Ed soprattutto questanalisi e interpretazione ci che interessa, e che d valore al test. Essaci fornisce una comprensione migliore del nostro sistema, e di come pu essere usato. Dai test di usabilit possiamoscoprire aspetti che abbiamo trascurato nella progettazione e che possiamo migliorare.

    Peraltro, in un tipico test di usabilit, molto spesso il conduttore non ha bisogno, per cos dire, di leggere fra le righe.In genere, quando ci sono dei problemi, le reazioni degli utenti sono evidenti, a volte addirittura scomposte, e disignificato inequivocabile. Per capire perch necessario fare test di usabilit dobbiamo vederne qualcuno. Leggerne suun report scritto pu non bastare a convincerci. Ma altra cosa vedere con i nostri occhi una persona in carne e ossa,che ha accettato di sottoporsi al test, e che si mostra gentile, disponibile, interessata e volonterosa e che, dopo diversitentativi non riesce a portare a termine un compito, e allora si fa rossa in viso, balbetta frasi incoerenti, e poi abbandonasbattendo, con un gesto di stizza, il mouse contro il tavolo Queste reazioni, nella loro specificit certamentesoggettive e individuali, costituiscono comunque un dato oggettivo, che non possiamo trascurare. Le difficoltmacroscopiche emergono subito, anche con pochi utenti, e questo il senso della regola di Nielsen. Diverso il caso

    17

  • 8/3/2019 P Cap.14: Valutare l'usabilit

    18/19

    dei problemi minori, in cui le differenze di esperienza fra i vari utenti possono contare molto. In questi casi possonoessere necessari molti test e molti soggetti e, soprattutto, una buona esperienza e capacit di analisi da parte degliosservatori.

    In conclusione, i test di usabilit sono parte necessaria e ineliminabile del processo di progettazione e sviluppo di unsistema interattivo. Lusabilit non un optional che si possa eliminare per abbassare i costi, come gli accessori in

    unauto economica. Cos come non si possono eliminare i test per verificare il corretto funzionamento del software.Molto semplicemente, se il prodotto poco usabile, o non funziona, gli utenti non lo useranno.

    Altre tecniche di valutazione

    In questo capitolo, coerentemente con la natura introduttiva di questo libro, ci siamo limitati a descrivere le due tecnicheprincipali di valutazione dellusabilit di un sistema interattivo: le valutazioni euristiche e i test di usabilit con gliutenti. Sono due tecniche di carattere generale, che hanno lo scopo di individuare i principali problemi di usabilit di unsistema. Le abbiamo descritte con finalit essenzialmente pratiche, enfatizzando le tecniche che ci permettono diraggiungere risultati utili in fretta e a costi limitati (discount usability). Indagini su aspetti pi specifici andrannocondotte con tecniche apposite, per esempio effettuando studi sul campo, oppure indagini mirate attraverso interviste o

    focus group, oppure ancora esperimenti di laboratorio con utenti scelti in modo statisticamente rappresentativo.In particolare, la conduzione di esperimenti di laboratorio condotti con metodologie rigorose su campionirappresentativi di utenti costituisce oggi uno strumento importante per lavanzamento delle conoscenze sullusabilit esui principi della Human-Computer Interaction in generale. Possiamo affermare che la HCI possiede due anime, moltodiverse ma ugualmente importanti e complementari: unanima progettuale e unanima sperimentale. La prima ci porta aconcepire, progettare e realizzare soluzioni e strumenti nuovi; la seconda ci permette di verificarne, sperimentalmente,la validit. quindi comprensibile che una parte rilevante degli studiosi di questa disciplina si occupi della conduzionedi esperimenti condotti con tecniche scientifiche rigorose. Queste richiedono competenze specifiche, anche di statistica,che esulano dagli scopi di questo libro, e per le quali rimandiamo ai testi specializzati.

    Ripasso ed esercizi

    1. Descrivi sinteticamente il metodo delle ispezioni per valutare lusabilit di un sistema, specificandonevantaggi e svantaggi.

    2. Che cosa sintende per valutazione basata su euristiche? Quali sono i vantaggi e gli svantaggi?

    3. Descrivi sinteticamente il metodo di ispezione dellusabilit di un sistema basato sulle euristiche diNielsen.

    4. Applicando il metodo di valutazione basato sulle euristiche di Nielsen, come valuteresti lusabilit deicomandi (esterni e interni) dell'ascensore di casa tua, e perch?

    5. Qual la differenza fra i test di compito e di scenario? E fra test formativi e sommativi?

    6. Che cosa la tecnica del "thinking aloud"? Perch la si usa spesso?

    7. Riassumi e motiva la regola di Nielsen.

    8. Devi organizzare un test di usabilit di un nuovo modello di penna stilografica. Come lo organizzi e loconduci?

    9. Quali misure si raccolgono normalmente durante un test di usabilit? A che cosa servono?

    10. Che cosa si intende per discount usability?

    Approfondimenti e ricerche

    1. Cerca su http://www.youtube.com esempi di registrazioni di test di usabilit di vario tipo (prototipi di carta,dispositivi mobili, applicazioni per personal computer). Puoi iniziare con i video prodotti dagli studenti chehanno usato questo libro, cercando le seguenti parole chiave: test usabilit, usability test, polillo.

    2. Per una interessante discussione retrospettiva sulla discount usability, si veda la Alertbox del settembre 2009 diJakob Nielsen: Discount Usability: 20 years del settembre 2009, sul suo sito

    18

    http://www.youtube.com/http://www.youtube.com/
  • 8/3/2019 P Cap.14: Valutare l'usabilit

    19/19

    http://www.useit.com/alertbox/discount-usability.html.

    3. Ricerca in rete un software gratuito per gestire i test di usabilit, e sperimentalo. Per esempio, puoi utilizzareMorae (http://www.techsmith.com), uno dei prodotti pi noti. Non gratuito, ma permette prove gratuite perun periodo limitato.

    19

    http://www.useit.com/alertbox/discount-usability.htmlhttp://www.techsmith.com/http://www.useit.com/alertbox/discount-usability.htmlhttp://www.techsmith.com/