All'interno delle tecniche di valutazione sperimentali, è possibile eseguire i test in 2 modi differenti:
- between subjects: ad ogni partecipante viene data 1 sola condizione, e ogni partecipante effettua 1 solo test; questo permette di non avere il problema del trasferimento dell'apprendimento;
- within subjects: ad ogni partecipante vengono date tutte le condizioni, e ogni partecipante effettua molteplici test; questo ha il vantaggio di poter avere pochi partecipanti per il test, dunque riducendo i costi, ma presenta il problema del trasferimento dell'apprendimento; è possibile mitigare quest'ultimo come segue:
- metà partecipanti riceve prima la condizione di controllo, poi la condizione sperimentale;
- l'altra metà riceve le condizioni in ordine contrario.
Una delle tecniche utilizzate per effettuare il prototyping e testare le interfacce con gli utenti è quella del "mago di Oz", attraverso la quale una persona simula il funzionamento di interfaccia grafica, mentre il partecipante interagisce con il prodotto senza rendersi conto della presenza di un attore dietro. La tecnica è stata introdotta in un test di un prodotto della IBM, per la quale una piattaforma di speech recognition veniva simulata in una camera nascosta da attori umani. I vantaggi di questa tecnica sono che è poco costosa, è particolarmente realistica ed è semplice da variare per futuri prototipi; nonostante tali pro, presenta svantaggi come l'over-optimism (le funzionalità testate potrebbero sembrare più funzionanti della realtà), e fare l'attore potrebbe non essere semplice.
I test in laboratorio vantano della presenza di strumentazione specifica che possa semplificare lo svolgimento degli esperimenti, ma presentano la mancanza di contesto reale; diversamente, i test sul campo colmano l'assenza di contesto durante l'attuazione dei test, inserendo il partecipante nell'ambiente naturale, ma introducendo il problema eventuale delle distrazioni causate dal contesto circostante.
All'interno di un esperiemento, una variabile indipendente è una caratteristica che non dipende dall'esperiemento, che potrebbe essere l'aspetto dell'interfaccia del prodotto testato, il numero di elementi di una lista all'interno di un menu dell'app presentata, ed altre proprietà che permettono l'interazione con l'interfaccia. Diversamente, le variabili dipendenti sono variabili che dipendono direttamente dall'esperimento svolto e dalle variabili indipendenti stesse, come ad esempio il numero di errori che il partecipante commette durante il test, oppure il tempo impiegato dallo stesso per effettuare un determinato task; dunque le variabili dipendenti sono generalmente legate a misurazioni sperimentali.
Disegnare interfacce all'interno degli storyboard non è buona pratica, principalmente per due motivi:
- il primo motivo è che lo sviluppo del prodotto verrebbe legato ad un'interfaccia specifica, in una fase in cui lo sviluppo ancora non è iniziato e ci si trova subito appena la fase di task analysis;
- il secondo motivo è che vogliamo che l'attenzione sia concentrata sul task e non sull'aspetto grafico del prodotto, dunque rivolgere il focus sul contenuto pragmatico dello storyboard.
Esistono due tipi di interazioni possibili tra oggetti ed azioni:
- le interazioni noun/verb, ovvero le interazioni in cui l'utente seleziona prima l'oggetto su cui agire, e successivamente l'azione; in particolare, il luogo dell'attenzione è dapprima sull'oggetto e successivamente si sposta sull'azione da selezionare, attivandosi; un esempio potrebbe essere quello di condividere una foto in galleria, poiché nel mentre che il luogo dell'attenzione è già sulla foto che stiamo visualizzando, premiamo sul pulsante per condividere la foto, e poi la condividiamo, che rappresenta l'azione da compiere;
- le interazioni verb/noun, ovvero le interazioni in cui l'utente seleziona prima l'azione che vuole svolgere, e successivamente l'oggetto sul quale compierla; questa interazione presenta svantaggi considerevoli, principalemente poiché potrebbe introdurre errori di modo, ad esempio utilizzando strumenti di editing fotografico potremmo dimenticarci di modificare lo strumento correntemente in uso.
Il cosiddetto "A/B testing" è caratterizzato da 1 variabile indipendente che può assumere 2 condizioni, A e B, e la null hypothesis determina che A = B, mentre l'ipotesi alternativa descrive che A != B; i risultati vengono raccolti ed esaminati statisticamente, generalmente attraverso il t-testing, che sfrutta distrubuzioni gaussiane. I vantaggi dell'A/B testing sono che risulta essere semplice per via della presenza di 1 sola variabile indipendente da esaminare, ed il risultato è anch'esso semplice da misurare; viceversa, gli svantaggi potrebbero essere che 2 condizioni potrebbero non essere sempre sufficienti, ed inoltre stabilire quali siano A e B potrebbe non essere sempre ovvio.
Le cosiddette "affordances" sono l'insieme delle azioni che è possibile eseguire su un oggetto, ed esistono a prescindere dalla percezione dell'utente che ci interagisce; un esempio potrebbe essere il fatto di utilizzare un martello come leva per sollevare qualcosa, che non risulta essere l'uso comune di un martello (ovvero quello di battere i chiodi), ma è comunque un'azione che rientra nelle azioni che è possibile svolgere con tale strumento. Invece, i "signifiers" sono le percezioni delle azioni possibili su un oggetto, che è possibile sfruttare attraverso indicazioni poste sull'oggetto o caratteristiche dello stesso; un esempio è fornito dalle porte che presentano etichette per tirare o spingere, che sottolineano all'utente l'azione corretta da dover performare.
Il "waterfall model" è un modello di sviluppo di design caratterizzato da fasi sequenziali, che sono le seguenti:
- specifiche dei requisiti: i requisiti devono essere scritti in linguaggio naturale, senza tecnicismi;
- design dell'architettura: è necessario fornire una descrizione ad alto livello del sistema e dell'interazione delle sue varie componenti;
- design dettagliato: in questa fase si raffina lo step precedente, andando ad identificare i vari moduli del sistema;
- coding e unit testing
- integration e testing
- manutenzione Questo modello di design presenta importanti problematiche, poiché:
- assume che le specifiche non cambino durante lo sviluppo del prodotto, mentre nella realtà si potrebbero presentare variazioni di contesto, di conoscenze, di requisiti, di tecnologie e di idee;
- assume che il design abbia fine in una determinata fase, mentre il design del prodotto è in continua evoluzione;
- assume che all'inizio dello sviluppo si sappia che cosa si sta facendo.
L'usabilità misura il grado di raggiungibilità di determinati obiettivi, da parte degli utenti, attraverso il sistema, in modo efficiente, e le misura mediante determinate proprietà:
- il sistema deve essere facile da ricordare e facile da imparare (memorability and learnability)
- il sistema deve essere efficiente
- il sistema deve essere veloce e ripristinabile da errori
- il sistema deve essere efficace e sicuro Dunque, l'usabilità (contrapponendosi alla UX) misura l'aspetto pratico e funzionale del sistema, chiedendosi "è facile da usare?".
Entrambe i modelli richiesti si basano sul modello ideale "washing machine", che adotta la tecnica dell'incremental design; in particolare, il modello agile è caratterizzato da una serie di fasi che si ripetono ciclicamente, detti "sprint", ovvero:
- analisi
- progettazione
- programmazione
- QA testing
- rilascio
L'agile presenta inoltre le seguenti proprietà:
- controlli frequenti del prodotto
- adattamento ai cambiamenti (di contesto, di requisiti)
- lavoro di gruppo: infatti, l'agile è caratterizzato da i cosiddetti "close proximity teams", in cui team di lavoro sviluppano il prodotto a stretto contatto, ed inoltre è presente il pair programming, in cui coppie di sviluppatori lavorano congiuntamente sullo stesso banco di lavoro
- rilascio frequente del prodotto
- allineamento con i need del committente
- non è facilmente predicibile per via della sua natura adattiva al cambiamento
- è "people-oriented", ma non "process-oriented", ed i processi servono solo come sostegno collaborativo mentre le abilità della singola persona sono maggiormente prese in considerazione
- non è presente molto coinvolgimento degli end users
Diversamente, il modello UCD (User Centered Design) è caratterizzato dalle seguenti:
- iterazioni di sviluppo
- "personas" e "scenarios": i "personas" sono modelli di utenti basati su dati demografici e psicologia, e rappresentano l'utente tipo; generalmente sono descritti da un nome, una foto, varie caratteristiche demografiche (al fine di dare umanità alla "persona"), da obiettivi concreti (che permettono di creare empatia con gli utenti e guidare le decisioni da prendere), da frustrazioni e comportamenti ben precisi; il vantaggio di utilizzare i "personas" sono di creare empatia, aumentare il focus sugli utenti, raggiungere più facilmente consenso nelle decisioni da prendere e misurare più facilmente l'efficacia di un prodotto
- ricerca contestuale
- user testing
- non è caratterizzato dal rilascio frequente di versioni
- non è multi-disciplinare e non si focalizza sulla collaborazione: nel modello washing machine i gruppi sono multi-disciplinari (nei vari gruppi sono presenti elementi eterogenei), mentre nell'UCD i gruppi sono omogenei.
L'agile UCD permette di prendere i vantaggi di entrambe i modelli di design, ed è caratterizzato da:
- alto coinvolgimento degli end-user
- alta comunicazione
- early release (ereditato dall'agile)
- non presenta stime di tempo finali per il progetto, ma presenta time slot fissati.
Espandendo l'ultimo punto, l'agile UCD è composto da cicli di sviluppo ben definiti:
- il primo ciclo, il ciclo 0, è ereditato dall'UCD, ed è caratterizzat da ricerca anticipata e contestualizzata, predizioni riguardo ai goal ultimi del prodotto, personas e scenarios; in questa fase developer e designer sono ancora a stretto contatto;
- nel secondo ciclo, il ciclo 1, viene definita la dimensione di 1 ciclo per tutti i prossimi cicli dal terzo in poi, e questo ciclo dura all'incirca 2/4 settimane con data di fine prefissata
- dal terzo ciclo in poi i cicli sono strutturati similarmente, all'interno dei quali developer e designer lavorano in 2 distinte track progettuali, dove
- i developer, attraverso il feedback ottenuto, implementano le migliorie sull'iterazione precedente del progetto, programmando contemporaneamente l'iterazione corrente
- i designer, attraverso il feedback ottenuto, testano l'interfaccia sull'iterazione precedente, eseguono il design sull'iterazione corrente e progettano e ricercano l'iterazione successiva.
Il luogo dell'attenzione è l'oggetto fisico o l'idea alla quale stiamo pensando attivamente ed intenzionalmente. Il focus è la volontà di focalizzare qualcosa, e rappresenta un elemento attivo dell'interfaccia, mentre locus potrebbe non coincidere con il focus dell'interfaccia, e denota l'impossibilità di controllare quale sarà il luogo dell'attenzione, attratta istintivamente da altro.
Il paper prototyping è una delle tecniche di prototipazione, realizzata attraverso prototipi di carta, che permette di usufruire di alcuni vantaggi:
- i prototipi sono a bassissimo costo, e sono facilmente e velocemente realizzabili; inoltre, è possibile riutilizzare parti di prototipi per vari test;
- i prototipi sono molto facili da cambiare attraverso le varie iterazioni;
- molte più persone possono giudicare il prototipo, poiché è realizzato in carta.
È preferibile far selezionare elementi dell'interfaccia al posto di far scrivere all'utente, al fine di svolgere un task per il raggiungimento di un determinato goal, poiché:
- l'utente mobile è spesso di fretta, e dunque utilizza il proprio dispositivo nei ritagli di tempo;
- l'utente mobile è distratto, e scrivere richiede invece particolare concentrazione da parte dell'utente, e non lascia spazio a distrazioni.
I vari ruoli sono:
- utenti, coloro che utilizzano con il prodotto
- administrator, colui che porge le domande all'utente
- observer, colui che prende nota dei risultati ottenuti
Il primo dei 7 principi di Norman (per il raggiungimento di un buon design) riguarda la "discoverability", ed afferma che deve essere possibile determinare ogni possibile azione all'interno di una data interfaccia, e deve essere sempre possibile determinare lo stato corrente del sistema; è possibile aumentare la "discoverability" attraverso i seguenti accorgimenti:
- comunicare lo stato del sistema in maniera efficace;
- le funzionalità principali devono essere chiare e più visibili delle funzionalità secondarie;
- fornire esempi di input laddove è richiesto l'inserimento di input da parte dell'utente;
- utilizzare valori di default intelligenti.
Un'abitudine è una sequenza di azioni, effettuate da parte di un utente, svolte in completo automatismo, senza che egli abbia bisogno di concentrarsi e porre l'attenzione su quel che esegue.
Durante la fase delle interviste è importante porre domande adeguate, che permettano all'administrator di ottenere le risposte al problema in esame:
- le domande devono essere "open-ended", che permettano di far parlare l'utente liberamente, ma non devono essere troppo lunghe;
- le domande devono trattare di situazioni note all'utente, calate in contesti a lui familiari;
- non bisogna chiedere mai "quanto spesso" un utente fa qualcosa
- non bisogna mai chiedere "vorresti X?", poiché ogni utente risponderà affermativamente, senza sapere realmente se tale funzionalità gli è davvero utile;
- non bisogna effettuare domande che abbiano "bias" verso una qualche risposta, e non devono contenere la risposta all'interno della domanda stessa;
- in generale, è importante "innamorarsi del problema, e non della soluzione".
All'interno delle tecniche di valutazione di un determinato prodotto è presente la cosiddetta "expert-based evaluation", descritta da una valutazione effettuata da un esperto, che è possibile condurre attraverso varie modalità, una delle quali è proprio il "cognitive walkthrough": attraverso questa tecnica l'esperto esamina esaustivamente il design, alla ricerca di problematiche e criticità, sulla base di studi psicologici e demografici, aderendo a noti principi che descrivono l'utente tipico.
È importante utilizzare gestures standard all'interno delle productivity applications, poiché esse sono pensate e progettate per un utente distratto, che utilizza l'applicazione nei ritagli di tempo, che ha bisogno di eseguire task ben precisi in maniera diretta, e che non ha tempo di preoccuparsi di imparare gesture particolari che distoglierebbero la sua attenzione dal task che deve compiere.
All'interno dello sviluppo del design di un prodotto è possibile sfruttare il luogo dell'attenzione attraverso le abitudini dell'utente: infatti, le abitudini creano automazione, ed è necessario rendere automatico lo svolgimento di determinati task al fine di catturare l'attenzione dell'utente su ciò che vogliamo sia veramente il suo luogo dell'attenzione. È bene ricordare infatti che l'essere umano è in grado di porre attenzione su 1 solo compito per volta, altrimenti si verificano fenomeni di interferenza, e tutti gli altri task svolti contemporaneamente a quello in cui si ha l'attenzione sono eseguiti per automatismo.
Nello studio dell'Interazione Uomo Macchina, le metafore sono elementi dell'interfaccia che richiamano oggetti del mondo reale, e che trasmettono all'utente il loro corretto uso e le possibili azioni eseguibili attraverso essi; esempi sono gli interruttori on/off per opzioni si/no, il pulsante play per riprodurre contenuti multimediali, o anche picker a scorrimento costituiti da ruote scrorrevoli.
Uno dei 3 stili principali di applicazione è lo stile "immersive", che descrive tutte le applicazioni caratterizzate da:
- task da compiere in uno specifico e ricco ambiente;
- task che prevedono la presenza di poco testo;
- task che richiedono l'attenzione continua da parte dell'utente;
- app che hanno necessità di mostrare numerose informazioni a schermo, in base al contesto dell'interfaccia. Tali applicazioni sono spesso utilizzate in modalità fullscreen, e hanno spesso necessità di utilizzare controlli non standard, perfino andando a crearne di propri (e scoprire il loro funzionamento è parte dell'esperienz autente).
Data un'interfaccia ed un gesto, tale interfaccia è detta in un modo rispetto a tale gesto se e solo se l'interpretazione del gesto non varia; quando l'interpretazione del gesto cambia, l'interfaccia si trova in un altro modo. Un esempio potrebbe essere il tasto INVIO, che in base allo stato del sistema può essere interpretato sia come CONFERMA che come pulsante per andare a capo. Un quasi-modo, invece, è un modo ottenuto attraverso un controllo attivo da parte dell'utente, come ad esempio potrebbe essere l'uso del tasto SHIFT o del tasto CTRL durante l'esecuzione di una shortcut. Infine, i modi temporanei sono modi che svaniscono dopo il loro utilizzo, come ad esempio il pennello per copiare un certo formato (selezionandolo) presente all'interno di molti programmi della suite Office.
È possibile mitigare le problematiche introdotte con l'utilizzo dei modi all'interno delle interfacce, attraverso i seguenti accorgimenti:
- sottolineare bene la presenza di modi laddove ve ne fossero;
- segnalare adeguatamente lo stato corrente del sistema all'utente, e renderlo il più possibile indipendente dai modi;
- utilizzare comandi diversi per modi diversi;
- in generale, limitare o evitare del tutto l'uso dei modi il più possibile.
È fondamentale fornire feedback agli utenti, al fine di renderlo consapevole degli effetti che produce agendo sull'interfaccia, e delle operazioni che vengono intraprese a seguito dei suoi comandi, che potrebbero talvolta essere errati e in mancanza di adeguato feedback porterebbero l'utente in forte confusione. I feedback possono essere di vario tipo, come sonori ma anche visivi (ad esempio animazioni). È importane sempre però proporzionare il feedback alla frequenza con cui tale feedback deve essere fornito: un alert di un'operazione pericolosa deve essere necessariamente ben visibile a schermo, poiché l'azione potrebbe essere potenzialmente distruttiva e l'utente ne deve essere al corrente, e soprattutto non è un'operazione che l'utente si troverà a compiere spesso nella maggior parte dei casi; diversamente, un'operazione che viene svolta molto frequentemente che però necessita comunque di feedback audio/video deve essere caratterizzata da un feedback poco invasivo, per via della ripetitività dell'operazione. Infine, è sempre buona norma informare l'utente dello stato del sistema durante fasi di caricamento di contenuti, mostrando barre di caricamento e/o tempi di attesa stimati per il completamento dell'operazione in corso.
Le tipologie di valutazione "expert-based" si dividono attraverso le seguenti:
- cognitive walkthrough: DISCUSSO IN DOMANDA PRECEDENTE
- heuristic evaluation: DISCUSSO IN DOMANDA SUCCESSIVA
- model-based evaluation: la valutazione è guidata da modelli, come ad esempio il GOMS, che permette di predire performance in relazione all'interfaccia, ed il KLM che viene utilizzato per predire compiti fisici semplici, come ad esempio interagire con il mouse
- review-based evaluation: i risultati raccolti vengono confrontati con quelli ottenuti a partire da studi effettuati in precedenza; per attuare tale strategia valutativa è importante accertarsi che sia possibile trasferire le conoscenze da un esperimento all'altro.
Il tasto "undo" permette agli utenti che stanno utilizzando un determinato prodotto di poter ripristinare le modifiche effettuate, e questo ha vari vantaggi:
- un vantaggio è sicuramente dato dal fatto che l'utente ha la possibilità di sbagliare, senza commettere errori irreversibili, dunque non rischiando di perdere informazioni o dati importanti;
- inoltre, tale possibilità di commettere errore permette di far sentire l'utente maggiormente a proprio agio, riducendo ansia e stress durante lo svolgimento di fasi critiche all'interno del task che sta eseguendo;
- infine, questa possibilità di commettere errori permette inoltre all'utente di sentirsi più libero di esplorare le funzionalità offerte dall'interfaccia, magari ad egli non ancora interamente note, riducendo il rischio di uso parziale del prodotto da parte degli utenti.
In ambito sperimentale, un ipotesi è una teoria con la quale si cerca di spiegare un determinato fenomeno del quale non si conosce a pieno il funzionamento. Dal punto di vista dello studio dell'Interazione Uomo-Macchina, generalmente gli esperimenti sono volti al fine di comprendere se esiste o meno la correlazione tra determinati elementi dell'interfaccia con alcuni fenomeni che si riscontrano; ad esempio, si potrebbe voler testare sperimentalmente se la variazione della dimensione del font all'interno di un'interfaccia possa avere impatto in termini di leggibilità della UI. Come descrive il metodo sperimentale, anche gli esperimenti in IUM vengono condotti utilizzando 2 ipotesi:
- l'ipotesi nulla, la quale afferma che non vi saranno variazioni all'interno delle variabili dipendenti
- l'ipotesi alternativa, la quale afferma, al contrario, che vi saranno variazioni all'interndo delle variabili dipendenti direttamente causate dalle variabili indipendenti.
Per poter eseguire la fase di needfinding di un determinato prodotto, è possibile attuare molteplici strategie, le cui 2 più importanti sono le seguenti:
- interviste: le interviste offrono possibilità di interazione diretta con gli end-users, ed è importante andare ad intervistare persone che rientrino nel target del nostro prodotto, poiché saranno loro a poterci fornire il feedback maggiormente impattante; durante un'intervista è importante porre le giuste domande, e chiedere le domande nel modo corretto DISCUSSO IN DOMANDA PRECEDENTE.
- questionari: i questionari sono un altro modo di effettuare needfinding, diverso dalle interviste poiché le domande che inseriamo al loro interno saranno effettuate a tutti quanti gli utenti indistintamente, e non sarà possibile ovviamente prolungare l'interazione con questi ultimi; infatti, i questionari mancano di "follow-up questions", ma permettono di raccogliere ed elaborare molto più facilmente i risultati; all'interno dei questionari possono essere poste domande aperte, a selezione multipla, a selezione singola o "Likert scales", ovvero domande in cui si chiede di indicare un valore in una scala che vada da 1 ad N, dove N è un numero sempre pari, di modo ché l'intervistato non possa esprimere un giudizio neutro.
L'analisi euristica è una delle tecniche che gli esperti possono attuare all'interno della "expert-based evaluation", utilizzata durante le tecniche di valutazione del design di un prodotto. Le euristiche sono norme, fonti e documenti preliminari ad un dato studio che vengono sperimentalmente utilizzate per guidare le decisioni da prendere o criticare le decisioni già prese; Nielsen ha stilato una serie di euristiche che secondo lui devono essere prese in considerazione quando si esamina il desing di un prodotto:
- informare sullo stato del sistema
- corrispondenza tra il sistema ed il mondo reale
- controllo e libertà
- consistenza e standard
- prevenzione errori
- riconoscere è meglio che ricordare
- flessiblità d'uso
- design minimalista
- aiutare l'utente negli errori
- guida e documentazione