Documento per la valutazione del progetto del team 2.pdf

Università degli Studi di Salerno
Dipartimento di Informatica
Corso di laurea Magistrale in Informatica
Corso di Interazione Uomo Macchina e Usabilità del Software
Documento per la valutazione del
progetto del team 2
IL PROGETTO: INTELLIGENT BUCKET
la docente
Prof. ssa Giuliana Vitiello
Email: gvitiello@unisa.it
Il Team 1
Gianmarco Beato 0522500782
Daniele Bifolco 0522501044
Riccardo D’Avino 0522501084
Federico Ripoli 0522500921
Anno Accademico 2021/2022
Assignment 3:

CORSO DI LAUREA MAGISTRALE IN INFORMATICA – UNIVERSITA’ DEGLI STUDI DI SALERNO
CORSO DI INTERAZIONE UOMO MACCHINA E USABILITA’ DEL SOFTWARE – A.A. 2021/2022
TEAM 1
DOCUMENTO PER LA VALUTAZIONE DEL PROGETTO DEL TEAM 2 – INDICE 1
Indice
1. Specifica dei requisiti di usabilità individuati durante l’analisi e il design……………………………….3
1.2 I task selezionati ..................................................................................................................................... 4
2. Impostazione dello studio………………………………………………………………………………... 9
2.1 Obiettivi della summative usability evaluation ...................................................................................... 9
2.2 Scelta dei partecipanti......................................................................................................................... 11
2.3 Ipotesi da testare................................................................................................................................. 14
2.4 Istruzioni sul testing e sui task............................................................................................................ 15
2.5 Predisporre il metodo di raccolta......................................................................................................... 17
2.6 Validità ecologica dello studio ............................................................................................................ 18
2.7 Analisi dei risultati .............................................................................................................................. 19
2.8 Sperimentazione con il software MORAE ........................................................................................... 23
3. Conclusioni……………………………………………………………………………………………... 25

TEAM 1
DOCUMENTO PER LA VALUTAZIONE DEL PROGETTO DEL TEAM 2 2
Il progetto che si andrà a testare in questo documento è “Intelligent Bucket” del team 2 i cui
componenti sono:ù
• Napolitano Ferdinando;
• Carone Lorenzo;
• De Roma Federico;
• Auriemma Francesco

TEAM 1
DOCUMENTO PER LA VALUTAZIONE DEL PROGETTO DEL TEAM 2 –
SPECIFICA DEI REQUISITI D USABILITA’ INDIVIDUATI DURANTE L’ANALISI E IL DESIGN 3
1. Specifica dei requisiti di usabilità
individuati durante l’analisi e il
design
1.1 I requisiti di usabilità
I requisiti funzionali del sistema sono:
• L’applicazione deve permettere all’utente di effettuare la richiesta di aiuto;
• L’applicazione deve permettere all’utente di effettuare la ricerca del rifiuto da cestinare;
• L’applicazione deve permettere di ritornare alla pagina principale;
• L’applicazione deve permettere di ritornare alle pagine precedenti;
• L’applicazione deve mostrare dove vanno differenziati i rifiuti;
• L’applicazione deve indicare il numero di rifiuti non coerenti;
• L’applicazione deve inviare settimanalmente o mensilmente le statistiche da analizzare;
• L’applicazione deve segnare i sacchetti non coerenti con uno spray.
I requisiti di usabilità individuati, in accordo alla documentazione prodotta dal gruppo sopra citato sono:
• L’applicazione deve essere motivante;
• L’applicazione deve essere intuitiva e facile da usare;
• L’applicazione deve offrire informazioni facilmente comprensibili.

TEAM 1
1.2 I task selezionati
Task 1: Gettare un rifiuto di cui non si conosce il contenitore di destinazione.
L’interfaccia della figura1 presenta
un pulsante “Aiuto?” che permette
di raggiungere una seconda
schermata (figura 2) in cui è
presente un pulsante “Dove lo
butto?”. Pigiandolo l’utente viene
indirizzato verso una nuova
schermata.
Nella schermata raggiunta (figura
3), l’utente può inserire grazie alla
presenza di una tastiera, il rifiuto di
cui desidera conoscere la
destinazione. Inserito il nome viene
reindirizzato all’ultima schermata
(figura 4) dove vengono mostrate le
informazioni desiderate.
Figura 1 Figura 2
Figura 3 Figura 4

TEAM 1
Task 2: Cosa si raccoglie oggi?
L’interfaccia della figura5 presenta un
pulsante “Aiuto?” che permette di
raggiungere una seconda schermata
(figura 6) in cui è presente un pulsante
“Cosa si raccoglie?”. Pigiandolo
l’utente viene indirizzato verso una
nuova schermata.
Nella schermata raggiunta (figura 7), l’utente può visualizzare
l’informazione desiderata.
Figura 5 Figura 6
Figura 7

TEAM 1
Task 3: Conferimento dei rifiuti.
L’utente che si appresta al
conferimento dei rifiuti visualizza
l’interfaccia standard (figura 8),
inserendo i rifiuti nel cassonetto
viene in automatico visualizzata
un’interfaccia di caricamento che
indica l’analisi dei rifiuti depositati
(figura 9).
Nel caso in cui siano presenti dei
rifiuti non coerenti con la raccolta,
viene mostrato un messaggio
inerente (figura 10) ed un pulsante
“Avanti”. L’utente clicca il pulsante
e viene indirizzato ad una pagina di
dettaglio, in cui vengono elencati i
prodotti idonei al conferimento
(figura 11).
Figura 8 Figura 9
Figura 10 Figura 11

TEAM 1
Task 4: Rimozione del sacchetto dei rifiuti.
L’operatore ecologico che si
appresta alla rimozione del
sacchetto dei rifiuti visualizza
l’interfaccia standard (figura 12), su
cui viene visualizzato il numero di
rifiuti non conformi. Intelligent
Bucket rileva la rimozione del
sacchetto (figura 13), l’operatore
preme il pulsante “SI”.
Successivamente alla corretta
rimozione del sacchetto, viene
mostrato una nuova schermata
(figura 14) in cui è presente il
messaggio di conferma ed un
pulsante “Azzera Contatore”, che
azzera il contatore dei rifiuti non
conformi e riporta alla schermata
standard (figura 15).
Figura 12 Figura 13
Figura 14 Figura 15

TEAM 1
Task 5: Accesso alle statistiche.
Figura 16
Figura 17
Figura 18

TEAM 1
IMPOSTAZIONE DELLO STUDIO 9
2. Impostazione dello studio
Per una corretta esecuzione del test di usabilità di un’applicazione è fondamentale impostare efficacemente lo
studio da effettuare, in modo da rendere possibile l’individuazione di problemi di usabilità che potrebbero
avere effetti negativi sulla corretta fruizione dell’applicazione da parte degli utenti finali ottenendo quindi una
cattiva UX (User Experience).
Prima di iniziare a pensare a cosa testare e come, è necessario elaborare un piano di test di usabilità che verrà
utilizzato come modello per il test vero e proprio.
In genere gli argomenti da affrontare sono i seguenti:
1. Obiettivi del test;
2. Scelta dei partecipanti;
3. Metodo di test;
4. Elenco dei task da testare;
5. Ambiente in cui avverrà il test;
6. Raccolta e misurazione dei dati utili per la valutazione.
2.1 Obiettivi della summative usability evaluation
Il primo passo per il test di usabilità è fissare gli obiettivi in modo chiaro.
È anche molto importante che gli obiettivi individuati siano:
• Specifici
• Misurabili
L’ individuazione degli obbiettivi di un test di usabilità viene svolto durante la fase cosiddetta di
“Pianificazione”.
Essenzialmente uno studio sull’usabilità di un’applicazione può essere condotto in due modi diversi, a seconda
dello specifico caso.
1. Usability study comparativo (Quantitative evaluation)
I test di usabilità comparativi sono diversi da altri approcci poiché si effettua un confronto tra due
applicazioni simili basandosi sull'efficacia e l'efficienza. Entrambi questi concetti sono il fulcro dei
test di usabilità. Un test comparativo non fornisce informazioni sulle preferenze o sulle prestazioni,
può invece darci indicazione su come gli end-users saranno in grado di completare i task e raggiungere
gli obiettivi desiderati.
Sarà quindi necessario proporre ai partecipanti al test diversi progetti che consentano di raggiungere
lo stesso obiettivo, in modo leggermente diversi ma abbastanza distinti da far percepire all’utente la
differenza, l’uno dall’altro.

TEAM 1
2. Usability study sulla singola applicazione (Qualitative evaluation)
Uno studio qualitativo offre una valutazione diretta dell'usabilità di un sistema;
i partecipanti vengono osservati durante l’interazione con specifici elementi dell'interfaccia utente, in
questo modo, risulta più semplice dedurre quali aspetti della progettazione sono problematici e quali
no. Si ha la possibilità di porre domande di follow-up ai partecipanti e modificare il corso dello studio
per ottenere informazioni su problemi specifici rilevati. Sulla base delle osservazioni effettuate durante
l’esecuzione dei task richiesti ai partecipanti e sulla base di come essi hanno reagito incontrando o
meno delle difficoltà, è possibile determinare se gli elementi dell'interfaccia utente sono ben progettati
o meno.
Lo studio a questo punto passa alla fase di “Preparazione” in cui vengono definiti il numero ed il profilo degli
utenti che saranno i soggetti del test di usabilità e che dovranno eseguire i task che sono stati precedentemente
selezionati. Si definirà la postazione di esecuzione degli esperimenti organizzando gli strumenti che si
utilizzeranno per l’osservazione ed il supporto all’esperimento.
La fase di “Esecuzione” inizia con l’inizio dell’esecuzione dei task che sono stati considerati utili nella fase
precedente. L’ultima fase e forse anche quella più delicata è quella di “Analisi” in cui vengo appunto analizzati
tutti i dati raccolti nelle fasi precedenti e che saranno la base di partenza per le eventuali modifiche da effettuare
alla UX in modo da risolvere i problemi riscontrati durante i test.

TEAM 1
2.2 Scelta dei partecipanti
Il metodo di test dell'usabilità delle applicazioni che verrà discusso nelle sezioni successive è una tecnica di
test orientata all'utente, significa che coinvolge utenti reali che svolgono attività realistiche. Sebbene il test con
utenti reali richieda più risorse, questo scenario realistico tende a produrre risultati più accurati.
Ci sono diverse considerazioni che devono essere fatte quando si scelgono i partecipanti per un test
di usabilità. I partecipanti devono:
• Essere rappresentativi degli utenti a cui è destinata l'applicazione (ovvero gli utenti target);
• Effettuare le loro considerazioni sulla base della fase in cui si trova attualmente l'applicazione.
Può variare da un'applicazione che è nelle sue fasi iniziali a una che è già sul mercato da tempo. A
questo proposito, fattori come la riservatezza e l'esperienza che i partecipanti al test hanno con le
applicazioni potrebbero essere cruciali;
• Essere disponibili nel momento, luogo e frequenza dei test di usabilità previsti;
• Accettare i termini e firmare il modulo di consenso alla partecipazione del test di usabilità.
Per verificare se gli utenti scelti siano o meno rappresentativi degli utenti a cui è destinata l’applicazione, verrà
chiesto loro di compilare uno specifico questionario pre-test.
Un buon numero dei nostri partecipanti dovrà svolgere la professione di operatore ecologico e di analista di
dati, questo per avere un buon feedback sul task n°4 e sul task n°5. I restanti partecipanti ricercati sono molto
eterogenei, questo perché l’applicazione è diretta a tutti coloro che effettuano la raccolta differenziata.
Quindi sulla base delle risposte ottenute al questionario sopra, i partecipanti saranno divisi in tre gruppi.
Questionario di background
ID utente: Data:
Dati dell’utente
Età: Sesso: M F Altro Titolo di Studio:
Professione: Luogo di Residenza:
Nazionalità:
Conoscenze utili
1) Nella tua città di residenza è attiva la raccolta differenziata dei rifiuti:
SI NO
2) Come giudicheresti la tua abilità nel differenziare i rifiuti:
BASSA MEDIA ALTA
3) Cosa pensi della raccolta differenziata:
INUTILE POCO UTILE UTILE MOLTO UTILE
FONDAMENTALE

TEAM 1
Alla fine dei test ogni partecipante dovrà compilare un questionario, un breve sondaggio di reazione che
esprime la valutazione soggettiva dell’applicazione e come i partecipanti hanno percepito il sistema. Il reaction
questionnarie misura le immediate percezioni del partecipante sulla qualità e sull’usabilità, i risultati possono
anche rilevare cambiamenti di opinione dovuto al test appena effettuato. È utile indicare una scala di
valutazione fissata in modo da guidare l’utente nella scelta ed ottenere dati facilmente analizzabili.
Reaction Questionnaire
1. Il sistema ha tutte le funzionalità che
mi aspettavo?
1 2 3 4 5
2. Credi che quest’applicazione migliori
la tua esperienza con la raccolta
differenziata?
1 2 3 4 5
3. Riesci a completare il task facilmente? 1 2 3 4 5
4. È facile trovare le informazioni di cui
ho bisogno?
1 2 3 4 5
5. L’interfaccia del sistema è piacevole? 1 2 3 4 5
6. Quali aspetti ti sono
piaciuti di più e perché?
7. Quali aspetti ti sono
piaciuti di meno e perché?
8. Hai qualche suggerimento?

TEAM 1
• SUS (System Usability Scale)
La System Usability Scale (SUS), offre un modo rapido ed efficace per valutare l'usabilità della
nostra applicazione, è uno strumento pratico e affidabile per misurare la facilità d'uso percepita e
determinare se esiste un problema generale con la nostra soluzione di progetto.
Assolutamente
in disaccordo
Disaccordo Neutro D’accordo
Assolutamente
d’accordo
1. Penso che mi piacerebbe
utilizzare questa applicazione
frequentemente
1 2 3 4 5
2. Ho trovato l’applicazione
inutilmente complessa
1 2 3 4 5
3. Ho pensato che
l’applicazione fosse facile da
usare
1 2 3 4 5
4. Penso che avrei bisogno del
supporto di una persona
tecnica per poter utilizzare
l’applicazione
1 2 3 4 5
5. Ho scoperto che le varie
funzioni di questa
applicazione erano ben
integrate
1 2 3 4 5
6. Ho pensato che ci fosse
troppa incoerenza in questa
applicazione
1 2 3 4 5
7. Immagino che la maggior parte
delle persone imparerebbe a
usare questa applicazione molto
rapidamente
1 2 3 4 5
8. Ho trovato l’applicazione molto
macchinosa da usare
1 2 3 4 5
9. Mi sentivo molto sicuro di usare
l’applicazione
1 2 3 4 5
10. Avevo bisogno di imparare molte
cose prima di poter iniziare
questa applicazione
1 2 3 4 5

TEAM 1
2.3 Ipotesi da testare
Per effettuare dei test che diano risultati soddisfacenti e che dimostrino la correttezza dei dati precedentemente
ricavanti quali anche le specifiche di usabilità è necessario formulare le cosiddette Ipotesi Nulle. Esse
mettono in relazione le variabili indipendenti e quelle dipendenti, affermando che la variazione della varabile
indipendente non causa una variazione nella variabile dipendente.
Lo scopo dell’esperimento è quello di invalidare le ipotesi nulle dimostrando che la predizione effettuata è
corretta.
Le variabili indipendenti sono: caratteristiche cambiate nel sistema per produrre differenti condizioni;
Le variabili dipendenti sono: caratteristiche misurate nell’esperimento (es. tempo di esecuzione task, errori,
efficacia, etc…)
• Esperimento 1
Nel primo esperimento ci concentreremo sull’esecuzione del task 1 in particolare sull’interfaccia della
figura3 prendendo in considerazione due possibili modi di presentarla all’utente:
1) Appare una tastiera con relativa input box;
2) Appare una label: “Che oggetto vuoi gettare?” e al disotto l’input box e la tastiera.
Variabile indipendente: label per l’input box.
Variabile dipendente: numero di errori e tempo di esecuzione del task.
NHP1: Utilizzare una label non aiuta gli utenti nel portare a termine il task con successo nel più
breve tempo possibile.
• Esperimento 2
Nel primo esperimento ci concentreremo sull’esecuzione del task 1 in particolare sull’interfaccia della
figura2 prendendo in considerazione di eliminare il pulsante “Cosa si raccoglie?”.
Variabile indipendente: pulsante “Cosa si raccoglie?”.
Variabile dipendente: numero di errori e tempo di esecuzione del task.
NHP2: La presenza del pulsante “Cosa si raccoglie?”, non interferisce con il portare a termine il
task con successo nel più breve tempo possibile.
• Esperimento 3
Nel terzo esperimento ci concentreremo sull’esecuzione del task 3 in particolare sull’interfaccia della
figura 11, prendendo in considerazione la label rifiuti non coerenti.
Variabile indipendente: label “rifiuti non coerenti”.
Variabile dipendente: errori.
NHP3: La visualizzazione della label e del numero (totale) di rifiuti non coerenti, rende agevole
all’utente la comprensione di quanti rifiuti non coerenti ha gettato.

TEAM 1
2.4 Istruzioni sul testing e sui task
Verrà adottato il metodo Within Group dove ogni soggetto esegue gli esperimenti sotto tutte le condizioni.
Per limitare i ‘learning biases’ ogni partecipante effettuerà i test secondo un ordine diverso.
È stato adottato questo metodo perché per eseguire un test ogni partecipante deve avere a disposizione 4 tablet
e un monitor, un set-up molto costoso.
• General Instructions
Nei prossimi 20 minuti dovrai eseguire 6 task con l’aiuto dell’applicazione Intelligent Bucket. Alcuni di
questi task sono introdotti da una breve storia che descrive il ruolo e la situazione che vorremmo adottassi
per eseguire il task.
Ognuno di essi presenta l’obiettivo che dovrai raggiungere.
Nota che abbiamo intenzionalmente tralasciato alcuni dettagli perché vorremmo che fosse il sistema a
guidarti.
Se hai qualche domanda non esitare a chiedere informazioni all’esaminatore, il quale non potrà però
rivelarti la soluzione da adottare per l’esecuzione del task.
Ti troverai di fronte a 4 cestini che rappresentano i cestini dell’immondizia ognuno collegato ad un tablet
con l’applicazione Intelligent Bucket già avviata che dovrai usare per eseguire i task 1, 2, 3, 4 e un monitor
dove dovrai eseguire i task 5, 6.
All’inizio di ogni task, per favore pronuncia: ‘inizio task’ seguito dal numero del task.
Quando hai finito, per favore pronuncia: ’task completato’.
Ricorda di pensare ad alta voce mentre esegui i task, questo è molto importante per noi, ci aiuta a capire i
tuoi stati d’animo, le tue aspettative, le tue reazioni mentre esegui il task.
• Istruzioni Task-Specific
Background task 1
Immagina di essere Tom, un ragazzo con poca esperienza nella raccolta differenziata che si trova a dover
gettare una ‘RAM’ senza conoscere il giusto contenitore.
Task 1
Getta la RAM nel giusto contenitore sfruttando l’aiuto dell’applicazione IB.
Background task 2
Immagina di essere Pina, una signora anziana che tiene molto alla raccolta differenziata e vuole che la sua
città sia sempre pulita. Arrivata davanti al bidone dell’immondizia si è dimenticata cosa viene raccolto in
quel determinato giorno.

TEAM 1
Task 2
Scopri cosa si raccoglie oggi.
Task 3
Davanti a te trovi diversi sacchetti contenenti rifiuti di tipo diverso, gettali tutti nel contenitore giallo e
scorpi quanti rifiuti non coerenti hai gettato.
Background task 4
Immagina di essere Mario un operatore ecologico che, come ogni mattina, raccoglie i sacchetti
dell’immondizia. È venerdì e si raccoglie il vetro. Mario raccoglie tutti i sacchetti ma alcuni sono
contrassegnati da una vernice che indica i sacchetti non correttamente cestinati.
Task 4
Raccogli i sacchetti nel contenitore del vetro e azzera il contatore dei rifiuti non coerenti
Background task 5 e 6
Immagina di essere Francesco un dipendente comunale di 45 anni, il cui compito principale è di
analizzare le statistiche sui rifiuti.
Task 5
Scopri quante tonnellate di plastica ha prodotto il suo comune nell’ultimo mese.
Task 6
Scopri qual è l’area che produce meno immondizia e quella che ne produce di più.

TEAM 1
2.5 Predisporre il metodo di raccolta
I partecipanti eseguiranno i test usando il metodo del Collaborative Think Aloud.
Un valutatore sarà presente durante l’esecuzione dei task e annoterà qualsiasi elemento possa essere rilevante
ai fini del test e offrirà assistenza ai partecipanti senza suggerire la soluzione per non invalidare il test.
Ogni valutatore avrà a disposizione un template che utilizzerà come riferimento durante l’esperimento.
Poiché i task sono eseguiti in ordine diverso per ciascun partecipante, il valutatore dovrà specificare il numero
del task, l’ora di inizio e di fine per capire il tempo impiegato nello svolgere il task. Dovrà indicare inoltre il
numero di errori, annotare i commenti dei partecipanti e riportare i problemi osservati e nel caso l’assistenza
offerta.
Data:____________ ID PARTECIPANTE:______________ ID VALUTATORE____________
TASK NUMERO:___________ INIZIO:_______ FINE:_______ NUMERO ERRORI_____
COMMENTI DEI PARTECIPANTI: _ _ _ _ _ _ _
PROBLEMI OSSERVATI (INCLUSA ASSISTENZA OFFERTA): _ _ _ _ _ _ _
PROBLEMI OSSERVATI (INCLUSA ASSISTENZA OFFERTA):
COMMENTI DEI PARTECIPANTI:_ _ _ _ _ _ _
OSSERVAZIONI DEL VALUTATORE:
_ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _
_ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _
__ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _ _ _ __ _ _ _

TEAM 1
2.6 Validità ecologica dello studio
L’ambiente in cui si è deciso di condurre l’esperimento è un’aula di laboratorio, in cui erano già presenti dei
computer.
Per simulare un contesto simile a quello in cui l’utente si troverebbe durante l’uso reale dell’applicazione sono
stati installati 4 tablet collegati a dei piccoli cestini che rappresentano i bidoni.
Per ogni postazione sono presenti dei sacchetti che rappresentano le buste della spazzatura.

TEAM 1
2.7 Analisi dei risultati
• Tabelle Variabili di Categoria
• Tabella Dati Numerici
Operatore
Ecologico
(n=6)
Analista
Dati
(n=5)
Studenti
(n=4)
Casalinghe
(n=7)
Altra
Professione
(n=8)
Età 43 (4.3) 37 (7.39)
19.5
(1.41)
56.5 (5.87) 62 (9.33)
Importanza Raccolta
differenziata
5 (0.00) 4.2 (0.4) 4 (0.9) 3.8 (1.12) 3 (1.00)
0
1
2
3
4
5
6
7
8
9
Operatore
Ecologico
Analista Dati Studenti Casalinga Altra
Professione
Professione
0
5
10
15
20
Italia Spagna Marocco Albania Polonia Ucraina
Nazionalità
Nazionalità

TEAM 1
• Tabelle dati sulla task performance
• Tabella delle specifiche di usabilità
Valutazione ipotesi nulla
Mean Time
(minuti)
Mean
Errors
1. Esperimento 1 (Task 1) 1.5 (0.39) 0.4 (0.45)
3. Esperimento 3 (Task 3) 1 (0.11) 0.1 (0.1)
Task
Mean Time
(minuti)
Mean
Errors
1. Gettare un rifiuto di cui non si conosce il
contenitore di destinazione
2 (0.67) 1.3 (1.2)
2. Cosa si raccoglie oggi? 0.6 (0.3) 0.25 (0.43)
3. Conferimento dei rifiuti 1.12 (0.5) 1 (0.2)
4. Rimozione sacchetto dei rifiuti 1 (0.39) 0 (0.00)
5. Accesso alle statistiche 6.5 (3.45) 0.98 (1.05)
Scenario Worst case Planned Best case
1. Gettare un rifiuto di cui non si
conosce il contenitore di
destinazione
4 minuti,
2 errori,
0 familiarità
2 minuti,
1 errori,
4 familiarità
1 minuti,
0 errori,
5 familiarità
2. Cosa si raccoglie oggi? 1,5 minuti,
1 errori,
0 familiarità
1 minuti,
0 errori,
3 familiarità
0.5 minuti,
0 errori,
5 familiarità
3. Conferimento dei rifiuti 2 minuti,
1 errori,
0 familiarità
1 minuti,
0 errori,
4 familiarità
1 minuti,
0 errori,
5 familiarità
4. Rimozione sacchetto dei rifiuti 1 minuti,
0 errori,
2 familiarità
0 minuti,
0 errori,
5 familiarità
0 minuti,
0 errori,
5 familiarità
5. Accesso alle statistiche 10 minuti,
2 errori,
0 familiarità
6 minuti,
1 errori,
5 familiarità
5 minuti,
0 errori,
5 familiarità

TEAM 1
I partecipanti sono stati divisi in due gruppi, alcuni hanno eseguito i task con l’interfaccia progettata (Gruppo
1), ad altri sono stati sottoposti i task in modo da valutare le ipotesi nulle (Gruppo 2).
Osservando la tabella 2 e 3 si può notare che le ipotesi nulle non sono state invalidate, ciò suggerisce di
effettuare delle modifiche all’interfaccia.
In particolare, per quanto riguarda il Task 1, si è visto che l’aggiunta di una label sulla tastiera che indichi
all’utente cosa scrivere, riduce il tempo di esecuzione del task ed il numero di errori medi che gli utenti hanno
effettuato. Sempre riguardo al Task 1, si è notato che la presenza del tasto “Cosa si raccoglie?” può confondere
l’utente, infatti, alcuni hanno pensato si riferisse ad una lista dei rifiuti conformi per il Bucket specifico e non
alla tipologia di rifiuto che si raccoglie in quel determinato giorno.
In relazione al Task 3 si è notato che molti utenti del Gruppo1 non sono riusciti ad individuare il numero di
rifiuti non conformi gettati, in quanto sullo schermo veniva mostrato il numero totale dei rifiuti non coerenti
presenti nel Bucket.
Una soluzione potrebbe essere quella di mostrare il numero totale di rifiuti non coerenti solo all’operatore
ecologico che avvia la procedura di rimozione del sacchetto mentre ai singoli utenti deve essere mostrato solo
il numero di oggetti non coerenti che hanno cestinato.
Confrontando i risultati ottenuti dagli esperimenti con le specifiche di usabilità, non sono stati individuati Task
che abbiano riportato dei valori che fossero inferiori al Worst Case. In molti casi i risultati ottenuti dagli
esperimenti coincidevano con i valori Planned, in alcuni invece si avvicinavano al Best Case.
• Tabelle dati SUS
Risultati SUS
Operatore Ecologico 82
Analista Dati 79
Studenti 73
Casalinghe 69
Altra professione 67
Media 74

TEAM 1
• Risultati Feedback degli utenti
Grazie al metodo del Think Aloud sono emerse alcune interessanti osservazioni:
1) Molti utenti hanno associato al pulsante ‘COSA SI RACCOGLIE’ la funzionalità di mostrare
all’utente cosa raccogliesse il contenitore, ovvero cosa buttare nel contenitore piuttosto che capire
cosa venisse ritirato quel giorno.
2) Molti utenti durante l’esecuzione del task 3 hanno erroneamente pensato che il numero dei rifiuti
non coerenti fosse il numero dei rifiuti non coerenti da loro buttati nel contenitore e non il numero
totale dei rifiuti non coerenti presente all’interno del contenitore.
3) Qualche utente ha pensato che il numero dei rifiuti non coerenti fosse un pulsante per verificare i
rifiuti che non si potessero buttare all’interno del contenitore.

TEAM 1
2.8 Sperimentazione con il software MORAE
Impostiamo, quindi, il test di usabilità utilizzando il software MORAE.
Per poter eseguire un buon test di valutazione dobbiamo definire le specifiche dello studio che stiamo
affrontando. Nel nostro caso abbiamo bisogno di tre diversi tipi di studio in base agli utenti del sistema:
operatore ecologico, analista e utente comune.
Operatore ecologico
Nel caso dell’operatore ecologico impostiamo tra i dettagli di registrazione, le specifiche per l’Observer in
modo che si debba collegare alla connessione “IBOperatore”; il nome della registrazione e la cartella in cui
verrà salvata saranno impostate alla fine del test.
In seguito, definiamo i dettagli dello studio. Impostiamo il nome “IntelligentBucketOperatore” e l’unica
istruzione che un operatore deve eseguire: “Rimuovere il sacchetto relativo ai rifiuti di vetro”. Inseriamo i task,
come riportati dalla tabella di seguito, nella relativa scheda, usando la scala di valutazione di default (0 =
completato facilmente, 1 = completato con difficoltà, 2 = fallimento).
Descrizione task Istruzioni
Rimuovere il sacchetto del vetro Rimuovere il sacchetto del vetro dal relativo
contenitore.
Resettare il contatore dei rifiuti non coerenti Sull’applicazione, azzerare il contatore dei
rifiuti non conformi.
Successivamente, impostiamo i survey che l’utente dovrà compilare una volta finito il test. I survey da
immettere sono il Reaction Questionnaire e il SUS descritti nel paragrafo 2.2.
Analista
Nel caso dell’analista impostiamo tra i dettagli di registrazione, le specifiche per l’Observer in modo che si
debba collegare alla connessione “IBAnalista”; il nome della registrazione e la cartella in cui verrà salvata
saranno impostate alla fine del test.
Lo studio sarà denominato “IntelligentBucketAnalista” ed avrà come istruzioni: “Cercare quanta plastica è
stata prodotta dal comune nell’ultimo mese” e “Individuare l’area che produce più immondizia e quella che ne
produce di meno”. Inseriamo i task, come riportati dalla tabella di seguito, nella relativa scheda, usando la
scala di valutazione di default (0 = completato facilmente, 1 = completato con difficoltà, 2 = fallimento).
Cercare quanta plastica è stata prodotta in
questo mese
Cercare i dati relativi la produzione di rifiuti
in plastica del comune nel mese corrente.
Individuare le aree con maggiore e minore
produzione di immondizia
Cercare i dati relativi le aree che producono
più immondizia e quelle che ne producono di
meno.

TEAM 1
Utente comune
Nel caso dell’utente comune impostiamo tra i dettagli di registrazione, le specifiche per l’Observer in modo
che si debba collegare alla connessione “IBUtente”; il nome della registrazione e la cartella in cui verrà salvata
saranno impostate alla fine del test.
Lo studio sarà denominato “IntelligentBucketUtente” ed avrà come istruzioni: “Capire dove si getta un rifiuto
di cui non si conosce il contenitore di destinazione”, “Chiedere cosa viene conferito oggi” e “Conferire dei
rifiuti”. Inseriamo i task, come riportati dalla tabella di seguito, nella relativa scheda, usando la scala di
valutazione di default (0 = completato facilmente, 1 = completato con difficoltà, 2 = fallimento).
Capire dove si getta un rifiuto di cui non si
conosce il contenitore di destinazione
Individuare all’interno del sistema il modo di
chiedere dove conferire un determinato
rifiuto; fornire il nome del rifiuto e cercare.
Chiedere cosa viene conferito oggi Individuare all’interno del sistema la sezione
in cui viene mostrato cosa si conferisce in data
odierna.
Conferire dei rifiuti Conferire dei rifiuti nel rispettivo contenitore
cercando di evitare errori di conferimento.

TEAM 1
CONCLUSIONI 25
3. Conclusioni
Dai dati sulla Task Performance abbiamo ottenuto risultati che si avvicinano al Planned Case delle
specifiche di usabilità. Anche se i risultati sono accettabili in quanto non sono al disotto del Worst Case,
potrebbero essere ulteriormente migliorati modificando l’interfaccia del prototipo tenendo conto degli
esperimenti effettuati.
Dai risultati del SUS è emerso che l’applicazione può essere ritenuta accettabile; tuttavia, sono necessari
piccoli miglioramenti per aumentare il punteggio delle categorie: Casalinghe e Altre Professioni che sono
risultate le categorie di utenti con età media maggiore.

Documento per la valutazione del progetto del team 2.pdf

Recommended

Recommended

More Related Content

Similar to Documento per la valutazione del progetto del team 2.pdf

Similar to Documento per la valutazione del progetto del team 2.pdf (20)

More from Gianmarco Beato

More from Gianmarco Beato (9)

Documento per la valutazione del progetto del team 2.pdf