Home » Articoli » Usabilità, ostacoli percettivi, schemi mentali e conoscenze precedenti: un caso reale
2/03/2009
[di Maurizio Boscarol]
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):
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.
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.
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:
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.
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:
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.
Tag: principi di interazione, usabilità
Circa una mail al mese (ma spesso meno) con gli aggiornamenti più significativi.
Precedente:
« Progettare la struttura dei siti: ampiezza o profondità?
Successivo:
L’usabilità delle tag cloud »