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

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

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:

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

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;

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

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”

- 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

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

- 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

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:

- 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:

- 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?

- 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

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

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

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.

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

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)

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

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”

- 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

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

- 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

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

- 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

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

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

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  

- 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:

-

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

possibile soluzione:

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.