Validazione app. Riprogettazione dell’interfaccia dell’applicazione ufficiale di Atm, “ATMobile”, con relativi test di usabilità. L’obiettivo principale è quello di migliorare l’interazione uomo-applicazione in modo da renderne più intuitivo l’utilizzo e facilitare la ricerca delle informazioni

1. Laboratorio di Progettazione II
Documento di validazione
e test
Dario Contini, 705212
d.contini@campus.unimib.it
Paola Re, 720316
p.re1@campus.unimib.it

2. INDICE
1) Definizione degli obiettivi del test
2) Definizione del campione di soggetti
3) Procedura
3.1) Task
3.2) Metriche di usabilità
3.3) Errori
3.4) Problemi riscontati
4) Valutazioni soggettive
5) Predisposizione dell’ambiente di testing
6) Report
6.1) Campione
6.2) Analisi dei risultati
6.2.1) Task analysis
6.2.2) Valutazioni soggettive
6.3) Possibili miglioramenti
7) Conclusioni

3. Questo documento descrive il piano usato per condurre il test di usabilità durante lo sviluppo di
NA.ATM.
1) Definizione degli obiettivi del test
Il processo di progettazione da noi utilizzato, per il
restyling dell’applicazione ATM Mobile, è quello dello User
Centered Design (UCD), che pone al centro dell’attenzione
il punto di vista e le esigenze dell’utente.
Il design deve essere semplice ed intuitivo per l’utente,
facilitando le operazioni che esso svolge con
l’applicazione. Per le informazioni più complesse deve
riuscire a suggerire passo per passo il cammino da
effettuare.
La struttura dell’interfaccia ha bisogno di essere
organizzata in modo chiaro, utile ed efficace.
NA.ATM è stata sviluppata seguendo come guidelines i principi della user-centered design e le
euristiche di Nielsen.
Le euristiche di Nielsen sono:
1) Visibilità dello stato del sistema
2) Coerenza fra il mondo reale e il sistema
3) Libertà è controllo da parte degli utenti
4) Consistenza e standard
5) Prevenzione degli errori
6) Riconoscere piuttosto che ricordare
7) Flessibilità ed efficienza d’uso
8) Design minimalista ed estetico
9) Aiutare gli utenti a riconoscere gli errori, diagnosticarli e correggerli
10) Guida e documentazione
Lo scopo dell'indagine è quello di valutare e apportare eventuali modifiche per migliorare il
risultato finale.
Sarà tenuto in considerazione:

4. - Il livello di facilità d’uso e comprensibilità dell’interazione dell’interfaccia e dell’architettura dei
contenuti
- La soddisfazione d'uso: la piacevolezza e il gradimento dell'utilizzo del prodotto
- L’efficienza: la quantità di risorse spese in relazione all'efficacia (tempi di completamento
dei vari tasks, misure soggettive, ecc.)
- L’efficacia: la misura in cui un utente è in grado di raggiungere l'obiettivo di un compito in
modo corretto e completo (raggiungimento obiettivo, se il numero di “tap” effettuati è
eccessivo)
- Gli errori: quanti e queli errori il soggetto compie
Inoltre verranno individuati:
- Eventuali problemi di design, di architettura informativa e di flusso delle informazioni
all’interno del sistema
Tutto questo per verificare se:
- NA.ATM è effettivamente migliorata rispetto alla versione precedente
- NA.ATM può reggere la concorrenza di altre applicazioni per il trasporto milanese presenti sul
mercato
- NA.ATM è facilmente utilizzabile da chi la usa per la prima volta
2) Definizione del campione di soggetti
Il test di valutazione sarà indirizzato a due tipologie di soggetti, ognuna delle quali composta
da 5 soggetti .
In tutti i casi i soggetti dovranno essere:
- Conoscitori del sistema operativo Android, in modo tale che abbinano già una certa familiarità
con le dinamiche di interazione con il dispositivo utilizzato per i test.
- Utilizzatori (anche non costanti) di mezzi pubblici.
- Età compresa tra i 18 e i 55 anni
Non prevediamo nessun’altra restrizione riguardo l’istruzione, la nazionalità, la residenza, ecc.
siccome i mezzi pubblici possono essere utilizzati da chiunque.

5. Le due tipologie di utenti sono:
Tipologia 1
Con la prima tipologia di utenti si vuole testare se l’applicazione è effettivamente migliorata
rispetto alla versione precedente e se può reggere la concorrenza di altre app simili. Per
andare a valutare questi aspetti è necessario rivolgere il test a utenti che hanno utilizzato
almeno una volta atm mobile o utilizzano frequentemente un’app di trasporto pubblico
milanese, al di fuori di ATM Mobile.
Tipologia 2
Con la seconda tipologia di utenti si vuole testare se l’applicazione è facilmete utilizzabile,
anche da chi si approccia ad un’ app sui mezzi di trasporto pubblici per la prima volta.
3) Procedura
Il metodo prescelto per la conduzione del test di usabilità è la “task-analysis”. Nei test di
compito, gli utenti svolgono singoli task, che permettono di esercitare funzioni specifiche del
sistema. Inoltre, saranno tenuti in considerazione i principi del “Thinking Aloud”, attraverso il
quale il partecipante è invitato ad esprimere ad alta voce pensieri, opinioni, commenti ed
eventuali dubbi e difficoltà mentre interagisce con l’interfaccia.
Abbiamo svolto il test seguendo 3 fasi principali:
- Preparazione: definizione degli obiettivi generali del test; definizione del profilo degli utentie
definizione dei compiti e dei contenuti d’uso (scenari);
- Conduzione: illustrazione dei compiti e della metodologia ai partecipanti al test; effettuazione
del test; somministrazione del questionario valutativo;
- Analisi e report: stesura dei report con la valutazione dei problemi riscontrati e con
indicazioni e suggerimenti su come risolverli.
In fase di conduzione si è tenuto conto di alcuni accorgimenti:
- Mettere gli utenti a proprio agio, per ridurre al massimo lo stress da esame;
- Spiegare bene che lo scopo è di provare il sistema, non l’utente;

6. - Spiegare bene quali compiti dovranno eseguire, e in quale ordine.
Ruoli:
Il test di usabilità prevede la presenza di tre figure:
- Partecipante:
. Viene sottoposto/a all’intervista/test
- Facilitatore:
. Fornisce una panoramica sul test
. Risponde alle domande dei partecipanti
. Assiste i partecipanti durante il test
- Osservatore:
. Prende nota di commenti, suggerimenti, punti di stallo ed errori
. Osserva le espressioni del partecipante (linguaggio non verbale) al fine di ricavare più
informazioni possibili
3.1) Task analysis
Questi test possono essere eseguiti anche quando il sistema non è completamente sviluppato.
Per esempio, per eseguire la ricerca nel catalogo dei prodotti, non è necessario che le funzioni
per l’acquisto siano già disponibili. Essi sono tanto più utili quanto più i compiti riflettono i casi
d’uso reali del sistema. Un errore frequente è quello di suggerire implicitamente agli utenti le
operazioni da eseguire, dando loro, in pratica, una serie di istruzioni, invece che un problema
da risolvere. L’utente deve, invece, essere posto in situazioni simili a quelle in cui si troverà
nell’uso reale del sistema, quando dovrà decidere, da solo, che cosa fare. Se l’utente è troppo
guidato, i problemi di usabilità, anche se presenti, non emergeranno, e il test non sarà di
alcuna utilità.
Durante il test, si chiederà all’utente di interagire con il prototipo di NA.ATM in base ai compiti
di seguito descritti.
Non abbiamo effettuato nessuna classificazione dei task per frequenza, criticità e importanza,
in quanto li riteniamo tutti sullo stesso livello.

7. Si vogliono andare a testare tutte le funzioni principali della nuova applicazione, per fare ciò
sono stati studiati 5 task specifici.
Ognuno dei compiti è stato elaborato in modo di andare a verificare diverse funzioni
dell’applicazione.
Task 1
Titolo
Pianificare un percorso
Obiettivo
Valutare come l’utente pianifica un percorso per raggiugere una determinata destinazione dalla
posizione attuale, escludendo gli autobus, e selezionando l’opzione più veloce. Inoltre verificare
se l’utente capisce i testi e le iconepresenti nell’app NA.ATM.
Compiti
- Calcola un percorso da “posizione attuale” a “Piazza Duomo”, escludendo gli autobus
- selezione la soluzione proposta che richiede meno tempo di percorrenza
- se c'è, dimmi il tempo di attesa del mezzo pubblico che dovresti utilizzare
Sequenza operativa ottimale
- Click sul pulsante calcola percorso
- Inserimento della destinazione
- Escludere autobus
- Click sul pulsante “cerca”
- Selezione dell’opzione più veloce
- Visualizzazione del percorso e del tempo d’attesa
Tempo richiesto
max 90 secondi
Criticità
- Riconoscimento immediato sezione “calcola percorso”
- Riconoscimento dei comandi nella pagina “calcola percorso”

8. - Comprensione della possibilità di vedere il percorso dettagliato nella pagina “scelta del
percorso”
- Riconoscimento e visibilità dell’icona che indica i “tempi d’attesa”
Task 2
Titolo
Visualizzazione dei punti d’interesse
Obiettivo
Verificare l’usabilità della sezione “trova”.
Compiti
- Trova la rivendida o l’ATM Point più vicino alla tua posizione attuale
- Visualizzalo sulla mappa
Sequenza operativa ottimale
- Click sul pulsante “Trova”
- Selezione di “Rivendite”
- Selezione di “ATM Point”
- Click sul rivendore o ATM Point più vicino
- Click su icona “mappa”
Tempo previsto per l’esecuzione
max 60 secondi
Criticità
- Riconoscimento immediato sezione “trova” punti di interesse
- Riconoscimento sistema per selezionare le categorie di interesse
- Riconoscimento icone e testi nella pagina “trova”
- Tap immediato sul rivenditore o ATM Point più vicino
- Riconoscimento icona “mappa”
Task 3
Titolo
Aggiunta di una fermata nei preferiti

9. Obiettivo
Verificare l’usabilità della sezione “linee e fermate” e aggiungere una fermata ai preferiti.
Compiti
- Visualizza l’intera linea della metropolitana M1
- Visualizza la fermata Lotto e aggiungila nei preferiti
Sequenza operativa attesa
- Click sul pulsante “linee e fermate”
- Swipe verso sinistra fino alla sezione metro
- Selezionare la M1
- Click sul pulsante “cerca”
- Selezionare la fermata Lotto-Fiera
- Click sull’icona preferiti
Tempo previsto per l’esecuzione
max 45 secondi
Criticità
- Riconoscimento immediato sezione “linee e fermate”
- Riconoscimento organizzazione pagina “linee e fermate”
- Riconoscimento icona aggiungi a preferiti
Task 4
Titolo
Lettura di un avviso riguardate una linea
Obiettivo
Valutazione usabilità sezione “avvisi”
Compiti
- Controlla se sono presenti avvisi per la linea del tram 7
- Se è presente leggi l’avviso
Sequenza operativa attesa

10. - Click sul pulsante “avvisi”
- Lettura dei tweet
- Click sul pulsante “infotraffico”
- Ricerca tra gli avvisi
- Visualizza dettagli avviso
Tempo previsto per l’esecuzione
max 40 secondi
Criticità
- Riconoscimento immediato sezione “avvisi”
- Riconoscimento organizzazione pagina “avvisi” e tasto “info traffico”
Task 5
Titolo
Preferiti e orari
Obiettivo
Valutazione usabilità sezione “preferiti” e pagina “orari”
Compiti
- visualizza la fermata Bignami già presente nei preferiti
- Scarica il file pdf degli orari della M5 in direzione Garibaldi
Sequenza operativa attesa
- Click sul pulsante “preferiti”
- Click sulla fermata di interesse
- Click sull’ icona orari
- Click su scarica orario
Tempo previsto per l’esecuzione
max 40 secondi

11. Criticità
- Riconoscimento immediato sezione “preferiti”
- Riconoscimento organizzazione pagina “preferiti”
- Riconoscimento icona orari
- Riconoscimento icona scarica in pdf
3.2) Metriche di usabilità
Abbiamo tenuto in considerazione tre diverse metriche per valutare l’usabilità dell’interfaccia.
- Completion Rate
Per tasso di completamento intendiamo la percentuale di compiti portati a termine con
successo, senza commettere errori critici. Se un partecipante richiede assistenza per
completare un task in maniera corretta il task dovrà essere considerato affetto da errore
critico.
- Error-free rate
Percentuale di partecipanti che completano il task senza errori (critici e non).
- Time on Task (TOT)
Il Time on Task è il tempo richiesto da un determinato compito per essere completato e viene
misurato da quando l’utente inizia lo scenario a quando lo dichiara completato.
Analizzando tali problemi si possono riscontrare differenze in base alle categorie di soggetti. In
questo modo si può cercare di rendere l’usabilità omogenea per tutti i tipi di utenti che
interagiscono con l’applicazione NA.ATM.
L’analisi comporta una componente di osservazione: saranno segnalati gli errori commessi, le
pause in cui l’utente non trova l’elemento con cui deve interagire e le deviazioni di percorso
per raggiungere un’informazione.
3.3) Errori
Le potenziali sorgenti d’errore possono essere:

12. - Errori di navigazione: impossibilità a trovare o accedere alle funzioni del sistema, eccessiva
lunghezza del flusso di navigazione per raggiungere una determinata area o funzione,
eccessivo uso della tastiera.
- Errori di presentazione: impossibilità a trovare e usare propriamente le informazioni
desiderate, errori dati dall’ambiguità delle labels.
- Problemi di utilizzo dei controlli (form, textfield, buttons).
Inoltre all’interno di un test di usabilità terremo in considerazione due tipologie differenti di
errori che un utente può effettuare, durante le interazione con l’applicazione.
- Errori non critici
Gli errori non critici sono errori commessi dai partecipanti durante il completamento dello
scenario, ma senza ostacolare la buona riuscita dei task. Solitamente se riconosciuti portano
frustrazione al partecipante. Questi errori possono essere di tipo procedurale: i partecipanti
non completano lo scenario in maniera ottimale (es. step eccessivi). Possono essere anche
errori di confusione (selezione della funzione scorretta, uso di un controllo in maniera scorretta
come provare ad editare un campo non editabile).
- Errori critici
Gli errori critici sono deviazioni dal completamento degli obbiettivi dello scenario. L’obbiettivo
principale è il completamento autonomo di esso. Ricevere un aiuto è un errore critico, in
quanto sta a significare che l’utente non riesce ad uscire da una situazione che trova non
comprensibile. Gli errori critici sono i più importanti da risolvere al fine di migliorare
l’esperienza d’uso del prodotto.
3.4) Problemi riscontati
Per assegnare una priorità ad ogni problema rilevato durante l’esecuzione del test, si
considerano due fattori:
- L’impatto del problema
- La frequenza con cui gli utenti ne fanno esperienza
Impatto
L’impatto è il peso che ogni problema ha sul completamento del task.
Ci sono 3 livelli di impatto:

13. - Alto: impedisce agli utenti di portare a termine il task (critical error)
- Moderato: causa difficoltà all’utente, ma il task può essere completato (non-critical error)
- Basso: problemi minori che non impattano sul completamento del task (non-critical error)
Frequency
E’ la percentuale dei partecipanti che incontrano il problema durante il task.
- Alto: 40% o più fanno esperienza del problema
- Moderato: 21% - 39% hanno esperienza del problema
- Low: 20% o meno fanno esperienza del problema
4)Valutazioni soggettive
Ultimata l’esperienza verrà sottoposto ai soggetti un breve questionario volto a valutare
l'efficacia, la soddisfazione d'uso della nostra app ed eventuali miglioramenti consigliati.
A questo scopo abbiamo scelto di utilizzare la scala di valutazone di tipo Likert a 5 alternative
di risposta.
La scala Likert misura gli atteggiamenti e i comportamenti utilizzando una serie di opzioni di
risposta (semanticamente collegate agli atteggiamenti che si vuole indagare), che vanno da un
estremo all’altro (ad esempio, da per niente probabile a estremamente probabile). A differenza
di una semplice domanda "sì/no", una scala Likert permette di scoprire i diversi gradi di
giudizio. La serie di opzioni di risposta aiuta, inoltre a identificare più facilmente le possibili
aree di miglioramento.
Il questionario è volto a indagare il grado dei seguenti aspetti:
- Facilità d’uso
- Consapevolezza della sezione in cui ci si trova
- Accesso alle informazioni
- Look / appeal
- Soddisfazione
Le domande del questionario sono le seguenti:
- Valuti positivamente l’interazione con l’applicazione?
- Ti è sembrato chiaro capire in quale sezione ti trovavi mentre utilizzavi l'app?
- Quanto è stato facile individuare le informazioni desiderate?
- La terminologia utilizzata per denotare le sezioni dell'applicazione risulta chiara?

14. - Il testo è leggibile?
- Giudichi positivamente l’aspetto della nostra app?
- I colori ti aiutano nelle navigazione?
- L'utilizzo dei simboli / icone ti risulta chiaro?
- Sei soddisfatto dei tempi impiegati per concludere un compito con successo?
- Complessivamente ti ritieni soddisfatto dell'esperienza?
- Hai osservazioni o suggerimenti da fare?
5) Predisposizione dell’ ambiente di testing
I test saranno effetuati sul campo e non in laboratorio.
Nella fase di test ci siamo avvalsi di un prototipo funzionante nelle sezioni interessate per lo
svolgimento dei task, sviluppato con Photoshoop e reso interattivo con Invision Prototyping
(software concepito per supportare l’attività del progettista di applicazioni web e mobile).
Il materiale usato è il seguente:
- Samsung s3 con accesso al prototipo
- Materiale cartaceo con le relative istruzioni per lo svolgimento dei task
- Blocco note per la stesura degli appunti da parte degli sperimentatori
- Microsoft Excel per la classificazione delle osservazioni alla fine di ogni test
- Microsoft Word per la stesura delle interviste

15. 6) Report
6.1) Campione
Il test è stato somministrato ad un campione di 10 soggetti:
- 5 utenti per la tipologia 1; coloro che hanno già utilizzato ATM Mobile o altre applicazione sul
trasporto pubblico milanese
- 5 utenti per la tipologia 2; coloro che non hanno mai utilizzato applicazioni sul trasporto
pubblico milanese
Come possiamo vedere dai grafici:
- 6 soggetti hanno un età compresa fra i 18 e i 25 anni

16. - 2 soggetti hanno un età compresa fra i 25 e i 35 anni
- 2 soggetti hanno un età superiore ai 45 anni
di cui:
- 5 sono di sesso maschile
- 5 sono di sesso femminile
Il livello scolastico è prevalentemente laurea triennale.
Una precisazione, non abbiamo intervistato nessuno studente del nostro stesso corso di laurea
(Teoria e Tecnologia della Comunicazione). Questo per evitare di valutare soggetti con il nostro
stesso background informatico.
Successivamente abbiamo chiesto la frequenza di utilizzo dei mezzi pubblici milanesi, per
verificare il rapporto dei soggetti con questo tipo di trasporto e per avere un’idea sulla loro
conoscenza delle dinamiche organizzative di ATM.
Possiamo vedere che 8 soggetti su 10 utilizzano regolarmente ATM.
Abbiamo chiesto quali applicazioni sul trasporto pubblico milanese utilizzano gli intervistati, la
frequenza di utilizzo e la loro soddisfazione d’uso.
N.B. un soggetto ha risposto con due applicazioni.

17. Di seguito possiamo vedere una tabella a doppia entrata che rappresenta la frequenza di
utilizzo per il tipo di app usate.
una volta poche volte abbasta-nza molte volte sempre
ATM Mobile 1 1 1
iATM 1
Milano Bus Live
Moovit
Movimi 1
ATM Milano 1
Di seguito possiamo vedere una tabella a doppia entrata che rappresenta la soddisfazione
d’uso per il tipo di app usate.
per niente poco abbasta-nza molto estrema-mente
ATM Mobile 1 2
iATM 1
Milano Bus Live
Moovit
Movimi 1
ATM Milano 1
6.2) Analisi dei risultati
6.2.1) Task Analysis
In questo paragrafo si esaminerà l’andamento delle performance del campione sui 5 scenari
proposti.

18. Di seguito proponiamo 5 tabelle a doppia entrata; esse rappresentano il successo (s), il
successo parziale (p), il fallimento (f) di ogni utente per ogni punto della sequenza ottimale.
Infine vengono indicate le osservazioni di rilievo registrate.
N.B. Utente 1-2-3-4-5 tipologia 1
Utente 6-7-8-9-10 tipologia 2
Task1
Sequenza operativa ottimale
- Click sul pulsante calcola percorso
- Inserimento della destinazione
- Escludere autobus
- Click sul pulsante “cerca”
- Selezione dell’opzione più veloce
- Visualizzazione del percorso e del tempo d’attesa
Criticità
- Riconoscimento immediato sezione “calcola percorso”
- Riconoscimento dei comandi nella pagina “calcola percorso”
- Comprensione della possibilità di vedere il percorso dettagliato nella pagina “scelta del
percorso”
- Riconoscimento e visibilità dell’icona che indica i “tempi d’attesa”
c1 c2 c3 c4 c5 c6 tempo (s)
1 s s s s s f 64
2 p s s s s f 101
3 s s s s s s 53
4 p s s s s f 131
5 s s s s s s 45
6 s s s s s p 85
7 s s s s s s 45

19. 8 s s s s s s 50
9 s s s s s s 99
10 s s s s s p 110
Completion Rate
su un totale di 60 osservazioni
Error-free rate
5 utenti su 10 hanno completato perfettamente il task
Osservazioni rilevanti
naif
- non è sicuro che è stato capito il significato dell’icona tempo d’attesa immediatamente
(errore non critico, impatto media frequenza, priorità media)
esperti
- non riconosce o non vede l’icona tempo d’attesa
(errore non critico, impatto media frequenza, priorità media)

20. Task2
Sequenza operativa ottimale
- Click sul pulsante “Trova”
- Selezione di “Rivendite”
- Selezione di “ATM Point”
- Click sul rivendore o ATM Point più vicino
- Click su icona “mappa”
Criticità
- Riconoscimento immediato sezione “trova” punti di interesse
- Riconoscimento sistema per selezionare le categorie di interesse
- Riconoscimento icone e testi nella pagina “trova”
- Tap immediato sul rivenditore o ATM Point più vicino
- Riconoscimento icona “mappa”
c1 c2 c3 c4 c5 tempo (s)
1 s s s s s 45
2 s s s s s 18
3 s s s s s 57
4 s s s s s 60
5 s s s s s 50
6 s s s s s 55
7 s s s s s 50
8 s s s s s 34
9 s s s s s 90
10 s s s s s 70
Completion rate

21. su un totale di 50 osservazioni
Error-free rate
Tutte e 10 gli intervistati hanno portato a termine il task
Osservazioni rilevanti
naif
- non è stato sempre effettuato subito il tap sulla checkbox, ma prima sul nome della categoria
(errore non critico, impatto media frequenza, priorità media)
esperti
- non è stato sempre effettuato subito il tap sulla checkbox, ma prima sul nome della categoria
(errore non critico, impatto media frequenza, priorità media)
Task3
Sequenza operativa attesa
- Click sul pulsante “linee e fermate”

22. - Swipe verso sinistra fino alla sezione metro
- Selezionare la M1
- Click sul pulsante “cerca”
- Selezionare la fermata Lotto-Fiera
- Click sull’icona preferiti
Criticità
- Riconoscimento immediato sezione “linee e fermate”
- Riconoscimento organizzazione pagina “linee e fermate”
- Riconoscimento icona aggiungi a preferiti
c1 c2 c3 c4 c5 c6 tempo (s)
1 s p s s s p 58
2 s s s s s s 21
3 s s s s s s 30
4 f
5 s s s s s s 50
6 s s s s s s 33
7 s p s p s s 60
8 s s s s s s 27
9 s s s s s s 55
10 s s s s s s 53
Completion rate
su un totale di 60 osservazioni

23. Error-free rate
7 soggetti su 10 hanno completato interamente il task
Osservazioni rilevanti
naif
- Problemi con l’individuazione della scheda metro
(errore critico, impatto media frequenza, priorità alta)
esperti
- Problemi con l’individuazione della scheda metro
(errore critico, impatto media frequenza, priorità alta)
Task4
Sequenza operativa attesa
- Click sul pulsante “avvisi”
- Lettura dei tweet

24. - Click sul pulsante “infotraffico”
- Ricerca tra gli avvisi
- Visualizza dettagli avviso
Criticità
- Riconoscimento immediato sezione “avvisi”
- Riconoscimento organizzazione pagina “avvisi” e tasto “info traffico”
c1 c2 c3 c4 c5 tempo (s)
1 s s s s s 26
2 s s s s s 20
3 s s f
4 s s f
5 s s s s s 19
6 s s f
7 s s s s s 49
8 s s f 60
9 s s s s s
10 s s f 59
Completion rate
su un totale di 50 osservazioni

25. Error-free rate
5 utenti su 10 hanno completato interamente il task
Osservazioni
Naif
- Non viene visualizzata la scheda infotraffico
(errore critico, impatto media frequenza, priorità alta)
Esperto
- Non viene visualizzata la scheda infotraffico
(errore critico, impatto media frequenza, priorità alta)
Task5
Sequenza operativa attesa
- Click sul pulsante “preferiti”
- Click sulla fermata di interesse
- Click sull’ icona orari

26. - Click su scarica orario
Criticità
- Riconoscimento immediato sezione “preferiti”
- Riconoscimento organizzazione pagina “preferiti”
- Riconoscimento icona orari
- Riconoscimento icona scarica in pdf
c1 c2 c3 c4 tempo (s)
1 s s s s 25
2 s s p s 40
3 s s s s 52
4 s s s s 29
5 s s s s 14
6 f s f
7 s s s s 13
8 s s s s 20
9 s s s s 48
10 s s p s
Completion rate
su un totale di 40 osservazioni

27. Error-free rate
7 utenti su 10 hanno completato interamente il task
Osservazioni
naif
- viene confuso il tempo d’attesa con orario
(errore critico, impatto bassa frequenza, priorità media)
- tap su vari punti prima di trovare orario
(errore non critico, impatto media frequenza, priorità media)
esperti

28. Time on Task
Di seguito proproniamo i tempi medi di svolgimento dei task ( in secondi)
tempo richiesto ( in secondi):
N.B: la prima volta che si usa una nuova applicazione il tempo sarà leggermente maggiore del
tempo normale per un’operazione.
task 1: 90 secondi
task 2: 60 secondi
task 3: 45 secondi
task 4: 40 secondi
task 5: 40 secondi
6.2.2) Valutazioni soggettive
Al termine dello svolgimento di tutti i task abbiamo sottoposto l’utente ad un piccolo
questionario in forma anonima.
Di seguito presentiamo i risultati ottenuti

31. 6.3) Possibili miglioramenti
Analizzati gli errori emersi dal test di usabilità, proponiamo ora una serie di proposte volte a
migliorare e a correggere le anomalie presenti nel nostro sistema.
Gli interventi necessari a questo scopo sono i seguenti:
- Rendere più chiaro e visibile il significato dell’icona che indica il “tempo d’attesa” del mezzo.
Di seguito proponiamo una possibile soluzione:
x

32. - Rendere interattiva tutta la zona che indica una categoria di punti d’interesse e non solo la
checkbox.
Di seguito proponiamo una possibile soluzione:
- Mettere in evidenza le quattro categoria di mezzi trasporto (tram, bus, metro, suburbane) al
click sulla sezione “linee e fermate”. Cambiare il colore e ingrandire la barra dei tabs, per
renderla maggiormente distinguibile con l’header.La stessa soluzione potrà essere adottata
anche nelle sezioni “Avvisi” e “Preferiti”.
Di seguito proponiamo una possibile soluzione:
-

33. Rendere distinguaibile l’icona orario, cambiandoil tipo di pulsante. Di seguito proponiamo una
possibile soluzione:

34. 7) Conclusioni
Rispetto al test effettuato si può osservare quanto segue:
- La maggior parte dei soggetti ha avuto un primo momento di parziale disorientamento,
dovuto alla necessità di familiarizzare con uno strumento mai visto prima, che hanno poi
recuperato gradualmente nel corso del test. Questo mostra che sarebbe utile prevedere una
piccola descrizione iniziale, che sia una panoramica delle funzionalità del sistema, volta ad
istruire l’utente.
- Durante i test abbiamo osservato che la terminologia usata in NA.ATM è stata ben capita
dagli utenti, a differenza delle icone che richiedono qualche aggiustamento.
- Terminato il primo test di valutazione abbiamo dovuto cambiare metodologia per l’esecuzione
di essi, inizialmente prevedevamo di utilizzare lo “scenario-based”I test di scenario possono
mettere alla prova l’utente (e il sistema) in modo molto più impegnativo dei test di compito. In
particolare, permettono agli utenti di utilizzare il sistema in relazione alle proprie specifiche
necessità, preferenze e abitudini. La strategia che gli utenti seguiranno per raggiungere
l’obiettivo potrebbe essere molto diversa da quella prevista dai progettisti.
Non avendo, ancora, un prototipo totalmente funzionante abbiamo deciso di utilizzare la task
analysis.
Svolgere il test di usabilità si è rivelato molto utile per individuare limiti e potenzialità
dell’applicazione, non solo dal punto di vista grafico , ma anche dal punto di vista
dell’architettura dell’informazione.
Nonostante in alcune situazioni i soggetti abbiano provato un senso di frustrazione dovuto al
fatto di non riuscire ad eseguire il compito richiesto, hanno mostrato un vivo interesse rispetto
all’idea dell’applicazione e alla sua utilità.
Confrontando, a questo report, i risultati rilevati dal questionario per la valutazione
dell’applicazione attuale ATM Mobile, riteniamo che ci siano stati numerosi miglioramenti in
termini di usabilità, grafica, architettura dell’informazione ed efficienza del sistema.
Oltretutto, siamo consapevoli che il lavoro per creare un’ottima app, capace di sostituire
l’attuale e di reggere la concorrenza è ancora grande.