In alcune definizioni la learnability – tradotta come “apprendibilità” o “facilità di apprendimento” – è considerata una delle sottocaratteristiche dell’usabilità. Per esempio, nella definizione di Nielsen. O anche nella definizione della norma ISO/IEC 25010, licenziata nel 2011 e che sostituisce la storica ISO/IEC 9126 (che comunque già all’epoca a sua volta includeva pure la learnability come dimensione dell’usabilità).

In questi casi, la learnability viene definita grosso modo come…

La ISO/IEC 25010 dà ora una definizione un po’ più contorta, ma riguarda sempre la facilità di apprendere l’uso di un sistema con efficacia efficienza e soddisfazione in determinati contesti.

Il problema della sovrapposizione fra usabilità e facilità di apprendimento

Da ciò emerge come molto spesso nei test di usabilità si stia di fatto valutando la learnability. Se l’utente riesce a capire subito come fare a eseguire i compiti che gli vengono proposti su un’interfaccia con la quale non ha familiarità, allora il sistema è facile da apprendere e anche usabile. Se invece impiega diversi tentativi e commette diversi errori, è meno facile da apprendere e meno usabile.

Il problema con questa definizione è che appunto in molte circostanze si sovrappone all’usabilità, nonostante formalmente come visto le sia subordinata, e non è quindi particolarmente utile. Anzi, è confusiva.

La realtà, che conosciamo bene, è che la gente su molti sistemi impara. In molti sistemi complessi è persino previsto un periodo di training. Quindi per tali sistemi (app, webapp, siti e servizi online, software di back-office per operatori specialistici in vari settori, dal finanziario, al medico, all’amministrativo) il primo approccio non è sempre quello migliore per valutare l’usabilità del sistema, almeno non dal punto di vista della produttività futura.

Certo, per siti di pubblico dominio, dove l’utente non è vincolato all’uso e dove l’uso non è ripetuto, avere una ottima learnability, cioè una capacità di trovare le informazioni ed eseguire compiti al primo tentativo, è importante, ed è per questo che spesso nei test di usabilità si valuta proprio quello, anche senza consentire un periodo di addestramento al sistema. Il primo sguardo, il primo impatto è in quei casi quello che ci interessa valutare. Ma non è sempre così.

L’apprendimento nel tempo: un secondo significato per la learnability

Come correttamente ci ricorda Jeff Sauro, infatti, nei sistemi che prevedono addestramento questa accezione di learnability non è adeguata. Ne esiste infatti un’altra:

Usabilità nel tempo, insomma.

Si può valutare quindi come migliora la prestazione (in termini di efficacia, di tempo, o di numero di click per svolgere lo stesso compito, ad esempio) per lo stesso compito, in prove successive ripetute dagli stessi operatori a distanza di tempo.

E sappiamo che, in applicazioni complesse, con l’abitudine all’uso si riduce il tempo di esecuzione dei task e aumenta la loro accuratezza. Questi miglioramenti seguono la power law of practice. La legge suggerisce che l’apprendimento progressivo non avviene a un ritmo costante, ma segue un andamento che alcuni autori descrivono come logaritmico e altri (criticandoli) come esponenziale. Tralasciando i dettagli matematici¹, significa semplicemente che se si impara in tempi relativamente rapidi la metà delle funzioni di un sistema, servirà un tempo più alto per imparare l’altra metà. Una discussione più dettagliata della curva di apprendimento è su wikipedia.

Il paradosso della curva di apprendimento ripida

È interessante notare che quando si parla di “curva di apprendimento ripida” si intende qualcosa del genere, sebbene nel senso comune il significato inteso sia l’opposto. In una curva di apprendimento ripida, a essere ripida è la parte iniziale della curva, che indica il livello di apprendimento nel tempo.

In questa curva viene rappresentato il livello di apprendimento o di accuratezza di una prestazione, nel tempo, indicato in tentativi successivi.

Questa curva ripida indica però che il livello di apprendimento migliora rapidamente all’inizio, per poi rallentare (gli incrementi sono minori con l’aumentare dei successivi tentativi). Invece nel senso comune con “curva di apprendimento ripida” si intende una materia o un’attività molto difficile da approcciare, complessa, che richiede molto impegno e fatica all’inizio. E che non è affatto rappresentata da questa curva!

Per quanto riguarda i tempi di esecuzione in tentativi successivi, se i miglioramenti sono rapidi nei primi tentativi, sono ben esemplificati da una curva di questo tipo:

In questa curva viene indicato il tempo di esecuzione nel tempo, ovvero in tentativi successivi.

Dopo i primi miglioramenti, la curva (ripida, ma in discesa) si addolcisce, e i miglioramenti nel tempo di esecuzione sono più limitati. D’altra parte, come è ovvio, con l’esperienza non si fa che avvicinarsi al tempo di esecuzione ottimale, che costituisce il limite definitivo.

Prestazione e valutazione soggettiva

Da dati riportati dallo stesso Sauro, non solo gli utenti “esperti” o power user – quindi che hanno una ripetuta storia di utilizzo del prodotto – mostrano efficacia ed efficienza maggiore nell’eseguire gli stessi compiti, ma danno anche valutazioni migliori del prodotto rispetto ai novizi. Questa è anche la mia esperienza. Addirittura, Sauro parla solo dell’usabilità percepita, mentre alcuni miei dati segnalano anche un aumento della valutazione da 0 a 10 nel Likelyhood To Recommend e nel Net Promoter Score di pari passo con l’apprendimento del sistema. Questo potrebbe non applicarsi a tutti i casi e a tutti i prodotti, ed è semmai qualcosa da analizzare in ogni progetto, per capire eventualmente perché accade o non accade.

Cosa significa tutto questo per i test di usabilità

L’esistenza di queste due accezioni del termine “learnability” in generale significa che nei nostri test di usabilità dovremmo, di volta in volta, decidere qual è l’approccio alla valutazione più adatto al tipo di sistema. E anche alla conseguente valutazione di efficacia, efficienza e soddisfazione. Ad esempio, misurando il tasso di efficacia e i tempi di esecuzione degli stessi task in sessioni ripetute nel tempo, man mano che gli utenti usano il sistema (o passano da un prototipo ad un più raffinato ad una versione sempre più funzionante, se si lavora in fase di sviluppo). È una delle rare situazioni in cui è anche possibile utilizzare gli stessi utenti in test differenti, per esempio: perché lo scopo è proprio valutare il miglioramento nel tempo.

Non solo: la velocità di apprendimento può essere al centro anche di una serie di test di usabilità su prodotti simili ma differenti, ad esempio una serie di tool che svolgono le stesse funzioni e fra i quali, magari, si vuole scegliere. In quei casi è bene che il panel di partecipanti ai test sia diverso per evitare effetti di interferenza fra un tool e l’altro, anche se questa accortezza non è sempre possibile e addirittura consigliabile².

Come si vede le variabili in gioco si moltiplicano ed è proprio per questo che serve una valutazione professionale adeguata del piano di test più appropriato alla situazione.

In definitiva, la facilità di apprendimento è un tema da tenere sempre presente in ogni tipo di test: sia quando questa corrisponde di fatto all’usabilità (nei siti e nelle applicazioni di uso occasionale), sia quando sottende un apprendimento nel tempo. Diverse modalità di pianificazione dei test sono di conseguenza possibili, purché tengano in adeguata considerazione tutti questi aspetti.

Nel 1989 Jakob Nielsen, oltre a semplificare le stesse regole di “design usabile” riassumendole in semplici principi euristici, ha proposto di semplificare i test di usabilità.

Negli anni ’80 spesso questi erano complessi e onerosi:

1. Si svolgevano in veri e propri laboratori
2. Utilizzavano molti partecipanti come negli esperimenti scientifici per ottenere indicazioni con elevata attendibilità
3. Si svolgevano su prodotti già in parte implementati, con la conseguenza di dover spendere nuove ore/uomo di programmazione per le modifiche che i test avrebbero reso necessarie.

Nielsen e la Discount Usability

Secondo Nielsen questi vincoli ostacolavano la diffusione su larga scala dell’usabilità. Suggeriva così un approccio alternativo:

• utilizzare molti meno utenti: ad esempio, solo 5 per ogni tornata di test.
• eseguire i test su prototipi (anche cartacei) anziché sui software sviluppati
• focalizzare i test soprattutto sull’osservazione qualitativa dei problemi, anziché sulla misurazione attendibile di aspetti quantitativi dell’esperienza d’uso
• ripeterli più volte (almeno 3) nel corso del processo di progettazione.

Secondo l’approccio di Nielsen, i test di questo tipo non servono a decidere con elevata affidabilità quale interfaccia è migliore fra una versione A e una versione B (attività che richiede effettivamente un numero elevato di utenti). Ma “solo” per far emergere problemi precocemente, quando è più conveniente intervenire e modificare l’interfaccia, in particolare perché non si è ancora investito nell’attività di programmazione.

Questa era la ratio dell’espressione “discount usability” coniata da Nielsen, e che poi è stata ripresa e ulteriormente semplificata da Steve Krug nei suoi libri. Il costo si intende ridotto rispetto all’usabilità “anni ’80”, e non nel senso che non costi niente: ogni attività deve costare il giusto. Tipicamente, fra il 10 e il 20% del budget di progetto (includendo in questo budget non esclusivamente i test, ma anche i test).

Il protocollo eGLU

Ispirato in parte dagli approcci di Nielsen e Krug, il Dipartimento della Funzione Pubblica (DFP) ha dato vita nel 2012 ad un Gruppo di Lavoro per l’Usabilità (GLU). Dal 2013 ho il piacere di coordinare con il collega Simone Borsci un sottogruppo di professionisti e accademici che si è occupato di definire un semplice protocollo, cioè un testo con delle istruzioni operative passo passo, per la progettazione, la conduzione e l’analisi di semplici test di usabilità.

Gli scopi del protocollo

Gli scopi sono due:

1. Anzitutto, diffondere la cultura dell’usabilità. Constatato che, quando il gruppo è nato (ma in tutt’Italia ancor oggi) nella PA spesso i test di usabilità non si sapeva nemmeno cosa fossero, salvo poche e lodevoli eccezioni, si è deciso di spiegare a “inesperti” di che si trattasse.
2. Come strategia di diffusione, si è ritenuto che far capire che con una guida passo-passo anche dei non esperti – come ad esempio i redattori web delle PA -potevano provare a preparare dei test semplificati. Non per sostituirsi agli esperti, come talvolta erroneamente è stato inteso, ma per rendersi conto in prima persona dei problemi di usabilità che altrimenti non sarebbero mai stati evidenziati. In questo modo, provando a eseguire dei semplici test, per quanto semplificati (ma provando comunque a evitare gli errori più comuni per dei profani), l’idea era che i problemi di usabilità sarebbero diventati evidenti a tutti, e sarebbero stati fatti presenti ai responsabili.

In questo modo, nelle successive gare d’appalto, ci sarebbe stata maggior consapevolezza dei problemi legati all’usabilità e si sarebbero potute bandire fra le altre cose delle attività di testing.

L’applicazione in situazioni di mercato

Il Protocollo eGLU è giunto ora alla sua versione 2.1 e la scommessa pare per il momento vinta. La procedura infatti è utilizzata non solo da alcuni enti pubblici internamente, ma anche da aziende che lavorano per gli enti pubblici, perché è diventata sinonimo di “procedura consolidata” e riconosciuta per i test di usabilità nella PA.

Il Protocollo eGLU è stato infatti anche inserito come procedura per l’analisi dell’usabilità all’interno delle linee guida di design per i siti della PA. Ma in quanto procedura di base, può essere estesa a piacere dai professionisti.

Formazione e divulgazione

In quanto frutto di un lavoro pubblico, il Protocollo eGLU è scaricabile e leggibile, con tanto di allegati che aiutano nell’elaborazione dei risultati, sul sito del Dipartimento, ed è dunque utilizzabile da chiunque, sia per il proprio lavoro (da proporre ad enti e aziende) che come attività di autoformazione.

E la formazione è un altro dei capitoli collegati al protocollo: in quanto strumento “riconosciuto”, è ora più facile parlare di test di usabilità in generale e di Protocollo eGLU in particolare anche nella formazione per enti pubblici.

Per chi fosse interessato, su Usabile.it è possibile richiedere una formazione dedicata sui test di usabilità e sul Protocollo eGLU.

Il Protocollo come procedura di base per aggiunte modulari

Nello specifico, una delle caratteristiche su cui abbiamo creduto di impostare il lavoro di stesura del protocollo a partire dalla versione 2.0 è quella della modularità e della sua estendibilità.

Il protocollo eGLU è infatti pensato come una procedura di base che possa prevedere aggiunte ed estensioni di metodo laddove un professionista che lo adotti lo ritenga utile. Ad esempio:

• Si può eseguire un test secondo il Protocollo eGLU, ma scegliere di raccogliere anche i tempi di esecuzione dei task (non trattati in questa procedura, perché impossibili da spiegare a un livello di base), se il tipo di test lo richiede.
• O integrarlo con la rilevazione dei movimenti oculari (se ha senso per il tipo di test).
• O aggiungere questionari di altro tipo (come il SEQ, per esempio).
• O prevedere il calcolo dei click o degli errori.

E’ cioè possibile partire dal Protocollo eGLU, riferimento “compreso” all’interno della PA, per svolgere anche analisi e test più complessi.

Oltre il protocollo: strumenti di HCD nei bandi di gara

E’ sufficiente? No. Oltre alla formazione, che va sempre condotta e portata avanti, sull’argomento, abbiamo preso atto che ogni buon sito dipende in maniera stretta dalla bontà dei processi che lo generano. E quindi abbiamo iniziato a immaginare una guida, un aiuto per l’inserimento di attività HCD all’interno dei capitolati dei bandi pubblici, una volta constatato che questo inserimento è raro e talvolta approssimato.

Questa guida è contenuta nel documento “Le linee guida appalti web HCD” sulla stessa pagina del GLU linee guida.

Gli strumenti offerti (e migliorabili) tolgono ogni alibi

C’è da auspicare una sempre maggior circolazione e diffusione di Protocollo eGLU e delle Linee guida per gli appalti web HCD. Fare test di usabilità all’interno di un progetto web non è infatti una questione di soldi: quelli vengono spesi comunque, solo che senza spenderli per i test si spendono peggio. E’ una questione di volontà, e di capire che questo (assieme alle altre pratiche HCD) è l’unico modo per costruire un sistema digitale veramente utilizzabile dai cittadini ed evitare di buttare i soldi dei progetti come tante volte è stato purtroppo fatto, anche di recente, in Italia.

Ma la novità è che se queste opportunità non verranno colte, non si potrà invocare la mancanza di strumenti o il loro costo: dipenderà esclusivamente delle scelte dei dirigenti e dei responsabili dei progetti.

Credits: L’immagine dell’articolo è tratta dal film Kitchen Stories, che vi consigliamo di vedere.

C’è una cosa che tutti coloro che hanno svolto test di usabilità sanno: non bisogna fidarsi dei giudizi degli utenti. In particolare, capita abbastanza spesso che utenti che hanno fallito un determinato compito, lo giudichino a posteriori comunque facile o molto facile!

Nielsen ci ha costruito sopra addirittura una “Legge” dell’usabilità: non ascoltate gli utenti. Le ragioni che Nielsen riporta sono senz’altro vere:

1. Gli utenti tendono a dire ciò che è più socialmente accettabile (e parlar bene di qualcosa, durante un test su quella cosa, è più accettabile che criticarla)
2. Spesso non si ricordano quello che hanno fatto davvero
3. Spesso tendono a razionalizzare il proprio comportamento, cioè a darsi delle spiegazioni a posteriori.

Io aggiungo che, inoltre, alcuni utenti possono non capire di aver sbagliato (è abbastanza evidente se si usano le verbalizzazioni, cioè il thinking aloud, durante il test) e che, infine, possono sbagliare nell’esprimersi secondo la scala di valutazione post-test. Solitamente si tratta di item di tipo likert a 5 o 7 punti, e talvolta la formulazione verbale non è sufficientemente chiara o gli utenti la fraintendono per proprie idiosincrasie.

Quantificare la distanza fra valutazioni e prestazioni

Tutto questo però non significa affatto che le metriche di soddisfazione (i giudizi, quello che gli utenti dicono) non vadano raccolte. Semplicemente, vanno interpretate con alcune cautele.

Ce lo ricorda in un interessante articolo Jeff Sauro di Measuringusability.com, sito dedicato ai dettagli statistici del mestiere dell’usabilità. In un’analisi comparativa di vari studi con oltre 19.000 tentativi di completamento di un task, ha comparato il livello di completamento del task con il giudizio successivo. Vi risparmio qui i dettagli di metodo, che comprendono una normalizzazione di diverse scale di misura adottate dai diversi studi. La conclusione di Sauro è che il 14% degli utenti che falliscono un compito lo giudicano con il massimo del punteggio di soddisfazione. Circa uno su sette.

Il dato non è altissimo, dice Sauro. Non abbastanza da costruirci sopra una “regola assoluta” (il riferimento è a Nielsen). Tuttavia, i dati possono essere, come al solito, letti in molti modi. Se oltre al punteggio massimo includiamo anche i soggetti che danno un giudizio comunque positivo del compito (scegliendo almeno il 70% del punteggio massimo, come sarebbe a mio avviso corretto), il dato è ben più soprendente: ben un utente su 3 (32.5%) tra quelli che falliscono un compito alla fine lo giudicano positivamente!

Uno su tre è davvero molto. Questo non significa che i punteggi di soddisfazione non siano utili: vi è comunque una correlazione positiva fra punteggi di soddisfazione e successo, come anche Nielsen riconosce: una correlazione che varia fra 0.44 e 0.51, secondo alcuni dati riportati da Sauro. Buona su grandi numeri, ma certamente poco affidabile per test con pochi soggetti come abitualmente si fa in Italia. Certamente il punteggio di soddisfazione spiega solo una parte del completamento dei compiti.

Vedendo il bicchiere mezzo pieno, Sauro nota che se si guarda solo ai punteggi estremi (il massimo o il minimo di soddisfazione), be’, allora oltre l’80% degli utenti che assegnano il punteggio massimo a un compito l’ha effettivamente superato, e il 20% l’ha fallito, regola 80/20 che vale anche all’inverso (solo il 20% di chi giudica con il giudizio più negativo un compito l’ha superato, mentre l’80% l’ha fallito). E, in definitiva, quando un utente fallisce un compito ha una probabilità di 6 volte maggiore di assegnargli un giudizio inferiore al massimo, rispetto al massimo.

Il merito dell’articolo di Sauro è quello di dare una quantificazione dell’errore di valutazione. Ma comunque la si giri, è evidente che la correlazione fra successo e giudizio (espressione più generale del rapporto fra usabilità reale e usabilità percepita) è tutt’altro che perfetta, soprattutto se includiamo anche i punteggi non estremi.

Come raccogliere i dati di soddisfazione e interpretarli in maniera utile

Tuttavia, ci sono ottime ragioni per continuare a misurare anche la soddisfazione soggettiva. Anzitutto, per valutare se i dati si discostano molto da quelli di Sauro. Inoltre, perché l’usabilità percepita, la soddisfazione, possono aumentare la tolleranza anche verso siti dall’usabilità subottimale. Infine, perché è possibile misurare la soddisfazione in modi vari, in maniera da trarre indicazioni utili al redesign.

Un approccio per “aree di design”

Ad esempio, invece di concentrarsi solo sulla facilità dei singoli task, è utile usare un questionario finale di valutazione generale di vari aspetti del design. Comprendenti domande sulla navigazione, altre sulle funzioni di ricerca, altre sulla grafica, altre sui contenuti e il linguaggio.

Proprio perché sono tutte misure di soddisfazione (e dunque tutte soggette alle medesime distorsioni), è particolarmente interessante notare le differenze interne fra le aree. Se quelle legate alla grafica risultano complessivamente più positive di quelle legate alla navigazione, possiamo avere un chiaro segnale che la navigazione va migliorata.

Interpretare i dati oggettivi attraverso quelli soggettivi

Oltre a questo approccio differenziale per aree, che può servire a dare priorità agli interventi di redesign, evitando di toccare ciò che funziona per concentrarsi su ciò che funziona meno, è anche possibile usare questi risultati per guidare l’interpretazione dei risultati prestazionali del test. Guardando per esempio le valutazioni dei singoli soggetti, è possibile reinterpretare le difficoltà che hanno incontrato durante l’esecuzione, per capire cos’è che li confondeva. Anche qui, particolarmente utile è l’analisi delle differenze: cioè valutare le diverse difficoltà di utenti che hanno dato valutazioni opposte ad un’area, per esempio la navigazione, in base alla loro capacità dimostrata di muoversi fra i menu.

Le valutazioni soggettive sono insomma correlate in maniera imperfetta con le prestazioni, ma, se correttamente raccolte, sono dati utili sia per guidare l’interpretazione dei risultati del test, sia per identificare in maniera rapida le aree del design sulle quali intervenire più tempestivamente. Informazioni che, senza i dati soggettivi (cioè solo con i dati di prestazioni) sarebbe molto più difficile identificare con chiarezza.

Per approfondire

Aggiornamento 2015 Questo e altri argomenti correlati vengono trattati più diffusamente nel corso avanzato: Misurare l’usabilità, disponibile in modalità “in-house” per enti e aziende che lo richiedono, e che affronta i dettagli di metodo nella valutazione dell’esperienza dell’utente con test e questionari.

Sebbene i siti web possano essere divisi secondo tipologie che si basano sugli
obiettivi, è lecito assumere in ogni caso che vi sia un utente interessato
all’interazione, dalla quale vuole ottenere informazioni o più genericamente
accesso a beni o servizi.

Scopo di un sito web è quindi senz’altro consentire la disponibilità
di questo accesso. I modi sono quelli della comunicazione ipertestuale
e ipermediale: l’utente naviga all’interno delle pagine del sito alla
ricerca dell’accesso a ciò che gli interessa (un bene, un acquisto, un’informazione).

Gli studi di usabilità si servono di due ampie categorie di interventi
per migliorare questa interazione. La prima, più economica, è speculativa.
Una serie di esperti analizzano il sito o un prototipo dell’interfaccia
sulla base di alcuni assunti, alla ricerca di problemi, fornendo
in output una serie di osservazioni e dei suggerimenti per possibili miglioramenti.
La seconda, più costosa e più precisa, si basa sull’osservazione diretta
dell’utente-tipo alle prese con il sito in fase di progettazione o
di beta testing. A seconda dei compiti svolti dall’utente e delle difficoltà
incontrate si traggono dei suggerimenti per la progettazione.

Entrambe le categorie di tecniche sono utili, dato che risolvere tutti
i problemi di usabilità in un sito è praticamente impossibile, come
nota Jakob Nielsen. Tuttavia riuscire a ottenere che il 85% degli utenti
non incontri seri problemi di usabilità sarebbe un risultato di cui essere
molto soddisfatti, e tutt’altro che scontato. Ma quali sono dunque le
tecniche disponibili, e a quali di queste è più opportuno ricorrere?

Metodi analitici

Fra i metodi analitici dell’usabilità dobbiamo citare soprattutto:

1. Analisi del compito (task analysis)
2. Cognitive walkthrough
3. Valutazioni euristiche

Sebbene siano sistemi differenti, tutte utilizzano come abbiamo detto
degli esperti che valutano il sito. E’ importante sottolineare (e sottolineare
al cliente) che questa analisi non viene condotta su basi soggettive,
secondo il gusto dell’analista o basandosi su una generica esperienza
arbitrariamente maturata. L’analisi viene condotta secondo principi che
sono stabiliti su base empirica. La task analysis richiede l’analisi delle
componenti del compito, il calcolo dei passi necessari allo svolgimento
di una procedura. Nel caso del cognitive walkthrough si tiene anche conto
delle caratteristiche cognitive dell’utente (competenze richieste, conoscenze
di dominio, eccetera), verificando sull’interfaccia/prototipo l’esistenza
di eventuali problemi rispetto alle previsioni.

La valutazione euristica invece valuta l’interfaccia sulla base di liste
di euristiche. Tali euristiche sono principi che hanno un elevato
valore predittivo perché rappresentano la sintesi dei problemi
di usabilità più frequenti organizzati in categorie. Le euristiche
di Nielsen, ad esempio, sono ottentute tramite analisi fattoriale
su una base di 249 problemi riscontrati in studi di vario tipo.

I metodi analitici sono particolarmente utili in fasi precoci del progetto,
quando i problemi di usabilità sono talmente numerosi che non avrebbe
senso sprecare dei soggetti (che rappresentano un notevole costo)
per rilevare errori che potrebbero essere facilmente identificati anche
da uno o più esperti.

Metodi empirici

Tra le tecniche empiriche, con l’uso di soggetti, abbiamo:

1. Analisi dei tempi di esecuzione
2. Questionari di soddisfazione
3. L’osservazione diretta con annotazione degli errori
4. Il pensare ad alta voce (thinking aloud)

e altre. Alcune richiedono laboratori attrezzati con telecamere o dispositivi
di rilevamento temporale, eventualmente specchi unidirezionali e così
via, tutti dispositivi che innalzano naturalmente i costi. Tutte richiedono
dei professionisti addestrati, perché quando si ha a che fare con
lo studio del comportamento di soggetti ci si trova quasi sempre a dover
progettare dei veri e propri disegni sperimentali per tentare di tenere
sotto controllo i problemi legati alla variabilità interindividuale e
alla scarsa naturalezza della situazione. Questo presuppone una certa
esperienza nella preparazione del setting, nella conduzione del test e
nell’analisi dei risultati, che andranno opportunamente classificati e
sottoposti laddove è possibile ad analisi statistica.

La durata di queste tecniche è molto variabile e naturalmente incide
sui costi. Le metodiche che prevedono l’osservazione e l’analisi del comportamento
dei soggetti possono essere più utili in fasi avanzate del processo di
progettazione: tipicamente dopo un redesign seguito magari alle prime
valutazioni effettuate con i metodi analitici che abbiamo visto sopra,
oppure laddove si voglia avere uno studio preciso su funzioni specifiche
di un’interfaccia, piuttosto che su aspetti di carattere generale. Ancora,
le tecniche empiriche ripetute più volte in fasi diverse consentono
di quantificare con buona precisione i miglioramenti ottenuti.

E’ importante insomma porsi di volta in volta gli obiettivi e le domande
più appropriate al progetto e usare le tecniche di analisi dell’usabilità
più adeguate all’obiettivo che ci si è posti. Questa capacità di focalizzare
le tecniche sui problemi appropriati è determinante. Una tecnica condotta
benissimo, ma a partire da presupposti errati può, com’è evidente,
portare alla totale invalidazione dei risultati, con conseguente spreco
economico.

In generale è bene, se si dispone di un budget adeguato, distribuire
l’investimento in usabilità su diversi test svolti a più riprese nel corso
della progettazione, in maniera da correggere e ritestare in un processo
iterativo e con tecniche differenti il prodotto. Ciò comporta un certo
dispendio da parte di designer e progettisti, e può talvolta essere visto
con riluttanza dallo staff di progettazione, ma porta a indubbi vantaggi
nel momento in cui il prodotto finale ha un ciclo di vita più lungo,
almeno nel senso che non necessiterà di premature modifiche (spesso le
modifiche a posteriori su un sito già pubblicato sono molto costose) e
darà una maggior soddisfazione agli utenti.

Nonostante questi vantaggi, la cultura dell’usabilità sul web non è molto
diffusa in Italia probabilmente per due motivi:

1. da una parte essa richiede un lavoro d’equipe che coinvolge esperti
   di usabilità e designer/progettisti che può non essere semplice
   far accettare a tutti gli elementi coinvolti;
2. dall’altra in certa ottica manageriale (non certo quella che privilegia
   il cliente e la qualità del lavoro) si preferisce tagliare i costi
   per attività delle quali non si apprezzano benefici immediati ed evidenti.

Tuttavia una successiva analisi degli esiti del sito in termini di accessi,
gradimento e converting-rate (la percentuale di utenti fra quelli che
accedono al sito che riesce a portare a termine un compito significativo)
potrà dare una misura della validità o meno di tale rinuncia. In fondo
lo scopo è quello di aumentare le transazioni fra utente e sito. Non solo
l’usabilità propone dei metodi per farlo, ma ne può essere addirittura
verificata la portata a posteriori. Da tali verifiche come è intuibile
si potranno trarre indicazioni anche economiche piuttosto precise sui
rapporti costi/benefici delle analisi di usabilità.

Le analisi di usabilità si differenziano in definitiva dalle semplici
valutazioni svolte con altri approcci soprattutto per la verificabilità
dei risultati e per il contributo concreto che portano al processo di
design. Tale contributo focalizza l’attenzione su aspetti specifici
e realizzabili, anziché ridursi ad una semplice pagella del progetto,
che non sarebbe di nessuna utilità agli sviluppatori. E’ importante sottolinearlo:
l’usabilità non dà pagelle ai designer, ma tenta di aiutarli a risolvere
problemi che emergono durante l’interazione tra utente e interfaccia.
Sottolineare questo aspetto è compito degli esperti di usabilità
e può alle volte contribuire anche a vincere le resistenze alla collaborazione
di una parte dello staff coinvolta nel progetto.