Il Thinking Aloud è una delle metodologie più popolari per l’esecuzione di test di usabilit� con utenti.

“Non mi piacciono i colori (Cosa potete aspettarvi che dica almeno un utente in ogni test di usabilit� )”
Steve Krug, Don’t make me think

“Con oggetti mal progettati(…), non fa meraviglia che le persone si sentano colpevoli quando hanno difficolt� a usare gli oggetti, specialmente se hanno l’impressione (sia pure sbagliata) che nessun altro abbia gli stessi problemi.”
Donald A. Norman, La caffettiera del masochista

Forse un altro titolo per questo articolo avrebbe potuto essere: “come realizzare un test di usabilit� con utenti, senza spendere troppo”.
Infatti, senza voler togliere il lavoro ai consulenti di usabilit� , nel corso di questo articolo mostreremo come sia possibile realizzare un test di usabilit� a costi contenuti e ottenendo risultati apprezzabili.

Che cos’è e a cosa serve
I test di usabilit� possono essere fatti in molti modi, più o meno costosi, il nostro è basato sul “Thinking aloud protocol”: questa metodologia prevede che l’utente, nel corso del test, esprima ad alta voce i propri pensieri, sensazioni, opinioni, frustrazioni (!) e commenti le proprie azioni mentre interagisce con la User Interface (UI) oggetto del test. Un osservatore è presente per stimolare l’utente senza influenzarlo e per raccogliere le sue osservazioni.

Noi stiamo presupponendo di testare un sito o un’applicazione web, ma in realt� questo metodo è adatto per testare l’usabilit� di un qualsiasi artefatto prodotto dall’uomo, dalla lavatrice all’applicazione client-server tradizionale.

Nel thinking aloud è l’utente stesso a fornire al team di sviluppo la risposta alle domande: “che cosa farebbe adesso l’utente?” “come possiamo aiutarlo a raggiungere l’obiettivo con successo?”. In altre parole con questo metodo si riescono ad ottenere informazioni dirette su come gli utenti ragionano quando interagiscono con la UI del nostro sito: leggere nel pensiero degli utenti è infatti il sogno nascosto di ogni UI designer.

Come è facile comprendere, le informazioni che otteniamo sono di carattere qualitativo e non quantitativo. Inoltre, relativamente ai tre aspetti principali correlati all’usabilit� (efficacia, efficienza, soddisfazione) il thinking aloud non copre quello relativo all’efficienza, dato che le condizioni di esecuzione del test influenzano le performance dell’utente (alcuni esperimenti hanno mostrato che il TA addirittura aumenta l’efficienza dell’utente nel compiere il task assegnatogli).

Ma vediamo come realizzare il nostro test.

Come si fa
La prima cosa da fare è individuare il facilitatore, che dovr� condurre materialmente il test ed elaborarne i risultati, partecipando attivamente a tutte le fasi; in un test “fatto in casa” il facilitatore può essere individuato tra gli sviluppatori di interfacce, scegliendo la persona con maggiore esperienza nel campo, con maggiore sensibilit� verso l’usabilit� e con spiccate capacit� di interrelazione con gli utenti. Disponendo di budget più elevati, il facilitatore potr� essere un consulente esterno, esperto in HCI.

La procedura per realizzare il nostro test è divisa in tre fasi:

• Preparazione
• Conduzione
• Analisi e Presentazione dei risultati

Preparazione del test
La fase di preparazione del test non deve assolutamente essere sottovalutata, perché da una sua accurata progettazione dipende la buona riuscita del test. All’interno della fase di preparazione possiamo distinguere queste attivit� :

1. determinazione degli obiettivi generali del test

2. definizione degli scenari d’uso e dei compiti
3. definizione del profilo degli utenti e selezione degli stessi
4. definizione degli obiettivi di usabilit�
5. preparazione dei materiali e logistica.

La prima cosa da fare è decidere quali sono gli obiettivi generali del test: è molto probabile che non sar� possibile testare tutto il sito, perché non abbiamo abbastanza tempo a disposizione e sicuramente non tutte le aree del sito hanno la stessa complessit� . Dovremo quindi individuare le aree maggiormente critiche e potenzialmente problematiche.

La definizione degli scenari d’uso e dei compiti è strettamente conseguente alle decisioni prese nella fase precedente. Una volta identificate le aree critiche del sito, dovremo costruire uno o più scenari d’uso realistici e logicamente coerenti. Ogni scenario d’uso potr� comprendere uno o più compiti da eseguire. Un esempio tipico di uno scenario d’uso per un sito di e-commerce dedicato ai libri può essere questo:

Task 1: Registrarsi
Task 2: Cercare un determinato libro nel catalogo
Task 3: Acquistarlo on-line
Task 4: Verificare lo stato dell’ordine
Task 5: chiudere l’ordine

Bisogna porre particolare attenzione nella costruzione di scenari e task che non forniscano implicitamente informazioni che aiutino l’utente nel portare a termine il compito. Inoltre la descrizione dei compiti deve essere la più asettica possibile, in maniera tale che gli utenti conoscano con precisione cosa devono fare, ma possano scegliere liberamente come portare a termine il loro compito.

E’ bene che il facilitatore provi egli stesso ad eseguire i compiti previsti dal test, oppure che li faccia eseguire da un altro tester, “fuori quota”.

La definizione del profilo degli utenti dipende dall’analisi dei requisiti degli utenti finali del sito, che dovrebbe essere stata fatta precedentemente nel corso del progetto; se questa analisi manca, bisogner� attingere agli studi di marketing e di comunicazione relativi al progetto; se mancano anche questi dovrete pur avere un’idea dei destinatari del vostro sito, altrimenti perché lo state facendo?

Una volta definito il profilo, bisogner� provvedere a selezionare gli utenti. E qui si pone il primo problema: decidere con quanti utenti effettuare il test. In questo per fortuna ci vengono in aiuto Jacob Nielsen e Tom Landauer, che in una ricerca, i cui risultati sono stati pubblicati in un alertbox del marzo del 2000, hanno dimostrato che il numero totale di problemi di usabilit� emergenti da un test con n utenti presenta l’andamento tracciato in questo grafico, in cui viene riportato il numero di problemi di usabilit� rilevati in funzione del numero di utenti tester:

fig. 1
Dall’andamento della curva si ricava che effettuando un test con 5 utenti si individuano l’85% dei problemi di usabilit� del progetto. Lo stesso Nielsen consiglia di non superare questo numero di utenti, perché altrimenti l’esecuzione del test e la elaborazione dei dati rilevati risulterebbe troppo onerosa e suggerisce il seguente criterio per decidere il numero di utenti da coinvolgere in un test di usabilit� :

• 5 utenti, se il prodotto è destinato ad una sola tipologia di utenti
• 3-4 utenti per tipologia, se il prodotto è destinato a due tipologie di utenti
• 3 utenti per tipologia, nel caso in cui le tipologie di utenti sono superiori a due.

D’altra parte Steve Krug, in “Don’t make me think” è dell’opinione che è meglio non andare mai oltre i tre - quattro utenti, sempre allo scopo di rendere agile e veloce la procedura di test. Possiamo perciò affermare che: il numero ideale di utenti da utilizzare per un test di usabilit� deve essere compreso tra tre e cinque.

Qualcuno, guardando l’andamento del grafico di Nielsen-Landauer potrebbe pensare di effettuare un solo test con 15 utenti, per individuare tutti problemi di usabilit� e non pensarci più, ma non sarebbe una buona idea. A parte le difficolt� e i costi di una soluzione di questo tipo, dobbiamo ricordare che il processo di test della UI all’interno di un progetto è iterativo: infatti dopo aver corretto i problemi di usabilit� in seguito al primo test, abbiamo bisogno di testare per verificare se le nostre soluzioni hanno raggiunto l’obiettivo. Inoltre nel redesign della UI potremmo aver introdotto altri errori, frutto della nostra volont� di “migliorare” l’usabilit� , quindi la soluzione più efficace e più economica è: meglio tre test con 5 utenti, che uno solo con 15!

Veniamo ora al problema della selezione degli utenti.

Quanto è importante selezionare utenti esattamente corrispondenti al profilo individuato? E’ sicuramente importante, ma quanto? Supponiamo che il nostro profilo utente sia costituito da farmacisti, dobbiamo davvero selezionare cinque farmacisti? Anche qui dobbiamo procedere con un po’ di buon senso: se proprio non riusciamo a trovare gli utenti che corrispondono esattamente al nostro profilo (o non possiamo perché ci costerebbe troppo), allora cerchiamo tra amici, parenti, conoscenti, colleghi, purché questi soggetti abbiano un minimo di corrispondenza col profilo utente e soprattutto (nel caso dei colleghi) non abbiano preso parte alla realizzazione del progetto. Ricordiamo che qualsiasi test è sempre meglio di nessun test!

Dobbiamo ora definire meglio quali sono gli obiettivi di usabilit� del nostro test, in altre parole quali metriche adottare. Ricordiamo che l’obiettivo principale del thinking aloud è quello di identificare i problemi di usabilit� dell’interfaccia, ma potremmo anche essere interessati ad altre metriche di usabilit� , come l’efficacia, che può essere misurata attraverso il success rate (percentuale di compiti portati a termine con successo). E’ sempre il solito Nielsen che suggerisce in un suo alertbox l’utilizzo di questa metrica.

Possiamo anche pensare di misurare l’efficienza attraverso il tempo impiegato per portare a termine ogni task. Nel caso del TA dobbiamo però prendere cum grano salis le misurazioni relative all’efficienza: il processo di verbalizzazione dei pensieri influenza l’utente nel portare a termine il suo compito, ma, contrariaramente a quanto si potrebbe pensare, non ne rallenta i tempi di esecuzione: diverse esperienze condotte hanno mostrato che in alcuni casi gli utenti sottoposti alla procedura del TA eseguivano il compito nello stesso tempo o addirittura più rapidamente rispetto ad altri che eseguivano il test in silenzio. Tenendo bene a mente che il TA non è adatto per la misurazione dell’efficienza, possiamo raccogliere dati relativi a questa metrica, ma questi dati dovranno avere per noi un valore puramente indicativo.

Il TA è invece adatto a misurare la soddisfazione all’uso, raccogliendo i commenti degli utenti e, per esempio anche attraverso un questionario da sottoporre alla fine del test per raccogliere al volo le impressioni del soggetto in maniera organizzata. Se decidete di preparare un questionario, dovete seguire alcune regole e indicazioni, ma questo è un altro argomento che va approfondito a parte.

La preparazione del test si conclude con la fase di preparazione dei materiali e logistica. Per quanto riguarda la logistica, è sufficiente disporre di una stanza, di un PC collegato in rete, e di un tavolo con due sedie, una per l’utente e una per il facilitatore. Se il vostro budget lo consente, può essere utile videoregistrare la seduta di test, in maniera tale da consentire anche agli altri membri del team di sviluppo di assistere al test.

Per quanto riguarda la preparazione dei materiali, da questa fase devono venir fuori almeno due cose: il piano di test e lo script del test.

Il piano di test è un sintetico documento che deve contenere elementi riepilogativi di tutte le fasi del test: obiettivi, metodologia, lista dei compiti, profilo utenti, schema di esecuzione del test, struttura del report in cui verranno presentati i dati rilevati.

E’ utile predisporre anche uno script del test, una vera e propria scaletta degli eventi che si susseguiranno durante il test. Questo script può essere molto utile al facilitatore, perché quando si susseguono più utenti consecutivamente qualcosa (anche importante) può sempre sfuggire.

Lo script dovrebbe prevedere almeno i seguenti punti:

1. Presentazione del facilitatore e descrizione del proprio ruolo di osservatore neutrale.
2. Spiegazione degli obiettivi del test.
3. Spiegazione dei task.
4. Spiegazione della metodologia, con invito al soggetto a parlare ad alta voce durante il test.
5. Mettere a proprio agio l’utente.
6. Far firmare eventuali liberatorie o dichiarazioni di riservatezza.

7. Sottoporre eventuali questionari.

Conduzione del test
Questo è la fase che riserva le maggiori sorprese, ma è anche la più divertente, se effettuata col giusto approccio.
Come abbiamo gi� detto, la metodologia del thinking aloud prevede che l’utente (che in altri casi chiamiamo anche soggetto, per fare riferimento al fatto che è l’utente che sta eseguendo il test), nel corso del test, debba verbalizzare i suoi pensieri e le sue azioni mentre interagisce con la UI del sistema. Egli deve soprattutto esternare:

– che cosa sta cercando di fare

– che cosa vede sullo schermo e come questo si relaziona la compito assegnato
– come pensa di dover proseguire
– quali dubbi e difficolt� sta provando

Vicino all’utente è seduto un osservatore (quello che noi abbiamo chiamato anche facilitatore, e che qualcun altro chiama supervisore) che registra (su nastro video, audio, o semplicemente con carta e penna) ciò che l’utente dice ed esegue.

Il ruolo del facilitatore è molto delicato: egli deve cercare di “leggere nella mente” dell’utente senza mai interferire nell’esecuzione del test. Deve essere assolutamente imparziale e i suoi interventi devono essere molto cauti e asettici: bisogna tener conto che non tutti gli utenti sono uguali e che in genere il loro comportamento varia tra colui che riesce a esternare il flusso dei propri pensieri, dandone magari anche una spiegazione e quello che invece non dice quasi niente o peggio, borbotta e basta. Il facilitatore deve perciò stimolare i soggetti che esternano meno, senza però guidarli nell’esecuzione dei compiti. Egli non deve mai rispondere direttamente alle domande di aiuto degli utenti, ma deve spiegare loro, con garbo e pazienza, che il suo ruolo di osservatore gli impedisce di dare qualsiasi suggerimento.

Cerchiamo ora di dare alcune linee guida per la conduzione del test.
E’ consigliabile iniziare la seduta con un atteggiamento amichevole, per mettere a proprio agio il soggetto, al quale va spiegato che non è lui ad essere oggetto del test, ma l’interfaccia del sistema. Se si sta effettuando una videoregistrazione della seduta, bisogna parlare brevemente della politica di gestione della privacy e far firmare l’autorizzazione al trattamento dei dati personali.

Come prima cosa il facilitatore deve “addestrare” il soggetto sulla metodologia del test, e deve soprattutto fargli comprendere che egli non deve solo descrivere ad alta voce quello che sta facendo, ma deve anche comunicare le sue impressioni, siano esse positive o fortemente critiche verso l’interfaccia.

Potrebbe essere utile spiegarsi con un esempio, anche pratico e far fare prima del test un piccolo esercizio all’utente.
Si passa poi al momento in cui si devono illustrare i task che il soggetto deve eseguire, dosando con attenzione le parole e facendo attenzione a non dare indicazioni implicite sul compito da eseguire. Non si devono creare false aspettative. Ad esempio, evitare di dire: “non preoccuparti, questo compito è semplicissimo, sicuramente lo porterai a termine senza problemi”. E’ importante che l’elenco dei task non venga illustrato in anticipo, per evitare che un qualsiasi nesso logico tra i task possa fornire indicazioni di aiuto all’utente.

Durante l’esecuzione dei task il facilitatore deve:

• mantenere sempre un clima rilassato, magari anche aiutandosi con un pò di humor, se necessario
• stimolare il soggetto ad agire e a parlare
• essere sempre molto cortese e paziente, ma imparziale: non esagerare nel sarcasmo, nell’ironia, o in atteggiamenti troppo “amichevoli”
• vestire in maniera sobria e comoda, evitando profumi troppo intensi
• se il facilitatore ha preso parte al progetto del sistema oggetto del test, non deve mai far trasparire questo suo coinvolgimento nella realizzazione del sistema: l’utente potrebbe esserne influenzato nell’esternare le sue critiche
• non far trasparire mai in nessun modo le proprie opinioni sul livello di conoscenze del soggetto relativamente al dominio del sistema
• ricordare che il soggetto è un utente, non un designer di interfacce: evitare quindi domande che possano portare l’utente a darvi suggerimenti di design
• mantenere sempre l’attenzione sull’utente, non su se’ stessi, e non dilungarsi sulla presentazione del sistema oggetto del test
• non fare mai domande retoriche, del tipo: “non crede che sarebbe stato meglio posizionare quel tasto a destra?”
• non cedere all tentazione di correre in soccorso dell’utente in difficolt� : se l’utente ha un problema, dargli un po’ di tempo per risolverlo da solo.

  Occorre però capire quando l’utente è bloccato e non è più in grado di proseguire. Solo in questo caso, deve essere aiutato a portare a termine il task, ma annotando che il task è stato fallito. Ogni volta che si cede alla tentazione di aiutare l’utente, vengono perse delle informazioni importanti, oramai irrimedialmente viziate dall’aiuto esterno.

• l’obiettivo deve essere posto sui task da compiere e non sulle funzionalit�
• Non stancarsi mai di porre domande; quando l’utente si trova in difficolt� , o quando esprime con convinzione giudizi critici o positivi, il facilitatore deve indagare ulteriormente sulle cause delle sue difficolt� e sulle motivazioni dei suoi giudizi. In questo caso è molto facile superare quella linea sottile che separa la scoperta di ciò che davvero pensa l’utente dall’influenzarlo o distrarlo, quindi occorre essere molto attenti a porre delle buone domande.

Alcune buone domande e interventi corretti:

• Potresti dirmi a cosa stai pensando?
• Continua a parlare
• Non scoraggiarti, tenta ancora
• Qual è il tuo obiettivo?
• Che cosa ti aspetti dopo aver fatto questo?
• Questo……. può aiutarti a raggiungere il tuo obiettivo?
• Puoi farmi tutte le domande che vuoi, ma non potrò fornirti le risposte
• Prova a pensare ad alta voce quanto più ti è possibile.
• Comportati come se io non ci fossi
• Fai tutto quello che faresti come se dovessi eseguire il compito da solo, in silenzio
• Qual’è la tua prima impressione, dando un’occhiata a questa pagina?
• Mi hai detto che questa pagina ti piace molto, ma cosa ti piace di più in essa?

Alcune domande da evitare:

• Perchè hai cliccato su quel tasto? (insinua nell’utente il dubbio di aver sbagliato)
• A cosa serve quel bottone? (si porta l’utente a concentrare la sua attenzione su di un aspetto della UI che stava trascurando)
• Ti piace questa pagina?
• Ti aspettavi forse che il tasto cambiasse colore al passaggio del mouse?
  (si offre all’utente un’interpretazione preconfezionata dei suoi pensieri)

Come gi� detto, il facilitatore deve in qualche modo annotare ciò che di più importante è accaduto durante la sessione di test. Utilizzare una videocamera può essere molto utile per riesaminare tutto con calma dopo il test e per farlo osservare agli altri componenti del team di sviluppo. Non è importante annotare tutti i minimi problemi incontrati dal soggetto, ma è indispensabile descrivere al meglio gli ostacoli e i problemi relativi alle aree più critiche della UI. Può essere utile descrivere le sensazioni mostrate dall’utente e non verbalizzate: sbuffa? Borbotta? Sorride entusiasta?

Quando la sessione di test è terminata, se è stato preparato un questionario, lo si deve sottoporre all’utente per raccogliere le sue impressioni sull’esperienza appena compiuta; compilare questo questionario non dovrebbe portar via più di cinque minuti. Se avanza un pò di tempo, si può dedicare qualche minuto a intervistare l’utente sulla base degli appunti presi durante il test per ottenere ulteriori spiegazioni ed approfondimenti su quanto emerso.

Analisi dei dati e presentazione dei risultati

La fase di sistemazione ed analisi dei dati deve avvenire quanto prima; gli eventi accaduti durante il test devono essere ancora freschi nella vostra mente. Preparare un report di un test di usabilit� è abbastanza impegnativo: oltre a sistemare i dati in maniera chiara e sintetica, occorre analizzarli e formulare delle raccomandazioni volte a risolvere i problemi riscontrati dagli utenti; quest’ultima fase è quella per la quale occorre maggiore esperienza.

Il nostro report è destinato ai membri del team di sviluppo, ma anche al project manager, o in alcuni casi al cliente, per cui dovremo organizzare il suo contenuto come segue:
1 - Obiettivi del test
2 - Metodologia utilizzata.
3 - Risultati del test
4 - Raccomandazioni e proposte migliorative

5 - Valutazione dello sforzo necessario per recepire le raccomandazioni e le proposte migliorative., in termini di impegno del team di sviluppo.

Per quanto riguarda l’esposizione dei risultati del test, la prima cosa da fare è una classificazione dei problemi di usabilit� riscontrati in base al loro livello di severit� : in questo possiamo utilizzare una scala fornita dal solito Nielsen, articolata su 5 valori da 0 a 4:

0 = non è detto che questo sia un problema di usabilit� (questo valore zero serve a censire problemi incontrati dall’utente, ma non completamente dipendenti dalla progettazione della UI)
1 = Problema meramente “cosmetico”: non è necessario risolverlo a meno che nel progetto non rimanga del tempo extra.
2 = Problema di usabilit� minore: dovr� essere risolto con una bassa priorit�

3 = Problema di usabilit� maggiore: è importante risolverlo, avr� un’alta priorit�
4 = Problema di usabilit� catastrofico: deve assolutamente essere risolto prima della messa in produzione del prodotto.

Non tutti sono d’accordo con Nielsen nell’utilizzare il livello zero per contemplare gli errori che comunque si verificano, ma che probabilmente non dipendono da problemi di usabilit� . Se volete potete anche scegliere di non considerare da subito questo tipo di problemi e di tirarli fuori dal report, riducendo così la scala a quattro livelli di severit� .

L’elenco dei problemi rilevati potrebbe essere compilato utilizzando una tabella contenente i seguenti dati:

Problema nr. X: descrizione del problema

Gravit� : riportare il livello di severit� del problema
Frequenza: riportare il valore in percentuale
Spiegazione: in che modo, contesto d’utilizzo, viene fuori il poblema
Raccomandazioni: indicazioni tecniche per risolvere il problema.

In questo modo nella tabella le raccomandazioni sono collegate in maniera diretta al problema che intendono risolvere.

Pro e contro della metodologia
I principali vantaggi di questa metodologia sono:

Il TA presenta anche alcuni svantaggi:

• la modalit� di esecuzione del test è in parte lontana dall’esperienza quotidiana, in cui la verbalizzazione è assente; questo comporta che non tutti i soggetti riescono ad interpretare al meglio il senso della metodologia, e ad eseguire il test in maniera soddisfacente riuscendo nel contempo a fornire informazioni. Se il soggetto non ha un modo di ragionare “analitico”, può avere grosse difficolt� nell’eseguire il test.
• L’utente può essere tentato di giustificare sempre in maniera razionale le sue azioni per evitare di fornire un’immagine di se’ di persona che agisce a caso, senza riflettere
• Questa tecnica in un certo senso costringe il soggetto a pensare a quello che fa; questo, se normalmente è una buona cosa, nel caso del test può essere controproducente, perchè può prevenire il verificarsi di errori che in una situazione normale l’utente avrebbe commesso, perchè meno concentrato sul compito.A questo proposito, Ericcson e Simon hanno individuato tre livelli di verbalizzazione concomitante all’esecuzione del task:
  • il primo livello riguarda informazioni che i soggetti verbalizzano senza problemi, in quanto gi� presenti in forma verbale a livello cosciente si tratta di quelle informazioni che spesso mentalmente ripetiamo a noi stessi mentre facciamo qualcosa: “dov’era quel file sul progetto XXX? Credo nella cartella Documenti/Progetti/XXX)
  • il secondo livello riguarda informazioni che sono presenti a livello cosciente, ma non in forma verbale, per cui lo sforzo di verbalizzazione nfluenza i tempi di esecuzione del compito ma non influenza i processi mentali dell’utente.
    (in genere non ripetiamo mentalmente il percorso che facciamo ogni giorno per andare a lavoro, però esso è ben presente nella nostra mente)
  • il terzo livello riguarda informazioni a cui l’utente non avrebbe nemmeno prestato attenzione se non gli fosse stato chiesto; queste sono informazioni che non sono presenti a livello cosciente, e la cui verbalizzazione influenza i processi mentali dell’utente.(a volte, nell’interazione con una UI, compiamo delle scelte irrazionali, che non hanno nella nostra mente una giustificazione: per es. clicchiamo su di un immagine perchè ci piace)
• Il metodo non è adatto alla misurazione delle performance e della efficienza della UI.

Alcune varianti della metodologia

Il TA in senso stretto prevede che il ruolo del facilitatore sia assolutamente passivo: egli deve solo prendere nota di ciò che accade. Il metodo illustrato in questo articolo è più vicino ad una variante del TA, e cioè il metodo detto della valutazione cooperativa: come abbiamo visto, in questo metodo vi è interazione tra l’utente e l’osservatore, sia pure con molta attenzione da parte di quest’ultimo nel non influenzare il soggetto, ma solo nello stimolarlo e nell’indagare più a fondo nei momenti critici dell’interazione. E’ sicuramente più produttiva rispetto al TA in senso stretto perchè consente di deresponsabilizzare l’utente e di ridurre il suo stress da eccessivo carico cognitivo.

Altre varianti di questa metodologia sono:

• interazione costruttiva, in cui due utenti utilizzano insieme il sistema e possono cooperare. Adatto per i test con bambini. E’ una situazione più naturale rispetto a quella col singolo utente, ma può aver il problema che la cooperazione in realt� non avvenga a causa del fatto che gli utenti possono avere diverse strategie di apprendimento e di problem solving
• retrospective thinking aloud, in cui l’utente effettua la verbalizzazione di pensieri e azioni a posteriori, mentre osserva la videoregistrazione del suo test. Con questo metodo è possibile raccogliere le informazioni con più calma, senza l’assillo del poco tempo a disposizione e della contemporaneit� con l’interazione dell’utente; richiede però appunto più tempo e maggiori risorse.

Concludendo, il Thinking Aloud viola una delle leggi fondamentali di qualsiasi esperienza sperimentale: ciò che è oggetto dell’esperimento non deve essere influenzato dall’esperimento stesso (ricordate la storiella del gatto di Schroedinger?), eppure è di un’efficacia straordinaria. Chiunque non abbia mai fatto prima un test di usabilit� rester� stupito di fronte alla grande quantit� di dati e di informazioni che questa metodologia offre.



Riferimenti

Jakob Nielsen, Usability Engineering, AP Professional, 1994

Jeffrey Rubin, Handbook of Usability Testing, John Wiley & Sons, 1994

Joseph S. Dumas, Janice C. Redish, A practical Guide to Usability

Testing Revised Edition, Intellect, 1999

Steve Krug, Don’t Make Me Think, Hops Libri, 2000

Michele Visciola, Usabilit� dei siti web, Apogeo, 2000

Kelly Goto, Emily Cotler, Web Redesign, Apogeo, 2000

- Userdesign.com, Comparison of Usability Evaluation Methods,

- Society for Technical Communication - Usability Special Interest Group, usability toolkit,

- James Hom, The Usability Methods Toolbox,

- Clayton Lewis, John Rieman, Task-Centered User Interface Design - A Practical Introduction,

- John S. Rhodes, Usability Metrics,

- Usability.gov, Conducting and Using Usability Tests,

- Jakob Nielsen, “Why You Only Need to Test With 5 Users”,

- Jakob Nielsen, “Severity Ratings for Usability Problems”;