Gestione errori

Come si gestiscono gli errori

La gestione degli errori stabilisce come il prodotto intercetta un problema, lo rende immediatamente comprensibile e offre un passo successivo concreto, senza mai colpevolizzare l’utente.

Messaggi visibili, contestuali e accessibili, dunque vicini al punto dell’errore, scritti in un linguaggio semplice e con annunci corretti, riducono gli ostacoli e aiutano a prevenire e correggere gli sbagli.

Principi di linee guida

Le linee guida di design per la gestione degli errori bilanciano prevenzione, chiarezza e recupero:

• mostra l’errore nel punto in cui si verifica, quindi inline, vicino al campo interessato;  
• usa un linguaggio semplice e orientato alla correzione;  
• riserva banner o modali ai casi globali o critici.
  
  Il timing dev’essere immediato e la persistenza proporzionata, con l’errore che resta visibile finché non viene corretto e offrendo azioni come retry o alternative, se necessario.
  
  Mantieni una gerarchia visiva coerente, con icona/colore e titolo breve, evita di colpevolizzare l’utente e rispetta i requisiti di accessibilità: identifica sempre l’errore in testo e, quando possibile, suggerisci come risolverlo.  

Tipologie di gestione errori

Errore inline

Se la validazione fallisce, ad esempio per l’inserimento dell’email in un formato non valido, evidenzia il campo e mostra immediatamente sotto un messaggio conciso che dica cosa non va e come correggerlo, per esempio “Inserisci l’indirizzo nel formato nome@dominio.it”.

Per rafforzare la percezione e agevolare la scansione visiva, affianca al testo un’icona di errore (come un punto esclamativo) e non basarti solo sul colore.

Banner top page

Si tratta di un messaggio di sistema che segnala un errore globale, ossia un problema che impatta l’intera pagina o servizio, come per una connessione persa, per esempio.

È posizionato in alto, a larghezza del contenuto, ben contrastato e persistente finché letto o risolto e può includere azioni come “Riprova” o “Chiudi”.

Page error

L’errore di pagina è una schermata a tutta pagina mostrata quando il contenuto non è raggiungibile o il servizio è temporaneamente non disponibile (errore 404/403/500/503).

Deve spiegare cosa è successo e come proseguire, offrendo percorsi chiari (come “Riprova”, “Torna alla home”, “Contatti”) e, se possibile, chiarire i tempi o le alternative possibili. Evita tecnicismi e offri messaggi sempre orientati al recupero.

Error modal dialog

L’errore modale (dialog bloccante) è una finestra che interrompe il flusso per gestire problemi critici o azioni potenzialmente distruttive.

Usala con parsimonia e mantieni l’essenziale: uno stato/icona, testo chiaro e 1–2 azioni (come “Conferma” e “Annulla”). In caso di errori non critici, preferisci le notifiche inline o toast.

Buone pratiche di UX writing

Principi di base

• Spiega cosa è successo e come rimediare nello stesso messaggio. Evita tecnicismi e vai subito al punto.
• Individua chiaramente l’errore tramite spiegazione testuale, non solo con il colore, e suggerisci la correzione quando possibile.
• Rendi il messaggio percepibile anche dalle tecnologie assistive (annuncio come “status/alert” senza spostare il focus).

Voce e tono

• Neutro, chiaro, rispettoso: non dare mai la colpa all’utente; mantieni calma e precisione.
• Italiano semplice; evita gergo interno o codici (es: “Errore 0x…”).

Struttura consigliata

• Problema
• Istruzione concreta
• Aiuto/alternativa, se necessario.

In questo modo si rispetta la struttura Error Identification + Error Suggestion, per esempio “Il codice non è valido. Inserisci il codice a 6 cifre oppure richiedine uno nuovo”.

Posizionamento e coerenza testuale

• Messaggio inline per errori di input, con testo breve, specifico e posto immediatamente sotto o accanto al campo.
• Riepilogo errori in alto solo per form complessi, con link ai campi interessati. Assicurati che il testo del link sia lo stesso del messaggio inline.
• Per problemi globali, usa banner chiari e non tecnici; per casi davvero bloccanti, invece, scegli una dialog con CTA esplicita.

Leggibilità e segnali

• Non affidarti solo al colore e abbina sempre l'icona al testo. Nei campi, l’icona di errore è raccomandata e il testo di supporto va sotto il campo finché non viene risolto.
• Mantieni un contrasto adeguato e limita la lunghezza del testo a 1–2 frasi.

Accessibilità del testo

• Il messaggio deve essere annunciato, ad esempio tramite role="alert"/region live, ed essere in grado di spiegare dove intervenire.
• Nei form multi-step, annuncia l’errore nello step pertinente e collega il messaggio al campo con etichette o descrizioni.

Esempi di microcopy

CTA e azioni

• Prediligi verbi d’azione e una singola scelta primaria, come “Riprova”, “Correggi”, “Aggiorna dati”, “Contatta supporto”.
• Se richiedi l'autenticazione, evita prove mnemoniche complesse e proponi percorsi accessibili, come la possibilità di copiare e incollare codici o alternative.
• Usa le stesse parole per lo stesso concetto: se scegli il termine“password”, per esempio, non usare anche “chiave di accesso”. Mantieni severità coerenti (“Avviso”, “Errore”) tra testo e stile visivo.

Template pronti e riusabili

• Campo obbligatorio: “Questo campo è obbligatorio. Compilalo per continuare.”
• Formato: “Inserisci una data nel formato GG/MM/AAAA (es. 02/10/2025).”
• Rete/timeout: “La richiesta è scaduta. Controlla la connessione e riprova.”

Accessibilità

L'accessibilità nell'ambito della gestione degli errori è importante perché i messaggi siano percepibili e comprensibili da tutti.

Assicurati di scrivere sempre dei testi chiari, che compaiano vicino al punto che richiede correzione, con indicazioni utili per proseguire. I messaggi devono essere efficaci anche se letti con tecnologie assistive e non interrompere inutilmente il flusso dell’utente, così da offrire un’esperienza coerente e inclusiva in ogni contesto.