L’usabilità o la facilità d’uso viene citata sempre più spesso nelle riunioni o nei requisiti di progetto come un fattore importante. Più sorprendente è che questi concetti vengono a volte associati a pratiche progettuali che non hanno quasi nulla a che vedere davvero con l’usabilità.

Si invoca spesso la facilità d’uso per cassare una certa proposta o per sostenerne un’altra, ma senza alcuna reale connessione con l’usabilità. La connessione è presunta, supposta, evocata, ma non osservata. Un’idea “ingenua” di usabilità, apparente, diversa da quella reale e misurabile, un po’ come sono “ingenue”, percepite ma non reali, alcune concezioni di fenomeni fisici, egregiamente illustrate in un classico di Paolo Bozzi¹.

Ecco dunque alcuni esempi di “usabilità ingenua”, in modo da aiutarvi a riconoscerli durante le vostre prossime riunioni, assieme ad alcuni argomenti per smascherare il dissimulatore. Se volete segnalarne altre, usate pure il modulo di contatti.

Questione di sfumature

“Non si potrebbero togliere le sfumature/le ombre/i riflessi? Appesantiscono la grafica e la rendono meno facile da usare. Gmail ha una grafica spartana, ed è il programma più usabile in assoluto”

Questa l’ho sentita di recente. Ebbene, Gmail, nonostante sia una buona applicazione, non è il programma più usabile in assoluto, perché una classifica del genere non è mai stata fatta e non ha più senso della vecchia, popolare gara di un tempo fra i giovani maschietti con incertezze ormonali, ovvero:“chi vincerebbe in un duello tra Hulk e La Cosa?”. L’usabilità si misura o valuta in molti modi, è un concetto multidimensionale (anche se recentemente Jeff Sauro ha proposto un numero unico per riassumerla, il SUM), e certamente bisognerebbe specificare meglio di cosa si parla. Gmail è il programma più gradito fra i programmi di mail? E’ quello più efficiente? E’ meglio di Excel (ma da che punto di vista, di grazia), ma peggio di Word?
Anche chiarito questo, non è certo la grafica la ragione del suo successo (anche se la grafica spartana ha un preciso valore di comunicazione² nel progetto delle applicazioni di Google), né un valido argomento per cassare altri stili grafici.

Gli argomenti per valutare la grafica sono diversi:

1. Il peso in relazione al contesto d’uso. Che sia rapida da scaricare è un fattore importante, ma non sempre: in una intranet lo è molto meno. Per la Nike, anche online, dati gli obiettivi che si pone, non lo è proprio.
2. Il rumore visivo: è una grafica visivamente affollata, pesante da decodificare, o non lo è?
3. La semantica: ostacola il riconoscimento dei widget di interfaccia per l’utente che la userà o no? Se ridisegna barre di scorrimento, bottoni, se maschera i link al punto che gli utenti meno evoluti che useranno il prodotto non saranno in grado di identificarli, allora vi sono problemi di usabilità
4. L’adeguatezza al messaggio, al tono comunicativo.

In sintesi, le sfumature, le ombreggiature, i riflessi, se appropriati ad obiettivi e contesto, non sono un problema di usabilità, ma possono diventarlo se e quando ostacolano tali obiettivi.

L’usabilità va rapportata a obiettivi e criteri di valutazione specifici del progetto. Ma le riunioni spesso si tengono senza condividere preventivamente gli obiettivi. Questo è il problema, non le sfumature.

Lo schierato

“Il menu a destra non va bene, secondo le ricerche sull’eye-tracking è dimostrato che l’utente vuole il menu a sinistra” (O: le convenzioni d’uso, o l’usabilità, lo vogliono… ndr.).

Ogni tanto qualcuno scrive anche a questo sito, per prenderci in castagna perché abbiamo fatto l’obbrobrio di mettere il menu (o qualcosa che gli assomiglia) a destra.
L’eye-tracking ha rivitalizzato questo mito, specie nei lettori meno attenti di quelle ricerche, perché dimostra che gli utenti leggerebbero le pagine secondo un pattern da sinistra a destra e dall’alto al basso a forma di F. Curiosamente, però se si guardano attentamente queste heat-map dei movimenti oculari, si vedrà che il menu a sinistra viene escluso dalla “F”: questi movimenti riguardano l’area di contenuto. Dunque queste ricerche sono ininfluenti rispetto alla posizione del menu.

Ma in generale, perché mai un menu dovrebbe essere la prima cosa che uno legge, e dunque stare a sinistra per forza? Magari uno vuole che si legga per primo il contenuto. Non sarebbe un’idea tanto balzana.
Secondo, l’ordine di lettura corrisponde a obiettivi e compiti che l’utente sta svolgendo. Il punto è vedere se quando gli serve il menu riesce a identificarlo e a raggiungerlo senza difficoltà. Ancora più importante è che le voci del menu siano per lui significative, tali da farli scegliere l’alternativa migliore, la voce che porti proprio dove deve portare.

Inoltre una vecchia ricerca Audi (ora non linkabile) ha dimostrato che fra destra e sinistra, almeno per i menu, non fa differenza.

Appena si citano ricerche di questo tipo, le obiezioni (o gli obiettori) spariscono.

Ma la cosa che mi diverto a dire il più delle volte è che a destra è addirittura meglio che a sinistra (ma di poco, concedo) per via della legge di Fitts. Non vi rovino l’esercizio completando la spiegazione: provate a ragionare sul perché.
Solitamente l’interlocutore di turno non ha idea di chi sia Paul Fitts e scompare nella nebbia.

Il succo però è che non basta una scelta di così basso livello a poter modificare sensibilmente l’usabilità del vostro sito. Sarebbe bello se bastasse questo, ma purtroppo le cose sono un tantino più complesse.

Dammi spazio!

“Come mai c’è tutto quello spazio ai margini dell’impaginazione? Ad alte risoluzioni si perde spazio utile nella pagina”

Questo capita quando il grafico ha pensato di adottare un layout che prevede margini importanti, magari un layout centrato con i margini a lato della colonna. Ora, bisogna vedere se i margini sono vuoti, se contengono elementi decorativi, o hanno ruolo funzionale. Ma giova ricordare, a seconda dei casi, che lo spazio negativo ha un ruolo importante nel design (anche se non sempre ugualmente dimostrato nell’usabilità). E soprattutto che i margini ai lati di una colonna di testo sono positivamente correlati con un aumento della comprensione e della soddisfazione nei compiti di lettura, ma negativamente riguardo la velocità (come risulta da questa ricerca)

Anche qui si scambia un problema complesso come l’usabilità per un problema di grafica. L’impatto dello spazio bianco dipende da obiettivi e tipologia di sito e utente. Non necessariamente pagine zeppe di testo sono più usabili di pagine con zone vuote

Nel blu dipinto di blu

“I link devono essere assolutamente blu, per ragioni di usabilità”

Portatemi l’utente (un minimo aduso al web) che non capisce i link di un altro colore, posto che siano di un colore diverso dal testo e adeguatamente sottolineati, e vi pagherò la cena.
La credenza deriva da due fonti principali. La prima è il solito Nielsen. Che però nel parlava molti anni fa, con utenti molto disorientati dalla rete e siti francamente inguardabili. La seconda è Jared Spool (nel suo libro Web Site Usability: A Designer’s Guide ). Sua è l’unica ricerca che mi risulti che trova una correlazione fra il colore blu dei link e l’usabilità in un campione di siti. Si trattava di anni precedenti al ’99, con siti che francamente avevano tali e tanti problemi, da poter spiegare questa correlazione anche in modi alternativi. La spiegazione proposta da Spool (che peraltro fu il primo a stupirsi del risultato) aveva più a che fare con il fatto che i link visitati fossero distinguibili da quelli non visitati, che con il colore blu.

La prova che questa linea guida così rigida non vale più ce la fornisce lo stesso Nielsen, che nell’aggiornare le proprie prescrizioni, dice che i colori per i link e i link visitati devono essere chiaramente distinguibili, non necessariamente blu.

E se lo dice lui, voi volete proprio restare indietro?…

Morale della storia

Il vero succo della faccenda è molto meno allegro del tono di questo articolo. Il punto è che l’usabilità è entrata nel gergo comune di chi fa progettazione web, ma non è capita né praticata. Nessuno di questi interlocutori ha partecipato ad un test di usabilità, né l’ha messo in calendario nel progetto, né ne ha capito i risvolti. Nessuno di questi interlocutori sa cos’è la progettazione iterativa (anche se diranno di sì, “è quella cosa dove si fanno riunioni periodiche per discutere del progetto…”) e centrata sull’utente.

Il problema è che l’usabilità oggi in Italia è associata semplicemente all’uso di alcune pratiche (o prescrizioni) di design, non alla loro verifica.

Sì, è vero che esistono alcune pratiche migliori di altre (ad esempio un testo con dimensione e contrasto più alti, entro un certo limite, è preferibile ad un testo con contrasto basso e di piccola dimensione: ma non significa che non vi siano opportune eccezioni e limiti alla regola).

Ma non esistono soluzioni standard per tutti i problemi, soprattutto se consideriamo variabili confuse come la tipologia del sito, il tipo di compito (mai uguale da sito a sito, e particolarmente complesso e variabile nelle applicazioni web) e le caratteristiche degli utenti cui ci si rivolge.
Adottare soluzioni pronte all’uso (laddove si può dimostrare che esistano) significa sostanzialmente fidarsi dell’abitudine, di qualcosa che è andato bene in circostanze spesso solo vagamente simili, senza fare alcuna verifica empirica dell’effetto di queste pratiche sul target di utenti, nel nostro contesto, dal punto di visto di una delle metriche rilevanti per l’usabilità: tempi, tassi di errore, completamento dei compiti, soddisfazione, rapidità di apprendimento, facilità di lettura, di memorizzazione, eccetera.

Insomma, in Italia non si fa verifica empirica del progetto. E l’usabilità è vista soprattutto come l’applicazione di pattern o prescrizioni pronti all’uso. E’ quello che tutti si aspettano dall’esperto di usabilità: che dica la parola che “squadri da ogni lato” il progetto nostro informe, consentendo, in virtù di un’expertise presunta, di scegliere semplicemente la soluzione migliore al problema proposto, senza verifiche.

Questa non è usabilità, questo è “genius design³”. Un designer “geniale”, se va bene informato (o, come si ama dire nelle riunioni, “skillato”…) decide. Se ha fortuna o intuito il prodotto avrà successo. Più spesso fallirà. Ma non c’entra niente con una procedura iterativa, empirica, valutativa, centrata sull’utente.

Poi non dite che non ve l’ho detto.