5. Test di Usabilità
5.1. Valutare l’usabilità
Figura 5.1 La valutazione all’interno del ciclo di sviluppo iterativo
Come già spiegato nel capitolo 3, il ciclo di sviluppo iterativo prevede una continua creazione di prototipi, che verranno ogni volta valutati conducendo
dei test sugli utenti dopodiché verranno modificati e raffinati sulla base delle indicazioni ottenute, fino a che il risultato non si rileverà soddisfacente.
Una volta conclusa la fase di prototipazione, verrà cominciata la fase di sviluppo del prodotto finale, che una volta completato sarà valutato di nuovo con un test molto approfondito per verificarne l’effettiva rispondenza alle specifiche di usabilità.
Infine, nel caso specifico dei siti Internet, dovrebbero essere condotti ciclicamente dei test di usabilità anche dopo che il sito è stato completato, per controllare la necessità di modifiche e/o aggiornamenti, dato che spesso le esigenze degli utenti cambiano nel tempo.
La metodologia U.C.D. mette quindi al centro del processo di produzione l’utente, che viene continuamente consultato per avere delle valutazioni sul prodotto, anche in corso d’opera e a volte anche a opera conclusa. Di conseguenza, la fase di valutazione ha un’importanza fondamentale perché all’interno del ciclo di processo viene usata come metrica per decidere la bontà del lavoro finora svolto. In base a tali risultati, si decide se proseguire e come proseguire, quindi è basilare che la valutazione sia affidabile.
Tuttavia la valutazione viene eseguita iterativamente su prototipi sempre più raffinati, fino ad arrivare alla valutazione del prodotto finale. Dovendo minimizzare le risorse necessarie, è plausibile effettuare valutazioni meno accurate (e quindi meno costose) quando si lavora su un prototipo ancora
“grezzo” , mentre sarà necessaria una valutazione molto dettagliata nelle fasi conclusive, quando bisognerà decidere se il prototipo/prodotto finale è da considerarsi soddisfacente o meno.
Negli ultimi anni sono state ideate e descritte diverse metodologie di valutazione, ognuna ha i suoi pregi e i suoi difetti e pertanto può rivelarsi più utile in una certa fase del progetto e meno in altre. Nel prossimo paragrafo descriveremo le più utilizzate e quindi discuteremo su quella che più si adatta al caso nostro.
5.2. Metodologie di test
I metodi utilizzati in fase di valutazione sono numerosissimi ed è facile confondersi, anche perché la loro denominazione non è univoca; inoltre per ciascuno di questi ne esistono numerose varianti. Tuttavia è possibile operare una distinzione in base all’approccio e alle tecniche adottate. Una prima distinzione è quella tra metodi automatici (Validatori di codice ) e semiautomatici (Analisi del log ), che forniscono indicazioni sui difetti di usabilità con un coinvolgimento limitato da parte dell’analista umano, e metodi “manuali” che comportano invece un lavoro di preparazione, test e analisi dei dati.
Tra i metodi “manuali” è possibile tracciare una linea di demarcazione tra quelli legati alla valutazione da parte di esperti e quelli basati su un’esperienza effettiva dell’utente col prodotto (o un suo prototipo). Questi due approcci, se applicati correttamente, possono essere complementari perché individuano problemi differenti.
Tra i metodi che si basano sul giudizio degli esperti, possiamo distinguere quelli che si basano su una serie di principi e linee guida (Valutazione euristica e CELLO ), quelli che si basano su un’analisi del compito (Cognitive walktrough ), quelli che coinvolgono nel lavoro di analisi i rappresentanti degli utenti (Walktrough collaborativo ).
Questi metodi hanno in comune lo stile di presentazione dei dati, che in maniera sintetica riporta accanto ad ogni problema il principio (o euristica) e il compito a cui si riferisce, assieme al grado di severità stimato.
Tra i metodi che invece si basano sull’esperienza effettiva dell’utente, includiamo quelli che misurano la performance dell’utente (Valutazione qualitativa e quantitativa , Valutazione collaborativa , Valutazione partecipativa ) e la sua soddisfazione. Tra quest’ultimi, possono essere annoverati i Questionari psicometrici (come il SUMI e il WAMMI) e il Focus
Group . Avevamo infatti visto che l’usabilità di un prodotto poteva essere scomposta in 3 sottoattributi più facili da misurare (efficacia, efficienza e soddisfazione), e infatti i test condotti direttamente sugli utenti riportano dei dati utili a quantificare uno o più di questi attributi.
Per brevità ci limitiamo a racchiudere in una tabella riassuntiva tutti i metodi finora introdotti, accompagnati da una breve descrizione.
METODO OBIETTIVO
METODI AUTOMATICI E SEMI-AUTOMATICI Analisi degli accessi (log-analysis)
Ha un ruolo di supporto rispetto ad altri tipi di valutazione, nell’ottica del “monitoraggio” continuo
Validatore automatico di usabilità Ispeziona il codice delle pagine web e ne valuta l’usabilità
METODI DI VALUTAZIONE ESPERTA Valutazione euristica
Valuta il prototipo in base a delle euristiche
CELLO Valuta il prototipo in base a principi
concordati da esperti Walktrough partecipativo
Identifica i problemi dei modelli concettuali con la partecipazione degli utenti
Cognitive Walkthrough Simula a livello cognitivo l'utilizzo da parte dell’utenza
METODI DI VALUTAZIONE DELLA PERFORMANCE DELL’UTENTE Valutazione cooperativa
Incoraggia team di design e utenti a collaborare all’identificazione dei problemi
Valutazione partecipativa
Individua problemi relativi alla struttura dei compiti assieme agli utenti
Valutazione qualitativa dell’esperienza dell’utente
Fornisce indicazioni al processo di design
Valutazione quantitativa e qualitativa dell’esperienza dell’utente
Valuta se siano stati raggiunti gli obiettivi
quantitativi e qualitativi di usabilità METODI DI VALUTAZIONE DELLA SODDISFAZIONE DELL’UTENTE
Questionari psicometrici (SUMI – WAMMI)
Valutano la soddisfazione
dell’utente nell’uso di un prodotto e operano un benchmarking
Focus Group
Riunisce un sottoinsieme di stakeholder in una discussione informale di gruppo, in presenza di un moderatore
Tabella 5.1
I metodi automatici e semi-automatici danno i risultati meno affidabili, ma hanno il pregio di essere poco costosi (anche in termini di risorse umane) e quindi si rivelano particolarmente utili a monitorare il sito anche dopo il suo rilascio (nell’ottica del miglioramento continuo), quando non è più possibile contare sui test approfonditi o sul parere degli esperti.
I metodi di valutazione esperta sono utilizzati soprattutto nelle fasi preliminari del progetto, quando è necessario stabilire le specifiche e gli obiettivi di usabilità del prodotto finale. Nel nostro caso, per realizzare la specifica di cui al capitolo 3 ci siamo avvalsi un po’ di tutte e 4 le tecniche sopraelencate, e in particolare della valutazione euristica. Avevamo infatti selezionato un insieme di linee guida (tra la moltitudine presente in letteratura) che abbiamo poi preso come riferimento nello stendere le specifiche e successivamente nella progettazione del prototipo.
Infine, i metodi della valutazione della performance e della soddisfazione dell’utente sono quelli più utili a condurre i test sui prototipi e sulla versione finale, infatti abbiamo più volte sottolineato l’assoluta necessità di incentrare la valutazione sugli utenti veri e propri, piuttosto che affidarsi ad esperti e linee guida.
In particolare i test più qualitativi si rivelano adatti a valutare le versioni iniziali dei prototipi, presumibilmente ancora ricche di errori e quindi di modifiche da effettuare. I test in questo caso devono solo aiutare a identificare i problemi più grossolani, non c’è ancora esigenza di ottenere
dei risultati quantitativi dato che il prototipo presumibilmente dovrà subire ancora numerose modifiche.
Man a mano che il prototipo viene raffinato invece gli errori diventano sempre più difficili da trovare, quindi è necessario raffinare anche i test, fino ad arrivare a delle valutazioni quantitative (utili soprattutto per le versioni finali) che potranno essere confrontate con le specifiche di inizio progetto, con i risultati ottenuti con versioni precedenti e/o alternative, ecc.
Nel nostro caso la metodologia più adatta è senza dubbio quella qualitativa, dato che siamo ancora alle fasi iniziali del progetto.
5.3. Valutazione qualitativa condotta sugli utenti
Adesso che abbiamo scelto una metodologia di test, entriamo nel dettaglio di come si conducono le valutazioni dirette sugli utenti.
5.3.1. Descrivere i compiti oggetto di valutazione
Sia per i metodi che implicano una valutazione esperta, che per quelli che invece implicano una valutazione di un’esperienza reale dell’utente, è opportuno preparare la descrizione della serie dei compiti che devono essere eseguiti.
Questi compiti devono essere rappresentativi dell’esperienza d’uso del sistema e vanno definiti sulla base degli obiettivi e degli scenari definiti precedentemente.
In mancanza di questi è opportuno disporre dei risultati dell’analisi dei compiti o almeno della specificazione delle caratteristiche generali del prodotto. Per le applicazioni basate su sistemi di rete, come il web, è particolarmente utile l’analisi del file di log.
La serie di compiti deve considerare il tempo a disposizione per ogni singola sessione e specificare chiaramente i risultati che devono essere raggiunti.
All’utente questi compiti vanno consegnati in forma scritta, preferibilmente sotto forma di scheda; inoltre gli deve essere data la possibilità di fare domande con calma se la descrizione di questi non fosse chiara. Nella valutazione di obiettivi orientati alla performance di utenti esperti, è possibile utilizzare la serie di compiti per aumentare la confidenza degli utenti col sistema e simulare così una parabola di apprendimento.
Bisogna sempre tenere presenti gli aspetti etici dei metodi che si basano sulla valutazione degli esseri umani. Questi metodi infatti esercitano una notevole pressione sul soggetto, che si sente valutato e scrutato, anche quando si assicura che la valutazione riguarda il sistema e non lui; è giusto operare in tutti i modi per allentare questa pressione psicologica.
I compiti vanno sempre inseriti all’interno di una “sceneggiatura”, di uno script comprensibile al soggetto del test. La sceneggiatura deve descrivere lo scenario simulato con una particolare attenzione non solo agli obiettivi di ciascun compito ma anche a quelli generali.
Inoltre inserire un compito semplice all’inizio può comportare una gratifica che mette il soggetto a suo agio nell’esecuzione dei compiti successivi, mentre l’ultimo compito dovrebbe chiudere lo script completando in maniera chiara gli obiettivi generali. Ad esempio, per un’applicazione web la conclusione potrebbe essere la stampa di una pagina o il raggiungimento della transazione.
5.3.2. La scelta degli utenti
Una volta stabilito il compito da assegnare durante il test, è necessario stabilire il numero di partecipanti e selezionarli, in modo che rappresentino un campione il più rappresentativo possibile della popolazione di utenti reale.
Ovviamente, il numero di utenti da coinvolgere dipende dal tipo di test che si vuole effettuare. Per test quantitativi, sono necessari almeno 20 utenti
perché i risultati abbiano una qualche rilevanza statistica, quindi questi test possono rivelarsi piuttosto costosi (in termini di tempo, denaro e risorse umane impiegate) e andrebbero condotti solo sulle versioni finali del prodotto.
Per le versioni iniziali invece, che presumibilmente dovranno essere testate molte volte, è necessario risparmiare sui costi e quindi ci si accontenta di test più qualitativi. Del resto, sarebbe inutile condurre test molto accurati su versioni del prototipo ancora molto lontane da quella finale.
Nielsen a questo proposito ha condotto un enorme numero di prove per stabilire quale fosse il numero ottimale di utenti da utilizzare, e secondo i suoi risultati il rapporto tra numero di persone coinvolte e problemi di usabilità riscontrati ha un andamento come quello riportato nella figura qui sotto.
Figura 5.2 Andamento del grafico N° di problemi di usabilità trovati / N° di utenti coinvolti
Il grafico evidenzia come sopra una certa soglia non si abbiano più miglioramenti apprezzabili, quindi secondo Nielsen è inutile utilizzare troppi
soggetti perché l’aumento dei costi non giustifica più il miglioramento dei risultati.
In particolare dal grafico si evince che con 13 utenti si rileva circa la totalità degli errori riscontrabili: anche avendo risorse a sufficienza, è altamente sconsigliabile salire sopra questa soglia, sarebbe molto meglio casomai ripetere i test sulla versione successiva piuttosto che condurre un unico, accuratissimo test.
Le modifiche al prototipo infatti difficilmente risolveranno in una sola volta tutti i problemi, anzi, spesso per risolverne uno se ne introducono altri e a volte la situazione può addirittura peggiorare anziché migliorare. Per questo il ripetersi ciclico dei test è alla base del processo di sviluppo iterativo, quindi è sempre preferibile condurre più test con pochi utenti piuttosto che pochi test con molti utenti.
In particolare Nielsen consiglia di non salire sopra i 5 utenti: sempre dal grafico precedente si evince che con soli 5 utenti si scoprono già l’85% dei problemi di usabilità. Secondo la sua esperienza, aumentando il numero dei soggetti si rischia soltanto di perdere tempo vedendo ripetersi sempre gli stessi risultati, quindi almeno nei primi test (quelli più qualitativi) ci si può senz’altro accontentare di un numero esiguo di utenti.
Nel caso (molto frequente) che gli utenti siano divisi in più categorie, è consigliabile però avere almeno 3 esponenti per ognuna, in modo da coprire adeguatamente tutta la popolazione. Nella nostra tesi abbiamo deciso di utilizzare un totale di 12 utenti, divisi nel seguente modo: 6 “cittadini” (di cui 3 esperti e 3 non esperti) e 6 “imprenditori” (di cui 3 esperti e 3 non esperti). Trattandosi di un test molto qualitativo, condotto sulla prima versione del prototipo, si tratta senz’altro di un numero rilevante.
5.3.3. Fasi della valutazione
La procedura per una valutazione di usabilità comporta normalmente quattro stadi:
1) Preparazione
Nella fase di preparazione ci si assicura di avere tutti gli strumenti e i materiali a disposizione prima dell’inizio del test e che questi siano perfettamente funzionanti, per evitare che fattori di disturbo invalidino i risultati dei test.
2) Introduzione ( Brief )
Lo sperimentatore saluta il soggetto e dà una breve spiegazione degli scopi della valutazione e eventualmente degli strumenti informatici utilizzati.
Gli vengono quindi spiegate le caratteristiche della procedura di test:
· Lo scopo del test non è di valutare l’utente ma il sistema;
· Lo sperimentatore non è il designer del sistema; si possono fare liberamente commenti su di esso senza timore di “urtarlo”;
· Le informazioni ottenute con questa procedura vengono utilizzate esclusivamente a fini di analisi; in particolare quelle personali rimangono strettamente confidenziali;
· Eventualmente, mostrare e spiegare il motivo della presenza di sistemi di osservazione e registrazione; far firmare una delibera sul loro uso, ricordando che questo verrà fatto solo a fini di analisi;
· Spiegare che i commenti e le domande sono ben volute, precisando tuttavia che lo sperimentatore non potrà rispondere alla maggior parte di queste durante il test per non compromettere la validità dei
risultati;
· Istruzioni specifiche per il metodo di valutazione condotto, come ad esempio il “pensare ad alta voce” (thinking aloud ) per la valutazione cooperativa.
3) Conduzione del test
Durante l’interazione, lo sperimentatore dovrebbe evitare qualunque movimento, gesto o parola che potrebbero significare anche implicitamente un atto di valutazione positiva o negativa. Non deve nemmeno aiutare il soggetto, a meno che questo non sia bloccato in qualche situazione senza uscita. In questo caso lo sperimentatore può indicare all’utente un modo per ricominciare il compito o passare a quello successivo.
Alcune buone domande e interventi corretti:
· Potresti dirmi a cosa stai pensando?
· Continua a parlare
· Non scoraggiarti, tenta ancora
· Qual è il tuo obiettivo?
· Che cosa ti aspetti dopo aver fatto questo?
· Questo... può aiutarti a raggiungere il tuo obiettivo?
· Puoi farmi tutte le domande che vuoi, ma non potrò fornirti le risposte
· Prova a pensare ad alta voce quanto più ti è possibile.
· Comportati come se io non ci fossi
· Fai tutto quello che faresti come se dovessi eseguire il compito da solo, in silenzio
· Qual'è la tua prima impressione, dando un'occhiata a questa pagina?
· Mi hai detto che questa pagina ti piace molto, ma cosa ti piace di più in essa?
Alcune domande da evitare:
· Perchè hai cliccato su quel tasto? (insinua nell'utente il dubbio di aver sbagliato)
· A cosa serve quel bottone? (si porta l'utente a concentrare la sua attenzione su di un aspetto della UI che stava trascurando)
· Ti piace questa pagina?
· Ti aspettavi forse che il tasto cambiasse colore al passaggio del
mouse? (si offre all'utente un'interpretazione preconfezionata dei suoi pensieri)
Se sono presenti altri osservatori oltre allo sperimentatore, questi devono stare in silenzio per tutta la durata del test per non influenzare il soggetto.
4) Termine ( Debrief )
Al termine della fase di test viene eventualmente consegnato il questionario per la valutazione degli stati soggettivi. Dopo aver terminato il questionario, il soggetto può fare domande o commenti sulla procedura di test o sul sistema.
Infine lo sperimentatore dovrebbe annotare tutte le impressioni in fondo alla scheda di rilevazione.
5.3.4. Il laboratorio
Spesso i test vengono condotti in laboratori d’usabilità. Questi luoghi sono equipaggiati di diverse telecamere e di dispositivi di registrazione; vi sono anche dei grandi specchi unidirezionali, a prova di suono, che separano la stanza per le osservazioni dalla stanza in cui si svolge il test (in Figura 6.3, più sotto, Test room e Observation Room ).
Figura 5.3 Pianta di un ipotetico laboratorio di usabilità (Nielsen, 1933)
Ciò rende possibile ad esempio la discussione tra sperimentatori e gli sviluppatori senza disturbare la sessione di valutazione. Una seconda stanza di osservazione (Executive observation lounge ) rende possibile invece un’ulteriore discussione, ad esempio tra sviluppatori e manager, senza infastidire le procedure di registrazione nell’altra sala.
Ovviamente non è necessario utilizzare una struttura così costosa. Per condurre una valutazione è sufficiente infatti convertire un paio di stanze temporaneamente con una quantità di attrezzatura minima, che può essere trasportata facilmente. Per registrare o visualizzare le immagini che compaiono sullo schermo dell’utente in un altro dispositivo (Figura 6.4, a), come un VCR o Monitor, basta un apparecchio (b) che divide il segnale video (video splitter); in maniera altrettanto economica è possibile registrare anche il segnale audio (c).
Figura 5.4 Configurazione minima per l’allestimento di un Laboratorio
In realtà se lo scopo è solo scoprire la presenza dei problemi non è necessario alcun tipo di registrazione; durante l’osservazione questi sono già abbastanza evidenti. L’uso di un dispositivo di registrazione ha invece altri vantaggi: innanzitutto è possibile fare un’analisi dell’impatto dei difetti di usabilità. In una prima fase infatti vengono rilevati una serie di problemi;
in una seconda fase vengono rivisti i nastri per rilevare quanti utenti del campione hanno avuto quello specifico problema, quante volte e quanto a lungo.
Le analisi dell’impatto vengono utilizzate, assieme ad altri fattori, per determinare le priorità nella correzione dei difetti sulla base di dati più precisi rispetto a quanto avviene nella valutazione esperta.
5.4. I nostri test
Dopo aver specificato e formalizzato le caratteristiche richieste dal nostro sito, abbiamo anche creato un prototipo in modo da poter condurre i primi test di usabilità.
Il prototipo, pur essendo alla versione iniziale, è già abbastanza dettagliato:
in particolare la home page offre già tutte le funzionalità previste, e a partire da questa sono state realizzate anche le principali sottopagine e
infine anche 4 servizi (due dei quali molto complessi) nella loro completezza. Il prototipo quindi ha già una completa orizzontalità e una buona verticalità, questo ci ha permesso di condurre dei test piuttosto articolati.
Come abbiamo già accennato nei paragrafi precedenti, i test condotti nelle fasi iniziali della progettazione sono esclusivamente qualitativi, utilizzano un numero ridotto di utenti (generalmente 5, oppure 3 per ogni categoria) e hanno come scopo principale quello di individuare gli errori e le possibili migliorie. Quindi tra i risultati non vengono mai riportati dati numerici (che sarebbero anche scarsamente significativi visto il campione esiguo di utenti) e di conseguenza non è possibile il confronto tra test diversi. Questo ovviamente perché almeno nella fase iniziale non è richiesta una grande accuratezza, quindi è opportuno risparmiare sui tempi e sui costi.
Nei nostri test abbiamo seguito questa linea, tuttavia avendo a disposizione un prototipo che, pur nella sua versione iniziale, ha già un buon grado di funzionalità, abbiamo potuto condurre fin da subito diverse prove, alcune anche piuttosto complesse.
5.4.1. Breve descrizione del pr ototipo
Nella figura 5.5 è riportata una prima immagine della home page, estratta dal prototipo. Come si può vedere abbiamo scelto la classica struttura a
“ferro di cavallo” (un menù verticale a sinistra, uno orizzontale in alto, un altro verticale a destra).
La parte in alto è fissa in ogni pagina, e contiene il logo comunale (che permette di intuire velocemente la mission del sito anche a chi ci arriva per
“caso” o comunque senza passare dall’home page) e dei riferimenti fissi alle funzioni più importanti (ricerca nel sito, mappa, link alla home page, alla pagina dei contatti e a quella di help).
La parte centrale invece è stata suddivisa in 3 “schede” rivolte alle 3 principali categorie di utenti: cittadini, imprese e turisti. Le schede sono accompagnate da una breve descrizione testuale, e in più utilizzano il colore e le immagini per attrarre l’attenzione dell’utente (soprattutto di quelli alle prime armi, che potrebbero essere disorientati nelle prime visite). Ogni scheda infatti porta al “cuore” del sito, ovvero alla home page dedicata a quella particolare categoria di utente, dalla quale si potrà poi accedere ai servizi.
Il resto della parte centrale è invece occupato da un messaggio di benvenuto, che introduce al Comune e ai contenuti del sito, e dalle news .
Figura 5.5 La home page del prototipo
La struttura della home page è quindi molto comune, l’organizzazione dei contenuti è piuttosto semplice e poco dispersiva (occupa una sola videata in 800x600) e di conseguenza aiuta l’utente ad orientarsi velocemente.
Oltre alla pagina principale, sono state implementate anche le home page dedicate ai cittadini e alle imprese, la parte relativa al turista è stata invece
per adesso trascurata. La motivazione è semplice: il turismo è un settore nel quale ogni comune può essere pensato in concorrenza con gli altri, quindi è meno opportuno proporre un layout standard. Al contrario, ognuno vorrà differenziarsi per emergere dalla concorrenza.
Tornando alle home page dei cittadini e delle imprese, ciascuna introduce i servizi disponibili, offrendo diverse modalità di navigazione: per eventi della vita, in ordine alfabetico, per servizi più utilizzati, oppure attraverso un motore di ricerca.
L’opzione più in vista è ovviamente quella per eventi della vita, che è anche quella consigliata dal Governo.
Nella parte in alto della pagina centrale, sotto le “schede”, compare il percorso di navigazione e le opzioni di navigazione disponibili in quel momento (che restano sempre a portata di mano).
Figura 5.6 La home page del cittadino
I servizi finora implementati sono 4, ma coprono le aree più importanti del sito e le modalità di interazione più comuni:
· Pagamento delle multe : esempio di servizio per il cittadino, procedura complessa, uso poco frequente, con transazione bancaria (livello di informatizzazione 4);
· Prenotazione visite mediche : esempio di servizio per il cittadino, procedura complessa, uso poco frequente, con prenotazione (livello di informatizzazione 3);
· Modulistica : esempio di servizio comune a cittadino e imprese,
procedura semplice, uso molto frequente, con funzionalità limitate al download (livello di informatizzazione 2);
· Bandi di gara : esempio di servizio pensato prevalentemente per le imprese, procedura semplice, uso molto frequente, con funzionalità limitate alla semplice visualizzazione o al download (livello di
informatizzazione 1 o 2).
Per una descrizione più dettagliata del prototipo rimandiamo al prossimo capitolo.
5.4.2. Lo scopo dei test
Come si può intuire dal paragrafo precedente, costruire l’interfaccia di un sito significa effettuare numerose scelte (sull’organizzazione della pagina, sulla posizione delle funzioni più importanti, sui nomi da associare ad ogni link, ecc.).
Alcuni dubbi sono risolti dalle linee guida sull’usabilità, almeno per quanto riguarda i problemi più comuni che ormai sono già stati ampiamente testati e documentati; altre scelte sono state dettate invece dagli standard (scritti o non scritti) attualmente in uso (ad esempio la maggior parte dei siti pubblici già esistenti ha delle caratteristiche comuni che dovrebbero essere conservate); su molti altri aspetti invece non esistevano soluzioni “pronte” e quindi abbiamo dovuto effettuare noi una scelta.
In alcuni casi però esistevano più soluzioni plausibili e la selezione non era banale, per cui abbiamo deciso di ricorrere a dei brevi test di usabilità realizzati “ad hoc”.
Un esempio è il contenuto dei menù di destra e di sinistra: è ormai una prassi più o meno consolidata che il menù di sinistra contenga le voci che permettono di navigare rapidamente tutti i contenuti del sito, mentre è
molto meno standard il contenuto del menù di destra (a volte è fisso, altre volte contiene link contestuali alla pagina attualmente visualizzata, altre volte ancora non esiste affatto).
Quindi abbiamo creato delle varianti del prototipo che rispecchiassero queste 3 diverse alternative, e le abbiamo sottoposte a dei rapidi test per decidere quale fosse la migliore.
Figura 5.7 Versione con menù di destra contestuale (in questo caso, sottoeventi associati all’evento “Pagare le tasse”, selezionato nel menù di sinistra)
Figura 5.8 Versione senza menù di destra (eventi e sottoeventi sono tutti nel menù di sinistra)
Figura 5.9 Versione con menù di destra fisso (il menù di sinistra contiene gli eventi, i sotto-eventi sono nella sezione in alto)
La versione più apprezzata è stata quella con menù di destra fisso (contenente il form per il login, varie funzionalità di help, e gli strumenti di community, che restano comodamente sempre a portata di mano), la versione con link contestuali infatti era poco intuitiva (per molti non era chiaro il nesso tra i due menù) mentre quella senza menù di destra appesantiva troppo l’unico menù rimanente (che invece dovrebbe offrire una via alternativa rapida per accedere alle varie sezioni del sito).
Una volta fugati questi piccoli dubbi, abbiamo proseguito con i test principali, ovvero quelli che si occupano di valutare più aspetti possibile del prototipo cercando di individuarne i punti deboli.
5.4.3. Modalità di conduzione dei test
La tecnica utilizzata è stata quella del thinking aloud: ogni utente è stato incaricato di portare a termine alcuni compiti prestabiliti, esprimendo ad alta voce i suo pensieri durante l’operazione.
I compiti riguardavano ovviamente le funzionalità finora implementate, che per essere portate a termine (partendo dalla home page) richiedono diverse modalità di interazione e una navigazione in tutte le sezioni principali del sito, quindi sono un buon campione.
Gli utenti coinvolti sono stati complessivamente 12, divisi in 2 categorie (cittadini e “imprenditori”, ovvero persone che possiedono o lavorano in una impresa) ognuna delle quali è stata a sua volta suddivisa in un ugual numero di “esperti” e “non esperti”.
Ciascun utente ha condotto il test da solo, avendo a disposizione un PC con browser già posizionato sulla home page del nostro sito, e un foglio che indicava i compiti da portare a termine. Il nostro ruolo è stato esclusivamente di supporto, e abbiamo cercato di rendere la nostra presenza il piu’ trasparente possibile.
Nel dettaglio, i compiti assegnati a ciascuno erano 4, di difficoltà via via crescente e a loro volta divisi in sotto-task che simulassero esperienze di navigazioni “tipiche”:
1. Il primo task è particolarmente semplice e serve soltanto agli utenti per “rompere il ghiaccio” e prendere confidenza con il sistema di test:
1.1. Identificare la sezione di propria competenza (home page del cittadino per i cittadini, home page delle imprese per gli “imprenditori”)
1.2. Tornare alla home page principale
2. Il secondo task è più complesso, e prevede la ricerca e il
download di un dato modulo (oppure, per le imprese, di un dato bando di gara). Queste due operazioni sono molto frequenti sui siti delle P.A.
2.1. Cercare il modulo relativo alla Dichiarazione ICI 2003 (oppure, per le imprese, verificare se il bando di gara n.
11/04 è già stato chiuso)
2.2. Tornare alla home page del cittadino (o delle imprese) Questi task sono volutamente più generali perché non volevamo influenzare il soggetto sul modo in cui raggiungere l’obiettivo.
Trattandosi infatti di servizi di uso frequente, il prototipo prevede diverse modalità di accesso: una modalità standard
(particolarmente semplice e intuitiva) per gli utenti alle prime armi, e una modalità più nascosta ma di rapido accesso (tramite
“scorciatoie”) per gli utenti abituali. Quindi era necessario lasciare l’utente libero di agire come meglio crede in modo da testare anche la visibilità di entrambe le alternative.
3. Il terzo task prevede il completamento di un’operazione molto articolata, il pagamento on line di una multa. La procedura infatti richiede di identificare nell’archivio il verbale relativo alla propria contravvenzione, verificare i dati e infine procedere con il
pagamento, scegliendo la modalità preferita. E’ una funzionalità che dovrebbe essere di uso raro per ogni utente quindi non sono previste particolari scorciatoie, ma aumentano casomai gli help e i suggerimenti visto che l’operazione è piuttosto complessa. Era necessario quindi testare se la modalità di interazione è
abbastanza intuitiva, soprattutto per i meno esperti.
3.1. Cercare il servizio relativo al pagamento on line delle multe;
3.2. Riempire il relativo modulo, prelevando i dati necessari dal verbale (fac-simile) fornito in allegato;
3.3. Effettuare il pagamento con carta di credito, utilizzando i seguenti dati:
· Nome, cognome e indirizzo: i tuoi dati
· Tipo di carta di credito: MasterCard, Numero:
0000000001, Scadenza: 15/6/05 3.4. Tornare alla home page del cittadino
4. Il quarto ed ultimo task richiede il completamento di un’altra operazione complessa, la prenotazione on line di una visita medica. Questa prestazione non prevede un pagamento, ma richiede di autenticarsi (ovviamente non si può effettuare una prenotazione da anonimi), quindi implica anche una registrazione.
Per non appesantire troppo il lavoro, abbiamo chiesto agli utenti soltanto di cercare la sezione che permette di registrarsi.
Dopodiché, si suppone l’operazione abbia avuto successo e si procede con username e password fittizi. Abbiamo lasciato questa prova per ultima in quanto le modalità di
registrazione/autenticazione possono essere molto poco intuitive per chi non ha familiarità col mondo di Internet.
4.1. Individuare la sezione che permette di registrarsi sul sito (la registrazione effettiva non è necessaria);
4.2. Cercare il sevizio relativo alla prenotazione di visite mediche;
4.3. Inserire come nome prestazione “ECO Addome completo”;
4.4. Scegliere tra quelle disponibili la struttura ospedaliera con la minor attesa;
4.5. Autenticarsi con username : test e password : test;
4.6. Concludere l’operazione e tornare alla home page.
Tutti questi compiti miravano a valutare l’efficacia e l’efficienza del sito, ma non la soddisfazione dell’utente. Abbiamo cercato per questo di “leggere”
anche i comportamenti dei soggetti durante i test, ma per non affidarsi esclusivamente alle impressioni sarebbe necessario utilizzare un questionario.
In realtà questo tipo di valutazioni vengono fatte solo sulle versioni finali di un prodotto, e soprattutto su un numero elevato di utenti. Tuttavia dato che il nostro lavoro si ferma al primo prototipo, abbiamo comunque preparato un primo questionario (da utilizzare in futuro) che si può trovare in appendice.
5.4.4. Risultati dei test
Nell’eseguire le prove non abbiamo incontrato grandi difficoltà, gli utenti si sono anzi dimostrati incuriositi dalle particolari modalità di test e ciò ha aumentato lo spirito di collaborazione. Da parte nostra gli interventi sono stati pochi, principalmente per spiegare meglio i compiti e per mettere i partecipanti a proprio agio, oppure per spingerli ad esternare i propri pensieri. Raramente siamo dovuti intervenire per aiutare un utente che non riusciva a proseguire nel compito.
Passiamo ora ad elencare le impressioni e i suggerimenti ricavati durante i test.
Primo task. Come già spiegato in precedenza, questo primo compito era molto semplice e serviva principalmente a conquistare la fiducia dell’utente.
Tutti sono riusciti a portarlo a termine in pochi secondi, il che comunque ci
conferma che la scelta delle “schede” per rappresentare le sezioni principali del sito assicura un’ottima visibilità ed è in grado di catturare l’attenzione anche degli utenti alle prime armi.
Secondo task. Questo compito ha segnato le prime differenze tra utenti esperti e non. Quasi tutti gli utenti esperti infatti hanno notato nel menù di sinistra una sezione “Accesso rapido a…” che conteneva in evidenza le voci
“Modulistica” e “Bandi di gara”. Alcuni hanno usato direttamente la ricerca nel sito, in alto a destra nella pagina. Ciccare su queste voci permette un accesso immediato, mentre la via alternativa (quella attraverso la home page del cittadino e gli eventi della vita) è più immediata ma richiede anche più tempo (almeno 4 click, quindi 4 pagine da caricare).
Pur senza utilizzare le “scorciatoie” quasi tutti gli utenti meno esperti sono comunque riusciti a completare il compito (seppure con qualche indecisione e in tempi molto più linghi). Questo ci ha confermato che solo i navigatori abituali conoscono l’importanza del munù di sinistra e cercano prima di tutto lì quello che gli serve. Tendono invece a trascurare la parte centrale della home page, che spesso è più caotica e dispersiva. Viceversa, gli utenti meno esperti tendono a concentrare la propria attenzione prima sulla parte centrale della pagina, che usa immagini, colori e testi più evidenti.
E’ importante quindi offrire scorciatoie nei menù di navigazione, e descrizioni più dettagliate nella parte centrale della pagina.
Terzo e quarto task. I compiti più complessi hanno portato le prime serie difficoltà agli utenti. In questo caso non erano previste particolari scorciatoie, quindi tutti hanno dovuto seguire più o meno lo stesso percorso di navigazione. Solo alcuni utenti hanno preferito usare la ricerca nel sito (qualcuno direttamente, altri solo dopo aver constatato che il task non era semplice come i precedenti).
Le principali difficoltà riscontrate riguardavano tuttavia la navigazione negli
“eventi della vita” , in particolare a molti non è risultato intuitivo cercare il
servizio “pagare una multa” sotto l’evento “possedere un auto”, ma piuttosto sotto “pagare le tasse -> sanzioni”.
Infine alcuni utenti esperti hanno lamentato l’eccessivo numero di pagine da navigare per arrivare al risultato (ovvero sito troppo “profondo”). Purtroppo questa debolezza è una diretta conseguenza della scelta di favorire gli utenti meno esperti. Infatti, essendo i servizi da offrire moltissimi, è necessario organizzarli in modo fortemente gerarchico in modo da non dover presentarne troppi in un’unica pagina, rendendo la consultazione pesante.
Allo stesso modo, se un servizio richiede un’interazione complessa con l’utente è preferibile scomporlo in sotto-task più semplici, presentati uno alla volta e con descrizioni chiare e dettagliate. Tutti questi accorgimenti sembreranno sicuramente eccessivi ad un utente esperto, per cui quando possibile è consigliabile inserire scorciatoie.
Generalmente, possiamo comunque dire che anche in presenza di servizi particolarmente complessi la maggior parte degli utenti è riuscita a portare a termine il compito al primo tentativo, e anche tra quelli che non sono riusciti quasi tutti hanno individuato correttamente la funzionalità di help (non ancora implementata, ma comunque in vista in diverse parti delle pagine).
5.4.5. Conclusioni
La tecnica del thinking aloud è particolarmente utile perché permette di avvicinarsi molto a quello che è il sogno del progettista, ovvero sapere cosa pensa l’utente mentre interagisce col prodotto. Tuttavia i risultati ottenuti con questa tecnica (che nel nostro caso sono senz’altro lusinghieri) vanno saputi interpretare: è stato dimostrato infatti che mediamente il fatto di dover esprimere ad alta voce i propri pensieri forza l’utente a concentrarsi di più rispetto a quello che è abituato a fare. Infatti, sentendosi sotto osservazione, tende a ragionare il più possibile in modo logico per evitare
brutte figure, e questo lo rende più “attento” del normale e quindi meno sottoposto agli errori.
Per questo motivo, prima di cominciare ogni test ci siamo sforzati di far capire ai partecipanti che era l’interfaccia ad essere sotto osservazione e non loro, e che dovevano cercare di ragionare come se fossero da soli, a casa o sul lavoro.
