Quando si preme un pulsante e non succede nulla, la reazione è quasi sempre la stessa: lo si preme di nuovo. Il risultato può essere un ordine duplicato, un messaggio inviato due volte, un modulo inviato a metà. Molti problemi di usabilità nascono non da ciò che l'interfaccia fa, ma dal fatto che non lo comunica.
La prima delle euristiche di usabilità più note riguarda proprio questo: il sistema deve sempre tenere informato l'utente su ciò che sta accadendo, con un riscontro appropriato e in tempi ragionevoli.
Quanto può durare un'attesa
Una regola pratica molto usata nella progettazione di interfacce distingue tre soglie, di origine ormai classica:
| Tempo di risposta | Percezione | Che cosa mostrare |
|---|---|---|
| Fino a circa 0,1 secondi | Reazione istantanea | Nulla di speciale: basta il cambiamento visibile |
| Fino a circa 1 secondo | Il flusso del pensiero non si interrompe, ma il ritardo si nota | Un segnale discreto, come il pulsante che cambia stato |
| Oltre qualche secondo | L'attenzione rischia di spostarsi altrove | Un indicatore di avanzamento e, se possibile, una stima |
Sono ordini di grandezza, non misure esatte, ma aiutano a scegliere il tipo di riscontro giusto.
I tipi di indicatore
Riscontro immediato sull'elemento
Il primo riscontro deve arrivare sul punto dove l'utente ha agito. Un pulsante premuto può cambiare aspetto, mostrare un piccolo indicatore e diventare temporaneamente non attivabile, per evitare il doppio invio. Il testo può cambiare da «Invia» a «Invio in corso…».
Spinner
L'indicatore rotante dice «sto lavorando» ma non dice quanto manca. Va bene per attese brevi e di durata imprevedibile. Per attese lunghe diventa frustrante: dopo dieci secondi di rotazione, l'utente non sa se il sistema è bloccato.
Barra di avanzamento
Quando la durata è stimabile, come in un caricamento di file o un'esportazione, una barra con la percentuale o con il numero di elementi elaborati rassicura molto di più. Anche una stima approssimativa, come «circa due minuti», è meglio di niente, purché sia onesta.
Skeleton screen
Invece di una pagina vuota con uno spinner al centro, si mostra la struttura della pagina in grigio chiaro, con i blocchi dove compariranno titoli, immagini e testo. L'utente capisce subito che cosa sta per arrivare, e il passaggio al contenuto reale è meno brusco. Lo skeleton deve corrispondere al layout finale: se il contenuto vero ha una forma diversa, la pagina «salta» quando si carica.
Interfacce ottimistiche
Per azioni che quasi sempre riescono, come mettere un «mi piace» o spuntare un'attività, si può aggiornare subito l'interfaccia come se l'operazione fosse già andata a buon fine, e sincronizzare con il server in background. L'esperienza sembra istantanea.
La condizione è gestire bene il caso di errore: se il server rifiuta l'operazione, l'interfaccia deve tornare allo stato precedente e spiegarlo chiaramente. Non è un approccio adatto ad azioni importanti o irreversibili, come un pagamento: lì l'utente deve sapere con certezza com'è andata.
Conferme e messaggi di stato
Al termine di un'azione serve una conferma proporzionata:
- per azioni frequenti e di poco conto, un breve messaggio temporaneo, come «Salvato»;
- per azioni importanti, una pagina o una sezione di conferma con i dettagli, come numero d'ordine e riepilogo;
- per azioni che si possono annullare, il messaggio può offrire «Annulla» per alcuni secondi.
I messaggi temporanei, a volte chiamati toast, hanno un difetto: spariscono. Se contengono informazioni importanti o un'azione come «Annulla», devono restare abbastanza a lungo, essere raggiungibili con la tastiera e non scomparire mentre l'utente ci sta interagendo.
Accessibilità: anche chi non vede deve saperlo
Uno spinner o un messaggio verde che appare in un angolo sono invisibili per chi usa un lettore di schermo, se non vengono annunciati. Il criterio WCAG 4.1.3 sui messaggi di stato chiede che queste informazioni siano comunicate alle tecnologie assistive senza spostare il focus.
Lo strumento principale è una regione live:
<div role="status" aria-live="polite" id="stato-salvataggio"></div>
Quando uno script inserisce del testo nell'elemento, per esempio «Modifiche salvate», il lettore di schermo lo legge non appena ha finito ciò che stava dicendo. Per gli errori urgenti si può usare role="alert", che interrompe la lettura in corso: va usato con parsimonia. La regione deve essere presente nella pagina prima che il messaggio venga inserito, altrimenti alcuni lettori di schermo non la rilevano.
Anche gli indicatori di caricamento hanno bisogno di un testo: «Caricamento dei risultati in corso» annunciato all'inizio e «20 risultati trovati» alla fine sono molto più utili di un'animazione silenziosa.
Errori frequenti
- pulsanti che restano attivi durante l'invio, causando ordini doppi;
- spinner infiniti quando la richiesta è fallita, senza messaggio di errore;
- messaggi di conferma che spariscono in due secondi;
- contenuto che si sposta quando si caricano immagini o annunci, facendo perdere il punto di lettura;
- aggiornamenti di risultati e filtri non annunciati ai lettori di schermo.
In sintesi
- Ogni azione dell'utente merita un riscontro visibile, proporzionato al tempo di attesa.
- Gli spinner vanno bene per attese brevi; per quelle lunghe servono avanzamento e stima.
- Gli skeleton screen e le interfacce ottimistiche rendono l'attesa più fluida, se usati con criterio.
- I pulsanti devono impedire il doppio invio e i fallimenti devono produrre un messaggio chiaro.
- Le regioni live con
role="status"rendono conferme e stati accessibili ai lettori di schermo.
