Nel campo dell’usabilità ci sono alcuni eventi emblematici che attirano l’attenzione sulla nostra disciplina e travalicano la cerchia degli specialisti.
Uno degli esempi più citati è quello della scheda delle elezioni USA 2000, che costarono il posto ad Al Gore e diedero un decisivo impulso al doppio mandato di George Bush. Il disastro viene ben raccontato da Bruce Tognazzini, e viene spesso citato a esempio di cattiva progettazione, finendo nei commenti di molti giornali e siti generalisti.
La posizione dei fori di punzonatura è ambigua e non corrisponde all’ordine di comparsa nell’elenco dei candidati.
A margine, è bene notare come il design della punzonatrice ne ricordi altri. Ad esempio, quello di alcune emettitrici di biglietti per trasporti pubblici, dove tuttavia non risulta ambiguo (il che ci dice anche come avrebbe potuto essere corretto quello della scheda elettorale).
In questa emettitrice l’ambiguità viene risolta, oltre che con un allineamento preciso fra righe e pulsanti,
anche con la corrispondenza diretta di frecce che collegano righe e pulsante. Si potrebbe dire molto altro sulla comprensibilità delle molte opzioni disponibili, ma questo è un altro discorso.
HealtCare.gov: quando il fiasco minaccia un’azione politica
Più sorprendente quello che è successo nel 2013 sempre negli USA, con il lancio del sito Healthcare.gov, che doveva concretizzare finalmente l’agognata riforma del sistema sanitario statunitense nota anche come “Obamacare”.
Molti ricorderanno che l’esordio del sito Healtcare.gov fu un fiasco tale da rischiare di affossare l’intera riforma di Obama. Ne parlarono a lungo i giornali generalisti, e la cosa sorprese anche perché in precedenza lo staff di Obama aveva dimostrato grande capacità nell’uso delle nuove tecnologie e in particolare dei social media1.
Se la scheda elettorale del 2000 mostrava errori di progettazione e di stampa del materiale cartaceo in relazione alla modalità di votazione con punzonatura – quindi non atteneva strettamente al solo mondo digitale – il problema del 2013 è perfettamente esemplificativo delle difficoltà di progettazione e di gestione che affliggono molti progetti online pubblici.
L’aspetto che finì all’epoca sui giornali riguardava principalmente l’errato dimensionamento dei carichi di accesso al sito nel momento in cui, il primo ottobre 2013, questo andò online. L’accesso degli utenti fu talmente massiccio – con picchi di 250.000 accessi simultanei quando ne erano stati previsti al massimo 60.000 – che portò all’impossibilità per molti utenti di completare le procedure, con attese ingiustificatamente lunghe, le quali davano vita a nuovi tentativi da frustrazione che sovraccaricavano ulteriormente il server, in una spirale che si autoalimentava.
Dai problemi tecnici a quelli di usabilità
Strettamente parlando, si potrebbe derubricare l’episodio a problema gestionale e funzionale, e non legato all’usabilità. In fondo, il corretto dimensionamento dei carichi di un server non è – di solito – compito di coloro che si occupano dell’usabilità. Ed è vero.
Tuttavia i problemi non si fermavano lì. Come un dettagliato resoconto di Craig Tomlin, che condusse dei test di usabilità, ci ricorda, alcuni aspetti concomitanti alle difficoltà di accesso erano mal gestiti anche dal punto di vista dell’usabilità. E potrebbero tutt’ora interessare i progettisti di tutti i siti, pubblici e privati.
1. Le schermate d’attesa devono fornire informazioni appropriate, rassicuranti e utili
Mentre gli utenti avevano difficoltà ad accedere al sito per i già menzionati problemi di dimensionamento, la schermata su cui rimanevano bloccati in attesa offriva un messaggio generico, senza indicazioni di quanto tempo ci sarebbe voluto per procedere.
“Abbiamo un sacco di visitatori in questo momento, per favore rimanete su questa pagina” – su un sito così lungamente atteso-
non offre una grande impressione di affidabilità. No, purtroppo le simpatiche icone non sono sufficienti…
In molti siti la messaggistica non è curata, non si ragiona per scenari d’errore ma solo per scenari di successo, cosicché inevitabilmente, quando l’errore capita, non se ne ha una gestione che aiuti a minimizzare il danno, pratico e di immagine. I messaggi d’errore devono spiegare con un linguaggio chiaro all’utente cosa è successo (o, in questo caso, cosa sta succedendo) e cosa può fare lui per risolvere, offrendo indicazioni pratiche (se possibile, idealmente dei link attivi verso pagine di soluzione).
La cosa più notevole però è che in questo caso il messaggio c’è e la pagina è curata: semplicemente è un messaggio troppo generico e deresponsabilizzante: il sito era molto atteso, come mai ora mi dicono solo che ci sono tanti visitatori? Non lo immaginavano? E non devo far altro che rimanere qui per “non perdere la priorità acquisita”, come in una qualsiasi telefonata di assistenza? Lo stesso richiamo a quell’espressione contribuisce probabilmente a evocare un senso di fastidio e di scarso rispetto per il cittadino.
2. La chat: uno strumento potenzialmente utile, ma gestito malissimo
A peggiorare l’impressione che il sito fece ai cittadini c’è la cattiva gestione di uno strumento che era stato preparato e pensato proprio con l’obiettivo opposto: quello di dare l’idea di un sito vivo, dove l’utente è accudito, grazie a una live-chat disponibile sul sito.
Peccato che anche questa soffrisse, inevitabilmente, dello stesso difetto di dimensionamento. Così quella che, in condizioni normali, diventa un’occasione per intervenire e aiutare direttamente l’utente, divenne in quell’occasione l’ennesimo strumento che non offriva risposte, né indicazioni sui tempi per ottenere risposte.
L’errore qui non è solo di dimensionamento, ma di strategia. Ci si è trovati ad avere ben due funzionalità che funzionavano sulla base delle stesse dinamiche: bene se i carichi fossero stati corretti, male – entrambe – qualora il servizio si fosse trovato in sovraccarico. In altre parole i due sistemi erano in fase. Entrambi dipendevano da risposte sincrone.
Quando si vuol aumentare la resilienza di un sistema a eventi traumatici (come l’eccesso di carico fu per HealtCare.gov) è buona norma predisporre sistemi di sicurezza o di ausilio che funzionino in controfase: in modo che entri in gioco uno proprio quando l’altro è in difficoltà.
Così se, per esempio, il sistema è bloccato per il carico, un help in pagina, già caricato, asincrono, magari con casistiche già spiegate, è un ausilio migliore rispetto alla chat – che funziona meglio a carichi bassi, visto che affronta gli utenti uno per uno.
La conseguenza di questo doppio malfunzionamento (causato in realtà dallo stesso problema, e da una cattiva progettazione delle alternative) fu che gli utilizzatori si fecero non solo un’idea negativa del servizio, ma anche di possibili altre strade di supporto. Ad esempio, si convinsero che non valesse la pena telefonare al numero verde perché, se due strade percepite come “automatiche” e tecnologiche si erano rivelate così scadenti, come avrebbe potuto una semplice assistenza telefonica essere di maggior aiuto?
3. Errori di comunicazione dei formati già nella fase di login
Nel momento del login, il messaggio di errore che invitava a comporre uno username e una password sicuri appariva ambiguo, con delle congiunzioni oppositive (“o” invece che “e”), posizionate nella frase in modo da far credere che bastasse scegliere o caratteri minuscoli o maiuscoli (e non entrambi), o numeri o simboli (e non entrambi). La conseguenza è che molti sbagliarono già nella fase di creazione del login.
CHARACTERS LONG AND MUST CONTAIN A LOWERCASE OR CAPITAL LETTER, A
NUMBER, OR ONE OF THESE SYMBOLS _.@/-“
Non basta, però. Quello che segue è un errore che, rivisto oggi, appare incredibile. Benché venisse alla fine richiesto di creare uno username case-sensitive, sia con lettere maiuscole che minuscole, l’email di reminder che veniva inviata presentava il login in maiuscolo, qualunque cosa l’utente avesse scritto!
Così anche chi copiò i dati dalla mail di appoggio sbagliò, e lo fece a causa del sistema stesso!
Figli minori di un progetto
Questo insieme di errori, soprattutto se elencati tutti assieme, sembrano dimostrare una grande sciatteria nella progettazione. Invece sono tipologie di errori molto comuni, perché riguardano tutto ciò su cui di solito non si riflette in un tradizionale processo di progettazione. In esso ci si concentra molto, per esempio:
- sulla scelta delle immagini,
- sul layout,
- sul tono della comunicazione,
- sui wireframe
- sulle schermate, in particolare delle pagine principali e dei primi step del processo,
- sull’architettura informativa…
Quelli accaduti sono invece errori che non riguardano affatto questi “oggetti progettuali”. Dipendono dall’esecuzione vera e propria di procedure, che durante il processo di progettazione vengono eseguite di solito da esperti – a volte solo dai programmatori – che ne testano soprattutto l’esecuzione corretta.
Riguardano inoltre la progettazione di schermate e di materiali cui si dedica tradizionalmente un’attenzione limitata. Schermate di attesa, messaggi su come creare password o sugli step di una procedura… e a chi mai viene in mente di pensare al modo in cui è formattata una semplice mail automatica di sistema?
Sono oggetti “minori”, quasi invisibili, e che calamitano molte meno attenzioni in fase progettuale di quanto sarebbe invece necessario. Perché richiedono una mentalità anti-confirmativa: ovvero ci vuole che qualcuno pensi agli scenari peggiori, non alle cose che funzionano.
E’ chiaro che il riferimento ai diversi “touchpoint” di un progetto, terminologia legata al settore del cosiddetto “service design”, design dei servizi, serve proprio a focalizzarsi su tutti i punti di contatto fra utente e sistema, non solo su quelli più vistosi. E dunque gli approcci più recenti facilitano la soluzione di questi problemi. Stupisce a maggior ragione che un sito facente parte di un ecosistema complesso di “service design” come quello dell’Obamacare non ne tenesse conto.
Il test di usabilità: la miglior assicurazione per un progetto
C’è un modo “sicuro”, al di là della metodologia che adottate, per identificare precocemente questi problemi?
La risposta più ovvia è che – oltre a una buona direzione di progetto, che abbracci una mentalità critica senza stroncare la creatività – solo i test di usabilità consentono di osservare scenari che noi, progettisti, non immagineremmo nemmeno accadessero. I test di usabilità, in questo caso, si sarebbero dovuti fare ben prima della pubblicazione del sito, ma con il sito già funzionante (almeno nelle funzionalità essenziali). Per consentire il tempo necessario a porre rimedio a quanto si sarebbe evidenziato.
Ma uno dei problemi che soprattutto siti di questo tipo hanno – e lo abbiamo visto anche con la frettolosa pubblicazione di Verybello qualche anno fa e con le difficoltà che ha avuto finora l’attivazione di Spid in Italia – è che spesso la politica non sa gestire correttamente i tempi di un progetto basato su tecnologie internet. Forse perché lo confonde con un tradizionale progetto di comunicazione non interattiva.
Dopo una presentazione frettolosa e affrettata solo per rispettare alcune scadenze, il progetto di Verybello.it, che tante polemiche generò all’epoca, risulta oggi abbandonato, o in un generico stato di “redesign”.
O, detto in un altro modo, i tempi della politica – legati a consenso e annunci – non sempre si attagliano a quelli ideali di un progetto complesso. Quindi si arriva spesso a ridosso della pubblicazione senza esser riusciti a svolgere i test di usabilità pre-rilascio, perché concentrati sul lavoro necessario a garantire la messa online del sistema.
Cosa ci insegna questo episodio sui rapporti fra politica e tecnologia
Dal punto di vista della reputazione, non solo i progettisti ma anche i politici dovrebbero aver ormai capito che fare annunci roboanti su servizi tecnologici è un rischio che forse non vale la pena di correre, perché nessun servizio può essere, per definizione, maturo al momento del lancio.
Mentre, specialmente in tempi di antipolitica, le aspettative dei cittadini sono elevate quasi quanto il grado di sfiducia preventivo. E invece solo la presenza di una grande fiducia nell’emittente può salvare dalle figuracce informatiche.
Solo la fiducia preventiva genera tolleranza ai difetti
Si cita molto spesso, non a caso, il fatto che per anni la Apple abbia goduto della fiducia degli appassionati anche negli anni in cui i prodotti non erano a livelli ottimi.
Con le dovute differenze, lo stesso si potrebbe dire, ad esempio, per l’estrema tolleranza, o comunque le scarse critiche che la lunga gestazione della piattaforma di democrazia diretta annunciata ad horam dal M5S subito dopo le elezioni del 2013 ha invece richiesto, non venendo alla fine nemmeno poi pubblicata con le caratteristiche attese. Questo per dire che il problema, con questo genere di progetti, non è legato a un colore politico: la tecnologia è complessa e la politica ha esigenze di immediatezza spesso incompatibili con una buona progettazione.
Il rischio di una partita loose-loose è sempre molto alto. Il “caso Obamacare” ce lo ricorda. E, nel farlo, ci offre qualche ammonimento e una manciata di consigli:
- Pianificate in anticipo il tempo necessario per fare i test di usabilità sia durante le varie fasi di progetto (dove si spera vengano fatti), sia in fase di pre-lancio (e poi fateli davvero!)
- Pensate agli scenari peggiori già durante il progetto
- Curate anche i materiali apparentemente minori, comunque tutti quelli con i quali gli utenti potrebbero venire a contatto.
- Non create aspettative eccessive se non avete una base molto fidelizzata.
1 L’uso di un ambiente social online per la gestione e la mobilitazione degli attivisti durante le campagne elettorali, in particolare quella del 2008, fu talmente efficace e innovativo che viene spesso indicato come caso di studio.