Talvolta è opportuno, per chi si occupa di usabilità, osservare da vicino il comportamento degli utenti in situazioni reali, cioè non sottoposti a test. Tali osservazioni vanno fatte in maniera non intrusiva. Non sono indicative del comportamento di tutti gli utenti, ma riescono a compensare un problema tipico dei test di usabilità: la mancanza di motivazione reale.

Recentemente ho avuto modo di seguire il tentativo di iscrizione online ad un corso universitario da parte di uno studente. E’ uno di quei casi che si testano sempre con difficoltà in laboratorio, dato che bisogna informare i sistemi informativi dell’università del test per utilizzare un’identità fittizia ed evitare che dati di test vengano inseriti davvero nel sistema.

L’iscrizione in questo caso avveniva online. Lo studente, il 29 settembre, dopo aver trovato la pagina sulla quale iscriversi al corso di “servizi sociali”, si è trovato di fronte alla seguente tabella (freccia rossa aggiunta per chiarezza):

In questa tabella l’utente non capiva perché la voce “Immatricolazione” indicata dalla freccia non risultasse cliccabile.

Molti link “immatricolazione” erano attivi, mentre il testo “immatricolazione” per alcune facoltà non era cliccabile. In una situazione ideale, l’utente legge il testo sulla riga sottostante e capisce che l’iscrizione sarà disponibile solo dal 30 settembre. Si rende conto di essere il 29 settembre, e decide di riprovare il giorno successivo. Nella realtà, tutto questo non è avvenuto, e l’utente si è trovato a telefonare in segreteria lamentando che l’iscrizione “non funziona”.

Solo in seguito ad una segnalazione esterna (non della segreteria!), si è reso conto che la scritta indicava che l’iscrizione sarebbe stata disponibile dal giorno successivo.

Cos’è andato storto? E’ esclusivamente colpa della distrazione dell’utente?

Anche, ma non solo. Le questioni qui sono molte, e riguardano un tipico intreccio di motivazioni reali, conoscenze, credenze precedenti e disservizi. E’ stato possibile ricostruirle a posteriori con il contributo dello studente stesso.

1. Conoscenze precedenti e cattive informazioni da parte della segreteria hanno contribuito a creare una precisa aspettativa, grazie all’autorevolezza della fonte. Una modalità di iscrizione scadeva infatti il 26 settembre, e vi era l’aspettativa da parte dello studente di potersi iscrivere secondo un’altra modalità, dal giorno successivo. Nessuno aveva segnalato in precedenza che invece la nuova modalità di iscrizione sarebbe stata attiva solo a partire dal 30. Tanto che persino durante la successiva telefonata informativa l’impiegato ha segnalato di “non sapere”, senza spiegare dunque che il meccanismo avrebbe funzionato di lì a qualche giorno.
2. La scarsa rilevanza percettiva della data (si veda il principio di percepibilità e visibilità per una discussione più generale). Perché le date attive sono scritte in verde, colore molto rilevante, e le date future in grigio pallido, rendendo disagevole la lettura a chi abbia problemi di vista?
3. La presenza della medesima parola, “immatricolazione”, in forma linkata e non linkata. Perché scrivere “immatricolazione”, se tale iscrizione non era al momento possibile? Negli altri casi quella parola rappresenta un invito all’azione, ma in questo caso sembra semplicemente non attiva.

Schemi, gabbie mentali e esperienze precedenti

All’opera ci sono due questioni: “gabbie mentali” unite a difetti progettuali che non fanno abbastanza per indicare “l’uscita dalla gabbia”. Lo studente cioè arriva sul sito con una convinzione pregressa: che ci si potesse sicuramente iscrivere. Lo sa da fonti esterne, glielo hanno confermato, non c’è alcuna ragione per lui immaginabile affinché ad alcune facoltà ci si possa iscrivere in certe date e ad altre facoltà in altre. Questo lo porta ad avere un “modello mentale” della situazione. L’utente è convinto che il sistema funzioni in un modo, si aspetta che funzioni in quel modo. Le caratteristiche dell’interfaccia sono ambigue: in alcune parti (alcune facoltà) il sistema sembra confermare il suo modello mentale, mentre in altre no. Qui si innesta l’esperienza precedente dell’utente. “In passato già il sito non funzionava a dovere, ho pensato ad un errore”, ha riferito in seguito.

Di fronte ad una difficoltà, è inevitabile formarsi un’idea della possibile soluzione. L’esperienza pregressa entra in gioco come possibile spiegazione, prendendo il sopravvento sullo stimolo (il testo che spiegava la data di apertura dell’immatricolazione).

Questo avviene più spesso di quanto non si creda, soprattutto in siti procedurali (dove si devono seguire procedure per portare a termine un’attività). A me è capitato di vedere ai test di usabilità utenti saltare completamente righe di testo dove si trovavano le informazioni o le funzioni da essi cercate. I problemi possono essere percettivi (testi troppo piccoli o con colori poco evidenti) o di modello mentale: l’utente non si aspetta che l’informazione sia lì; o, infine di conoscenza lessicale: non conosce l’esatto wording, i termini con i quali l’informazione si presenta. Più spesso dipendono dall’interazione di diversi livelli di problema.

Casi del genere capitano a tutti, in situazioni particolari. Forse il miglior equivalente è l’esperienza, che tutti abbiamo probabilmente provato, di controllare e ricontrollare delle equazioni algebriche precedentemente svolte a scuola senza successo, senza riuscire a trovare l’errore (che magari ci salta all’occhio mezz’ora dopo). Assai simile anche all’esperienza di non riuscire a vedere errori di ortografia su un testo appena scritto nonostante lo si fosse letto e riletto più volte. Si crea una situazione di framing, nella quale non riusciamo più a vedere la possibile soluzione che sta davanti ai nostri occhi. Siamo incapaci di cogliere lo stimolo esterno, e diamo retta alle nostre rappresentazioni mentali più di quanto dobbiamo.

Avviene una sorta di “prevalenza dello schema sullo stimolo”. Un errore cognitivo molto frequente, ma difficile da osservare nei laboratori di usabilità per una ragione molto precisa: mancano le motivazioni reali e le situazioni contestuali che portino alla formazione di uno schema pregresso.

Possibili soluzioni

Cosa può fare un progettista in questi casi? Se l’utente non riesce a notare o a prendere in considerazione lo stimolo (gli elementi corretti dell’interfaccia) nonostante sia presente, che speranze abbiamo di modificare la nostra interfaccia per evitare che questi errori si presentino?

Non possiamo eliminare del tutto la probabilità di errori, ma possiamo ridurla, operando in modo che il minor numero di elementi dell’interfaccia possa contribuire a formare o a confermare schemi errati.

Nel nostro caso, potremmo intervenire su tre elementi:

1. Il colore del testo con la data – l’uso di un grigio, formalmente corretto perché indica “disattivazione” in molte interfacce, non è corretto perché ostacola la lettura; perché non si tratta solo di una funzione disattivata, ma di un’informazione da fornire; e anche perché le date “attive” non sono nere, ma verdi. Per veicolare il significato opposto, allora, in questo caso è opportuno usare il colore rosso, che è molto evidente e che simbolicamene richiama l’opposizione al verde
2. La presenza inutile e fuorviante della scritta “immatricolazione”, senza il link – la scritta ha senso se attiva un comando, ma altrimenti perché inserirla? Dà davvero l’idea di un errore: la scritta in altre righe indica un comando, ma qui no. Inoltre, se proprio vogliamo seguire coerentemente la convenzione usata per la data, resa grigia, perché non rendere almeno grigia anche la parola “immatricolazione”, per dare l’idea che l’intera casella della tabella sia disattivata? Meglio ancora, però, togliere del tutto la scritta, lasciando solo la data.
3. Esplicitare – Infine, per quale ragione non spiegare meglio, con parole esplicite, che l’iscrizione sarà semplicemente disponibile domani, o dopodomani… 30 settembre? In questo modo è decisamente più improbabile che lo studente non si accorga del problema di data. Ma soprattutto non deve essere consapevole di quale giorno è quello nel quale sta operando e non deve confrontarlo con quello presentato.

La prevalenza dello schema, del proprio modello mentale di come l’azione dovrebbe essere, è talmente forte che l’errore potrebbe anche capitare lo stesso. Ma almeno l’interfaccia (o meglio, il suo progettista) non avrebbe nulla da rimproverarsi.

Una possibile soluzione migliorativa sarebbe quella di eliminare il testo “Immatricolazione” e di usare il colore rosso per evidenziare la data. Già questo riduce la probabilità di non vedere o di non capire. Nel testo si suggerisce anche un’altra soluzione (punto 3). Provate come esercizio a produrla ed eventualmente a migliorarla. Il file con l’immagine a dimensione originale è disponibile qui.

Generalizzare il caso specifico

Questo è un caso specifico. È possibile stabilire linee guida generali? Be’, possiamo almeno indurre delle linee guida da questo caso per applicarle a tutta l’interfaccia:

1. Fare attenzione a non usare convenzioni differenti all’interno della stessa “unità di significato” (e possibilmente in tutta l’interfaccia). La tabella per le iscrizioni è un tutto che dovrebbe essere semanticamente coerente. Invece sono usati per oggetti simili (la casella con il link per l’immatricolazione) due convenzioni differenti:
   • L’uso del verde per gli elementi attivi (che avrebbe il suo complementare nel rosso, per gli elementi dal significato opposto)
   • L’uso del grigio per gli elementi inattivi (che ha il suo complementare nel normale colore di primo piano, qui il nero, per gli elementi attivi)
2. Non modificare il ruolo funzionale di oggetti simili. Il link “immatricolazione” è un oggetto che “chiama all’azione”. Ripeterlo, ma modificando una proprietà (il link) senza spiegare perché crea confusione.
3. Inserire le informazioni verbali nella forma più esplicita possibile. Un testo che spieghi che un servizio sarà attivo in futuro dovrebbe essere esplicito, non solo indicare una data. In caso contrario l’utente dovrà compiere un’inferenza, una comparazione, che è un’occasione di incomprensione e di errore in più.
4. In generale, la cosa forse più importante è conformare l’intera procedura al modello mentale dell’utente. Far sì che il sistema funzioni proprio come si attende l’utente. In questo caso, aver reso possibile l’iscrizione fin dal 27 settembre avrebbe reso ovviamente irrilevante tutto il resto.

Va ricordato che in situazioni di assenza di pressione psicologica (come in un’iscrizione fittizia) non si sarebbero forse verificati questi errori. Ecco perché l’osservazione in casi reali, oltre ai test di usabilità, ci offre importanti spunti di analisi e di miglioramento delle nostre interfacce.