Linee guida per i messaggi di errore

Un messaggio di errore è un testo visualizzato per descrivere un problema che impedisce all'utente o al sistema di completare un'attività. Il problema potrebbe causare il danneggiamento o la perdita di dati. Altri tipi di messaggi includono conferme, avvisi e notifiche. Le linee guida contenute in questo argomento consentono di scrivere messaggi di errore chiari che sono facili da localizzare e utili per i clienti.

I messaggi di errore scritti in modo errato possono essere fonte di frustrazione per gli utenti e possono aumentare i costi di supporto tecnico. Un messaggio di errore ben scritto fornisce le informazioni seguenti all'utente:

  • Cosa è successo e perché?
  • Qual è il risultato finale per l'utente?
  • Cosa può fare l'utente per impedire che si verifichi di nuovo?

La lunghezza del testo non è un problema, purché lo sviluppatore gestisca correttamente le dimensioni del buffer. È importante che l'utente disponga di tutte le informazioni necessarie per risolvere il problema. Se un messaggio include più gruppi di destinatari, potrebbe essere necessario fornire testo separato per amministratori, utenti finali e sviluppatori.

Consigli per iniziare

Di seguito sono riportati i modi per migliorare i messaggi di errore:

  • Evitare condizioni di errore. Se è possibile prevedere che si verificherà un errore quando un utente esegue un'azione specifica, riscrivere il codice in modo che l'utente non possa causare l'errore.
  • Scrivere un messaggio di errore separato per ogni causa nota dell'errore. Non usare un singolo messaggio generico per spiegare ogni possibile motivo dell'errore, a meno che non sia possibile determinare la causa dell'errore quando si verifica.
  • Dichiarare chiaramente il problema e, se sarà utile per l'utente, spiegare cosa ha causato il problema. Quando possibile, sostituire i messaggi generici dalle risorse della tabella messaggi di sistema con un messaggio dettagliato specifico per il problema.
  • Fornire all'utente una soluzione al problema. Se la soluzione ha più di un passaggio, fare riferimento a un argomento della Guida in cui viene illustrata in dettaglio l'attività.
  • Visualizza solo il nome del prodotto, del componente o della procedura guidata nella barra del titolo del messaggio. Ciò consente all'utente di determinare dove si trova il problema. Non riepilogare il problema nella barra del titolo o includere la parola "error".
  • Non usare il gergo tecnico, usare la terminologia che il pubblico riconosce. Non usare abbreviazioni o slang.
  • Usare i pulsanti di comando appropriati, ad esempio OK, Annulla, Sì, No e Riprova. È possibile usare combinazioni di questi pulsanti. I pulsanti Sì e No devono essere sempre utilizzati in combinazione e devono essere sempre preceduti da una domanda.
    • Per arrestare un'operazione e chiudere la finestra di messaggio, usare il pulsante Annulla .
    • Per chiudere una finestra di messaggio, usare il pulsante Chiudi .
    • Per fornire altre informazioni sulla causa dell'errore, usare il pulsante Dettagli .
    • Per fornire altre informazioni sulla soluzione al problema, usare il pulsante ?
    • Se nel messaggio è inclusa un'azione dell'utente, usare il pulsante OK per chiudere la finestra di messaggio.
    • I pulsanti Sì e No devono essere usati in combinazione e devono essere sempre preceduti da una domanda.
  • Se l'errore è un errore critico, scriverlo nel registro eventi.

Considerazioni sullo stile

  • Usare frasi complete ma semplici.
  • Utilizzare il tempo presente per descrivere le condizioni che hanno causato il problema o uno stato ancora esistente. È possibile usare il tempo passato per descrivere un evento distinto che si è verificato in passato.
  • Usare la voce attiva ogni volta che è possibile. È possibile usare la voce passiva per descrivere la condizione di errore.
  • Evitare il testo maiuscolo e i punti esclamativi.
  • Non fare in modo che l'utente si senta in errore anche se il problema è il risultato di un errore dell'utente.
  • Non antropomorfizza. Non implicare che i programmi o l'hardware possano pensare o sentire.
  • Non usare parole o frasi colloquiali. Non usare termini che possono essere offensivi in determinate impostazioni cultura.
  • Non complicare più sostantivi senza aggiungere una preposizione o una sottoclausa per chiarire il significato. Ad esempio, "Server del server del sito server LDAP server directory" deve essere modificato in "Server directory per il servizio LDAP del server del sito".
  • Inserire descrittori prima di un termine per chiarire il significato della frase. Ad esempio, "Specify InfID when Detect is set to No". (Specificare il parametro InfID quando l'opzione Detect è impostata su No).
  • Evitare la parola "bad". Usare termini più descrittivi per indicare all'utente cosa è sbagliato. Ad esempio, evitare messaggi come "Dimensioni non corrette". In alternativa, indicare all'utente quali criteri usare quando si specifica una dimensione.
  • Evitare la parola "please". Può essere interpretato per indicare che un'azione obbligatoria è facoltativa.
  • Inserire parole che si trovano sia nell'indice che pertinenti al significato centrale all'inizio della stringa del messaggio.