Un lettore, riprendendo un discorso fatto qualche tempo fa su questo sito, pone sul suo blog un quesito interessante: se è vero che gli utenti comettono errori perché “usano prima di capire”, dice, non sarà bene sfruttare i loro errori per progettare le varie funzionalità? Interpretare cioè i loro errori come consulenze gratuite? Attraverso l’errore l’utente ci suggerisce come si aspetta di usare il sistema. Ci insegna il suo modello mentale.

Questo è proprio il punto di forza dell’usabilità: imparare empiricamente dall’utente. Nei commenti di quel sito però qualcuno ammonisce: assecondare sempre l’utente può dar vita ad incongruenze. Ed è vero anche questo. Dovremmo “assecondare” gli errori che hanno un’elevata probabilità di essere commessi anche da altri (sebbene non da tutti) a patto di non introdurre modifiche peggiorative.

Ma come capire quali errori devono dar vita a modifiche e quali sono idiosincratici, o, peggio, ci porterebbero a fare modifiche dagli effetti collaterali negativi?

Il caso delle caselle di input che non comunicano chiaramente la propria funzione

Un esempio può aiutare a capire meglio. Supponiamo che io scambi la casella di iscrizione alla newsletter per la casella di ricerca di un sito e invece di inserirci il mio indirizzo email ci inserisca il termine che voglio ricercare, commettendo così un errore.

Può darsi che quel giorno io sia mezzo addormentato, cosa non improbabile, oppure che ci sia un problema dell’interfaccia. Se lo stesso errore viene commesso da diversi utenti, probabilmente quella casella è mal disegnata. Ma anche se non viene commesso da molti utenti può darsi che la casella sia comunque migliorabile. Come capirlo?

Analizzando posizione, forma, colori, testi utilizzati. Forse è posizionata dove molti si aspettano un motore di ricerca. O forse c’è una cattiva comunicazione del formato del dato, o magari etichette verbali confondenti. Una casella senza anticipazione del formato (ad esempio attraverso il testo di segnaposto) o con messaggi generici è più “fraintendibile”:

Fig. 1 – Nonostante il titolo “newsletter”, un utente distratto può scambiare questo elemento per un search box, se posizionato in posizione ambigua, complice anche l’assenza di informazioni sul dato nella casella e la genericità del bottone. Infatti, mentre il titolo può essere “sorvolato”, casella e bottone hanno maggiori probabilità di essere visti.

Fig. 2 – In questa alternativa, il contenuto dell’input box riduce la probabilità di errori

Fig. 3 – In quest’ultimo esempio, il formato del dato viene esemplificato e il verbo nel bottone cambiato, riducendo al minimo l’ambiguità.

L’errore, se viene rilevato, deve sempre dar vita ad un ripensamento. Ma non tutti gli errori devono dar vita ad una modifica dell’interfaccia. Se cambiare l’interfaccia significa sconvolgere le aspettative degli altri utenti – ad esempio invertendo le posizioni di casella di iscrizione alla newsletter e casella di ricerca, per venire incontro al mio incauto errore – potremmo addirittura peggiorare le cose. Ad esempio, potremmo scoprire che ora è la maggioranza degli utenti che inserisce l’indirizzo email nella casella di ricerca! Al contrario, la modifica illustrata nelle immagini qui sopra è sicuramente migliorativa, perché non introduce altre ambiguità, ma, anzi, le elimina.

Gli errori vanno insomma filtrati e analizzati. Ed è questa è la parte più difficile del lavoro.

L’utente “tipo” non esiste, eppure ci assomiglia

Una delle critiche che vengono rivolte all’usabilità è che:

“ogni utente è diverso, non esiste l’utente tipo, perciò il designer deve prendersi le sue responsabilità e progettare, non farlo fare all’utente”.

Vero. Ma alcuni errori curiosamente ricorrono. Dipendono anche dall’interfaccia e possono essere evitati. E gli utenti hanno in comune molto più di quanto si pensi:

• Il verde e il rosso nella nostra cultura hanno più o meno lo stesso significato simbolico un po’ per tutti, anche se ciascuno di noi è diverso.
• Il verso di lettura è sempre da sinistra a destra e dall’alto in basso.
• Il fuoco dell’attenzione, fino alla prossima mutazione genetica, è sempre uno solo.
• Le regole di organizzazione percettiva sono simili.
• E molto altro…

Certo, poi ci sono le differenze. Di conoscenze, di ragionamento, di attenzione. A volte queste differenze generano problemi, altre solo diversi modi di usare l’interfaccia, perfettamente accettabili. Alcuni “heavy users” di Gmail non si rendono ad esempio conto che esistono le label e che è possibile filtrare le mail, mentre altri utenti che a rigor di classificazione dovremmo chiamare “inesperti” le usano quotidianamente con gran successo e senza difficoltà di comprensione. Questo non impedisce però a Gmail di essere usata proficuamente da entrambi i gruppi di utenti.

Per queste ragioni le modifiche delle interfacce sulla base degli errori devono essere del tipo “win-win”, come si dice in epoca di globalizzazione… Fare il bene di alcuni utilizzatori senza penalizzarne degli altri, o almeno fare in modo che il saldo finale fra facilitati e penalizzati sia positivo. E per far questo bisogna discriminare, analizzare, verificare.

Come valutare gli errori dell’utente

Se proviamo a stilare alcune linee guida o, meglio, dei criteri euristici su come valutare quando gli errori dell’utente debbano portare veramente a modifiche dell’interfaccia, otteniamo un elenco del genere:

1. Quando l’errore, qualunque esso sia, è compiuto da più di un utente. Se più di un utente in un test commette l’errore, è assai probabile che molti altri lo faranno nella realtà.
2. Quando l’analisi dell’errore evidenzia una scarsa chiarezza delle label verbali, siano esse testi, titoli, etichette di bottoni, testi interni ad elementi dei form, link. Una label verbale ambigua genera nel migliore dei casi dei rallentamenti dovuti a dubbi, nel peggiore dei casi errori.
3. Quando l’analisi mette in evidenza che vi sono segnali non verbali, ma dotati di valore semantico (icone, colori, posizioni) poco chiari. Si fa presto a fare un test di comprensibilità delle icone. Mettetele fuori contesto e chiedete a una decina di persone di scrivere sotto a ciascuna di esse cosa significhino secondo loro, senza dire altro. I risultati parleranno da soli.
4. Quando l’analisi dell’errore mette in evidenza che la causa potrebbe essere una mancata coerenza dell’interfaccia. Ad esempio, un elemento che assomiglia ad un altro, presente altrove, che si comporta in un modo diverso, e che dà vita a conseguenze diverse. Bottoni che cambiano colore, labeling o posizione, menu che cambiano ordine delle voci o fanno sparire voci, sono esempi di incoerenze che possono creare errori.
5. Quando l’errore si può eliminare con una modifica ovvia e poco costosa dell’interfaccia.
6. Tutto questo a patto che la modifica, rianalizzata, non introduca uno dei casi precedenti.

Più difficile è stabilire quando non cambiare l’interfaccia. Ecco alcuni casi tipici:

1. Quando non si è capito perché avviene l’errore; in tal caso è necessario approfondire le ragioni prima di ipotizzare la soluzione.
2. Quando la soluzione non rende l’interfaccia più chiara.
3. Quando la modifica interferisce con altre convenzioni diffuse o introduce ambiguità semantiche.
4. Quando la modifica penalizza qualche altro gruppo di utenti (elimina o modifica funzionalità gradite o usate dagli altri) che noi non vogliamo penalizzare.

I limiti dell’osservazione degli errori dell’utente

Queste “linee di condotta” si applicano a modifiche puntuali, focalizzate, dell’interfaccia. Non riguardano i cambi completi di modello concettuale, ovvero del funzionamento complessivo del sistema. Le “rivoluzioni”, quelle che modificano il nostro modo di lavorare con un software.

Un software consolidato difficilmente può permettersi modifiche di tali portate, perché deve tener conto degli utilizzatori già acquisiti, che hanno dunque imparato alcuni automatismi che la “rivoluzione” renderebbe inefficaci, innalzando, almeno inizialmente, il tasso di errore e di insoddisfazione. E’ accaduto anche per una delle recenti versioni di Microsoft Office, per esempio, con l’introduzione del ribbon, che all’inizio pare abbia disorientato qualche utente, anche se si tratta sicuramente di una modifica utile dell’interfaccia, una volta appresa.

Per quanto riguarda i siti di contenuti, un redesign solo estetico o piccole modifiche architetturali dovrebbero portare a problemi contenuti, perché tali siti sono meno orientati ai task e i cambiamenti interferiscono meno con la memoria procedurale.

Tra le applicazioni (desktop o web), quelle nuove hanno la possibilità, esordendo sul mercato senza la preoccupazione di perdere vecchi utenti, di proporre nuovi modi per svolgere attività vecchie. In quel caso, la rivoluzione riguarda l’intera interfaccia e non va applicato un modello “incrementale” di modifica come quello qui sottinteso. Questo modello va però applicato anche in queste nuove applicazioni a partire dalle successive iterazioni del progetto, per migliorarlo e raffinarlo.

Gli errori degli utenti sono in definitiva importanti strumenti di “consulenza gratuita” a patto che siano elaborati correttamente e non presi – ma nessuno lo pretende – come unica risorsa progettuale. A rendere più morale la (quasi) gratuità della consulenza – non dimentichiamo infatti che ai test gli utenti vanno in qualche modo compensati – c‘è il fatto che i maggiori beneficiari di questa consulenza dovrebbero essere, alla fine, proprio gli utenti stessi.