FLSS vuole essere un supporto tecnologico alla gestione della vita condivisa, semplice, giocoso e facile da usare, volto a rendere piacevole e formativo quel periodo della vita in cui giovani studenti e lavoratori condividono un appartamento, soprattutto nelle grandi città dove i canoni d'affitto sono molto alti.

1. FLSS
Flatmates life support system
Usability Test Plan
Chiara Frantini
Sara Minoli
MatteoVacca

2. 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.3Time onTask (TOT)
5.4 Subjective Measures
6. Gravità del problema
6.1 Impatto
6.2 Frequency
7.Valutazioni soggettive

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

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

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

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

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

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

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

10. 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)
IlTime onTask è 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

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