Un messaggio di errore compare quando una persona cerca di completare un’attività e qualcosa glielo impedisce. Se si limita ad annunciare che c’è stato un problema, lascia chi lo usa senza sapere se deve correggere un dato, aspettare, riprovare o chiedere aiuto. Per chi si occupa di prodotto e tecnologia, l’obiettivo non è abbellire il malfunzionamento: è aiutare a scegliere il passo successivo ed evitare che la persona perda il proprio lavoro o ripeta un’azione con possibili conseguenze.
Progettare messaggi utili richiede di conoscere l’origine dell’errore, le informazioni ancora disponibili e le opzioni per recuperare. Richiede anche di coordinare il testo con il comportamento effettivo dell’applicazione. Un’istruzione come «Riprova» è dannosa se l’operazione è già stata completata o se ripeterla può creare un duplicato.
Classifica l’errore prima di scrivere il messaggio
Inizia individuando che cosa impedisce di completare l’attività e chi può risolvere il problema. Questa classificazione aiuta a scegliere sia il contenuto sia l’azione disponibile:
- Errore correggibile dalla persona: manca un campo obbligatorio, il formato di un dato non è valido oppure una selezione non soddisfa una condizione. Spiega che cosa occorre verificare e indica il campo specifico.
- Problema temporaneo del sistema: l’applicazione non riesce a completare un’operazione a causa di un disservizio o di una condizione transitoria. Indica se conviene aspettare o riprovare e che cosa succederà ai dati.
- Dipendenza esterna: un servizio collegato non risponde o rifiuta la richiesta. Non attribuire la causa alla persona e non promettere quando il problema sarà risolto. Comunica ciò che l’applicazione sa e proponi un’alternativa praticabile.
- Situazione che richiede assistenza: la persona non può risolvere il blocco dall’interfaccia oppure il caso richiede una verifica. Spiega come contattare l’assistenza e quali informazioni utili fornire.
Non è necessario esporre l’architettura tecnica per fare questa distinzione. È però necessario concordare con il team di sviluppo quale stato abbia restituito l’operazione, se le modifiche sono state salvate e se è sicuro ripeterla. Senza queste informazioni, il team dei contenuti non può offrire istruzioni affidabili.
Indica una causa comprensibile, l’impatto e il passo successivo
Un messaggio pratico risponde, con un linguaggio quotidiano, a tre domande: che cosa è successo, che cosa comporta e che cosa si può fare adesso. Se è rilevante, aggiungi se i dati sono stati conservati. Non occorre spiegare tutti i dettagli interni: basta fornire il contesto necessario per poter agire.
Per esempio, «Non è stato possibile salvare il modulo perché manca il numero di telefono. Inserisci un numero nel campo Telefono e salva di nuovo» chiarisce il risultato, il motivo e come correggerlo. «Errore durante l’elaborazione della richiesta», invece, non indica dove intervenire. Per un problema temporaneo, una frase come «Non siamo riusciti a caricare i risultati. I filtri sono ancora disponibili; riprova» è utile solo se l’interfaccia conserva davvero quei filtri.
Verifica ogni testo rispetto allo stato effettivo del prodotto. Se non puoi confermare che i dati siano stati salvati, non dire che sono al sicuro. Se non conosci la causa, non inventarla: comunica il risultato e un’azione sicura. È preferibile una spiegazione limitata ma precisa a una promessa rassicurante che l’applicazione non può mantenere.
Scegli una modalità di recupero che non peggiori il problema
L’azione proposta deve corrispondere al tipo di errore e alle conseguenze di un’eventuale ripetizione. Prima di mostrare un pulsante o un’istruzione, rispondi a queste domande:
- La persona può correggere il problema? Se sì, indirizza l’attenzione al campo o alla scelta da modificare e, quando possibile, conserva il resto.
- È sicuro riprovare? Se l’operazione potrebbe essere stata completata anche se l’interfaccia non lo conferma, non proporre di riprovare alla cieca. Verifica lo stato oppure spiega come controllarlo.
- Si può proseguire in un altro modo? Se esiste un’alternativa funzionante, come salvare una bozza o completare la procedura più tardi, rendila visibile senza nascondere l’opzione principale.
- Serve assistenza? Indica un canale disponibile e, se utile, un codice di riferimento. Non fare del contatto con l’assistenza l’unica via d’uscita quando la persona può risolvere il problema autonomamente.
Per le operazioni sensibili, ad esempio inviare un ordine, effettuare un pagamento o pubblicare un contenuto, concorda con il team di sviluppo come confermare il risultato e come evitare che l’azione venga ripetuta. Il messaggio visualizzato deve rispecchiare questo comportamento: il testo, da solo, non può garantire che un’operazione sia sicura.
Scrivi con chiarezza e senza colpevolizzare
Scrivi per chi sta cercando di completare un’attività, non per chi esegue il debug del sistema. Evita codici interni, nomi di componenti ed espressioni come «richiesta non valida» se non spiegano che cosa correggere. Un codice può essere utile all’assistenza, ma deve accompagnare una spiegazione comprensibile, non sostituirla.
Usa un tono diretto e neutro. «Non siamo riusciti a convalidare l’indirizzo» descrive il risultato senza accusare. «Hai inserito l’indirizzo in modo errato» attribuisce la colpa alla persona e potrebbe essere inesatto: forse il formato richiesto non è chiaro. Evita anche istruzioni vaghe come «Controlla i tuoi dati» quando puoi indicare il dato da verificare.
La brevità è utile, ma non deve portare a omettere una conseguenza importante. Se una risposta è stata cancellata, se la procedura è ancora in sospeso o se è possibile riprovare senza creare duplicati, dillo. Se non sai quale di queste situazioni si applichi, interrompi la stesura e chiedi al team tecnico di definire lo stato.
Fai in modo che il messaggio sia percepibile e utilizzabile
Il testo deve comparire vicino all’elemento interessato oppure in una posizione coerente con la portata del problema. Un errore relativo a un campo è di solito più utile accanto al campo che in un avviso distante. Se è bloccata l’intera attività, un messaggio generale può spiegare la situazione e proporre un’azione principale. Non affidarti soltanto al colore per comunicare un errore: accompagnalo con un testo riconoscibile.
Verifica che il messaggio sia comprensibile con la tastiera e con le tecnologie assistive e che la persona possa individuare il campo correlato senza doverlo indovinare. Nei moduli, controlla se l’errore rimane visibile dopo la correzione del dato e se la gestione del focus o la navigazione consentono di proseguire. L’accessibilità non si ottiene con una frase corretta se l’avviso non raggiunge chi ne ha bisogno.
Conta anche il momento in cui compare: un avviso che scompare prima di poter essere letto, o che viene mostrato prima che la persona abbia finito di scrivere, può aumentare la confusione. Verifica il comportamento nell’interfaccia reale e negli stati pertinenti, non soltanto il testo in un documento.
Documenta e verifica una matrice degli errori
Per evitare risposte diverse allo stesso problema, crea una matrice condivisa tra prodotto, design, sviluppo e assistenza clienti. Includi almeno:
- Nome dello stato e origine nota del problema.
- Attività che la persona stava svolgendo e portata dell’impatto.
- Dati conservati, eliminati o ancora in attesa di conferma.
- Testo visualizzato, posizione e azione disponibile.
- Responsabile della verifica del comportamento e criteri per rivolgersi all’assistenza.
Dai priorità agli errori che bloccano attività importanti, possono causare la perdita di dati o generano richieste ripetute. Prova i messaggi con attività reali: osserva se la persona capisce che cosa è successo, trova il passo successivo e riesce a proseguire senza istruzioni esterne. Registra i punti in cui abbandona o riprova, insieme alle richieste ricevute dall’assistenza, e confronta questi segnali prima e dopo le modifiche. Una diminuzione delle richieste, da sola, non dimostra che il problema sia risolto: potrebbe significare che le persone hanno smesso di provare a completare l’attività.
Aggiorna la matrice quando cambiano il flusso, le dipendenze o la logica di salvataggio. La qualità di un messaggio non si misura da quanto suona gentile, ma dalla precisione con cui descrive lo stato e dalla possibilità che offre di agire. Quando il prodotto non conosce ancora il risultato, la scelta migliore può essere evitare un nuovo tentativo automatico, spiegare l’incertezza e proporre un modo sicuro per verificare la situazione o chiedere assistenza.