FLSS Flatmates life support system

Usability Test Plan

Chiara Frantini

Sara Minoli

Matteo Vacca

INDICE

1. Panoramica del documento

2. Metodologia 2.1 Partecipanti 2.2 Procedura 2.3 Ruoli

3. Tasks e scenari 3.1 Scenario 1 3.2 Scenario 2 3.3 Scenario 3 3.4 Scenario 4 3.5 Scenario 5 3.6 Scenario 6

4. Errori 4.1 Errori non critici 4.2 Errori critici

5. Metriche di usabilità 5.1 Completion rate 5.2 Error-free rate 5.3 Time on Task (TOT) 5.4 Subjective Measures

6. Gravità del problema 6.1 Impatto 6.2 Frequency

7. Valutazioni soggettive

1. Panoramica del documento

Questo documento descrive il piano usato per condurre il test di usabilità durante lo sviluppo dell’app

FLSS.

La tecnica di progettazione da noi utilizzata è quella dello User Centered Design (UCD), che pone al

centro dell’attenzione il punto di vista e le esigenze dell’utente.

Gli obbiettivi di un test di usabilità sono :

1. valutare il livello di facilità d’uso e comprensibilità dell’interazione dell’interfaccia e

dell’architettura dei contenuti;

2. misurare le prestazioni degli utenti durante l’uso dell’app (tempi di completamento dei vari

tasks, misure soggettive, ecc...);

3. individuare gli eventuali problemi di design, architettura informativa, flusso delle informazioni

all’interno del sistema al fine di migliorare l’efficienza, la produttività e la soddisfazione d’uso

dell’utente finale;

4. valutare la piacevolezza dell’interfaccia.

Il metodo prescelto per la conduzione del test di usabilità è il cosiddetto “scenario-based”, che

prevede la definizione di scenari d’uso che identificano alcuni contesti di azione e obiettivi tipici e

plausibili da conseguire.

Le potenziali sorgenti d’errore possono essere:

- Errori di navigazione – impossibilità a trovare / accedere alle funzioni del sistema, eccessiva

lunghezza del flusso di navigazione per raggiungere una determinata area / 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).

2. Metodologia

2.1 Partecipanti

Per il test verranno reclutati 5 partecipanti. Questa scelta si basa su una ricerca effettuata da

Nielsen, secondo la quale con 5 partecipanti si individuano l’80% dei problemi di usabilità.

In fase di definizione dei requisiti, i dati raccolti con un questionario on-line a 60 soggetti, ci hanno

permesso di definire gli utenti-tipo del nostro sistema. Le categorie di partecipanti rappresentative

per il nostro test sono principalmente 3 :

1. Studenti che vivono in casa con altre persone

2. Lavoratori che vivono in casa con altre persone

3. Coppie conviventi

2.2 Procedura

Nella fase di test ci siamo avvalsi di un prototipo, funzionante nelle sezioni interessate per lo

svolgimento delle tasks, sviluppato con Axure, un software concepito per supportare l’attività del

progettista di applicazioni web e mobile.

Abbiamo svolto il test di usabilità seguendo 3 fasi principali:

- preparazione: definizione degli obiettivi generali del test; definire il profilo degli utenti, i compiti, e

i contesti d’uso (scenari);

- conduzione: illustrazione dei compiti e della metodologia ai partecipanti al test; effettuazione del

test con l’osservazione; questionario valutativo;

- analisi e report: stesura del 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.

Il test verrà effettuato seguendo il metodo Thinking Aloud. Con questo metodo il partecipante è

invitato ad esprimere ad alta voce pensieri, opinioni, commenti ed eventuali dubbi e difficoltà

mentre interagisce con l’interfaccia. In questo modo è possibile capire perchè l’utente effettui una

scelta piuttosto che un’altra, mettendo in luce i cosiddetti Pain Points, ovvero i punti in cui l’utente

esegue un’azione ottenendo un risultato diverso da quello atteso.

2.3 Ruoli

Il test di usabilità prevede la presenza di tre figure:

Conduttore

• fornisce una panoramica sul servizio

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

• osserva le espressioni del partecipante (linguaggio non verbale) al fine di ricavare più informazioni possibili

3. Tasks e Scenari

Gli scenari sono ricostruzioni dettagliate delle situazioni d’ uso del nostro sistema, che prevedono la

documentazione puntuale delle azioni eseguite dagli utenti.

Durante il test, si chiederà all’utente di interagire con esso in base agli scenari di seguito descritti. Ogni scenario prevede diversi task. Il completamento di uno scenario avviene dopo aver ultimato ogni

singolo task. La buona riuscita di uno scenario significa che l’interfaccia risulta all’utente chiara e

usabile. Può succedere che l’utente dichiari di aver completato uno scenario pur non avendo ultimato

tutti i tasks. Questo tipo di situazione potrà aiutarci ad individuare eventuali errori di progettazione.

Di seguito presentiamo gli scenari da noi proposti:

3.1 Scenario 1:

Arriva una bolletta del gas da 80 euro riferita al periodo gennaio-febbraio. La bolletta deve essere

pagata entro il 25 maggio. Decidi di notificarne l’arrivo ai tuoi coinquilini, inserendo le informazioni

relative (importo, scadenza, periodo di riferimento).

Task 1: entra in gestione

spese /calendario

Task 2: cliccare sul +

Task 3: inserisci bolletta

Esecuzione ottimale:

L’utente dopo aver effettuato l’accesso al sistema, potrà inserire la bolletta in due modi:

- dalla sezione gestione spese cliccando in basso sul bottone “+”.

- dalla sezione calendario, cliccando in basso sul bottone “+”.

Si aprirà un pannello overlay al centro della schermata dove sarà possibile inserire i seguenti dati:  

tipologia bolletta, periodo di riferimento, scadenza, coinquilini che contribuiranno alla spesa, e stato

del pagamento (pagata o ancora da pagare).

Ultimato l’inserimento di queste informazioni, e dopo aver cliccato sul bottone SALVA, il sistema

informa l’utente attraverso un feedback, che una notifica è stata inviata agli altri coinquilini.

3.2 Scenario 2:

Decidi di pagare la bolletta anticipando l’intero importo. Successivamente avviserai i tuoi coinquilini

del pagamento.

Task 4 : entra in gestione

spese

Task 5: aprire la bolletta

Task 6: segnalare come pagata

Esecuzione ottimale:

Nella sezione gestione spese, o

nella sezione calendario,

l’utente apre la voce bolletta

precedentemente inserita e

modifica lo stato da pagare in

pagata.

3.3 Scenario 3

In casa sono terminati alcuni prodotti di uso comune (detersivo per piatti, carta igienica, sale). Vuoi

informare i tuoi coinquilini in modo che possano ricomprarli il prima possibile.

Task 7 : entra in lista spesa

Task 8: inserire items

Esecuzione ottimale:

L’utente accede alla sezione lista spesa dove può aggiungere gli

item con la relativa quantità, inserendoli nel box di inserimento

testo in alto.

3.4 Scenario 4

Ti trovi in prossimità di un supermercato, e ricevi la notifica di nuovi item inseriti. Decidi di

acquistare i prodotti e di registrare in seguito l’importo nella sezione gestione spese.

Task 9: entrare il lista spesa

Task 10: selezionare gli items da mettere nel carrello

Task 11: concludi spesa

Esecuzione ottimale:

L’utente effettua la spesa consultando l’app: man mano che

trova un prodotto, clicca sul suo nome nella lista.

Automaticamente lo visualizzerà all’interno del carrello virtuale

situato nella parte inferiore dello schermo. Raccolti tutti gli

items, l’utente conclude la spesa, cliccando sul bottone relativo. Il

sistema mostrerà una finestra pop-up chiedendo all’utente se

vuole inserire l’importo e la foto dello scontrino. L’utente

declinerà la richiesta, rinviando l’azione ad un secondo

momento.

3.5 Scenario 5

Vai a fare uno stage all’estero di 90 giorni e subaffitti la tua camera. Comunica al sistema che non

sarai attivo per quel periodo e non verrai calcolato nella divisione delle spese.

Task 12: cliccare su on

Esecuzione ottimale:

L’utente clicca sulla scritta on

in verde impostando su off il

suo stato.

3.6 Scenario 6

Devi visualizzare i debiti che hai con gli altri.

Task 13: entrare nel profilo

personale

Esecuzione ottimale:

L’utente accede alla pagina

profilo personale cliccando

sulle tre linee in alto al

pannello più scuro da una

qualunque pagina della

nostra app, oppure

trascinando questo

pannello perso il basso.

4. Errori

4.1 Errori non critici

Gli errori non critici sono errori commessi dai partecipanti durante il completamento dello

scenario, ma senza ostacolare la buona riuscita delle tasks. 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).

4.2 Errori critici

Gli errori critici sono deviazioni dal completamento degli obbiettivi dello scenario. L’obbiettivo

principale è il completamento autonomo dello scenario. Ricevere un aiuto è un errore critico, in

quanto sta a significare che l’utente non riesce ad uscire da una situazione e ha bisogno di aiuto. Gli

errori critici sono i più importanti da risolvere al fine di migliorare l’esperienza d’uso del prodotto.

   

5. Metriche di usabilità

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

5.2 Error-free rate

Percentuale di partecipanti che completano il task senza errori (critici e non).

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

6. Gravità del problema

Per assegnare una priorità ad ogni problema rilevato durante l’esecuzione del test, si considerano due

fattori - l’impatto del problema e la frequenza con cui gli utenti ne fanno esperienza.

4.3.1 Impatto

L’impatto è il peso che ogni problema ha sul completamento del task.

Ci sono 3 livelli di impatto:

• Alto - impedisce gli 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)

4.3.2 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

7. Valutazioni soggettive

Ultimata l’esperienza di testing, 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 ti 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:

1. facilità d’uso

2. consapevolezza della sezione in cui ci si trova

3. accesso alle informazioni

4. look / appeal

5. soddisfazione

Le domande del questionario sono le seguenti:

1. Come valuti l’interazione con l’applicazione?

Per niente semplice - Poco semplice - Piuttosto semplice - Molto semplice - Estremamente

semplice

2. Ti è sembrato chiaro capire esattamente in quale sezione ti trovi mentre utilizzi l’app?

Per niente chiaro - Poco chiaro - Piuttosto chiaro - Molto chiaro - Estremamente chiaro

3. Quanto è stato facile individuare le informazioni desiderate?

Per niente semplice - Poco semplice - Piuttosto semplice - Molto semplice -

Estremamente semplice

4. Come giudichi il look della nostra app?

Per niente piacevole - Poco piacevole - Piuttosto piacevole - Molto piacevole -

Estremamente piacevole

5. Complessivamente ti ritieni soddisfatto dall’esperienza?

Per niente soddisfatto - Poco soddisfatto - Piuttosto soddisfatto - Molto soddisfatto -

Estremamente soddisfatto