Cosa deve dire la tua app quando si rompe: scrivere messaggi di errore che le persone capiscono davvero

Ogni app si rompe, prima o poi. Cala la connessione, un server ha un intoppo, qualcuno digita un numero di telefono con delle lettere in mezzo. Questa parte non puoi prevenirla del tutto. Quello che puoi controllare è il messaggio di errore — il testo che la tua app mostra quando qualcosa va storto — e spesso è proprio quel messaggio a fare la differenza tra un utente che alza le spalle e riprova, e un utente che decide in silenzio che la tua app è rotta e non torna più.

La maggior parte delle app costruite con l’AI sbaglia esattamente questo momento. Non perché chi le ha costruite sia stato distratto, ma perché i messaggi di errore sono quella parte a cui nessuno pensa finché qualcosa non va storto davanti a una persona vera. Di default, le app tendono a mostrare una delle due peggiori cose possibili: niente, oppure un blocco spaventoso di testo tecnico. Vediamo come risolvere entrambe.

Perché le app falliscono in silenzio o mostrano messaggi di errore spaventosi?

Le app si rompono male in due modi: non dicono niente quando qualcosa fallisce, oppure mostrano un errore tecnico che una persona normale non riesce a leggere. In entrambi i casi l’utente resta a indovinare, ed è proprio l’indovinare che spinge le persone a rinunciare.

Il fallimento silenzioso. Una freelance che chiameremo Maya aveva costruito un modulo di prenotazione per la sua attività di fotografia. Una cliente tocca “Conferma prenotazione”, il pulsante lampeggia, e… niente. Nessuna conferma, nessun errore, nessuno spinner. Ha funzionato? La cliente non ne era sicura, quindi ha prenotato di nuovo. Ora Maya si è ritrovata con due prenotazioni per lo stesso orario e una cliente confusa. L’app non si era bloccata — era solo il salvataggio a essere fallito, e l’app non aveva detto nulla, così chi la stava usando non aveva idea di cosa fosse realmente successo.

L’errore tecnico spaventoso. L’altro tipo di fallimento è più rumoroso e, in un certo senso, ancora peggiore. Una volontaria che gestiva una raccolta fondi per la comunità ha provato a caricare un foglio di calcolo e si è vista comparire un riquadro rosso con scritto Error 500: Internal Server Error. Lo ha interpretato come “ho rotto qualcosa”. Non ha riprovato, non ha scritto per chiedere aiuto: ha semplicemente chiuso la scheda — perché il messaggio faceva sembrare il problema colpa sua, e dava l’idea che ritoccare qualcosa potesse essere rischioso.

Entrambe le utenti si sono imbattute in un problema normale e recuperabile. Entrambe se ne sono andate, perché i messaggi di errore dell’app non dicevano nulla oppure dicevano qualcosa di spaventoso.

Cosa rende buono un messaggio di errore?

Un buon messaggio di errore fa quattro piccole cose, con parole semplici: dice cos’è successo, dice di chi è il problema, dice cosa fare dopo, e non fa perdere il lavoro dell’utente.

Dice cos’è successo — “Non siamo riusciti a salvare la tua prenotazione”, non il silenzio e non 500.
Dice di chi è il problema — di solito la risposta onesta è “nostro”, e dirlo tranquillizza le persone.
Dice cosa fare dopo — “Riprova tra un momento” oppure “Controlla la tua connessione internet e riprova”.
Non fa perdere il lavoro fatto — qualunque cosa abbiano digitato è ancora lì nel modulo quando compare il messaggio.

Tutto qui. Nessun saggio di scuse, nessun codice di errore come titolo, nessuna colpa. Ecco gli stessi tre fallimenti, riscritti:

❌ (non succede nulla) → ✅ “Non siamo riusciti a salvarlo proprio ora. I tuoi dati sono ancora qui — tocca Conferma per riprovare.”
❌ Error 500: Internal Server Error → ✅ “Qualcosa è andato storto da parte nostra durante il caricamento del file. Non è colpa tua. Riprova tra un minuto.”
❌ Invalid input → ✅ “Quel numero di telefono non sembra corretto — dovrebbe avere 10 cifre, tipo 555-123-4567.”

Nota l’ultimo esempio: punta sul campo specifico e mostra come dovrebbe apparire un dato corretto. “Invalid input” costringe a cercare a tentoni; “quel numero di telefono dovrebbe avere 10 cifre” dice esattamente cosa cambiare.

Quali errori dell’app dovresti correggere per primi?

Non serve un messaggio personalizzato per ogni possibile fallimento — tre casi coprono quasi tutto ciò che può andare storto in un’app tipica: il salvataggio o invio che fallisce, l’input che l’app non riesce a usare, e ciò che si rompe dalla tua parte.

Il salvataggio o invio che fallisce. Il più dannoso per la fiducia, perché l’utente ha fatto tutto correttamente e non sa se ha funzionato. Conferma sempre il successo e spiega il fallimento. Non lasciarli mai a indovinare, e non buttare mai via quello che hanno digitato.

Il “non riusciamo a usare quello che hai digitato” (validazione). Non è davvero un errore — è un malinteso. Intercettalo nel momento in cui l’utente esce dal campo, indica esattamente quale campo è, e mostra un esempio del formato corretto. Non aspettare che premano Invia per rivelare un muro di rosso.

Il “qualcosa dalla nostra parte si è rotto”. Problemi reali di server o di rete. Di’ che è colpa vostra, mantieni un tono calmo, e offri la possibilità di riprovare. L’utente non può sistemare il vostro server, quindi non fatelo sentire in dovere di farlo.

Tre abitudini che aiutano silenziosamente

Alcune cose distinguono le app che gestiscono bene i fallimenti da quelle che non ci riescono:

Non mostrare mai un codice di errore grezzo come messaggio principale. Un codice può stare in piccolo, sotto, per l’assistenza, ma il titolo che una persona legge deve essere una frase, non ERR_CONN_RESET.
Non incolpare mai l’utente. “Hai inserito qualcosa di sbagliato” fa male; “quella data sembra essere nel passato — intendevi il mese prossimo?” aiuta. Stessa informazione, sensazione completamente diversa.
Conserva sempre quello che ha digitato. Se l’app si ricarica o il salvataggio fallisce e il modulo si svuota, hai trasformato un piccolo intoppo in dieci minuti di ridigitazione. Le persone perdonano un salvataggio fallito. Non perdonano di dover rifare il lavoro due volte.

Come fai a far scrivere al tuo AI builder messaggi di errore migliori?

Puoi ottenere gran parte di questo con una sola richiesta — incolla qualcosa come il prompt qui sotto e il tuo AI builder applicherà le regole di linguaggio semplice viste sopra in tutta la tua app.

“Quando un salvataggio o un caricamento fallisce, non fallire in silenzio e non mostrare un codice di errore tecnico. Mostra un messaggio breve e amichevole, in linguaggio semplice, che dica cos’è successo, dica che va bene riprovare, e conservi tutto quello che l’utente ha già digitato. Per i campi del modulo, valida quando l’utente esce da ciascun campo e mostra un messaggio specifico con un esempio del formato corretto.”

Poi chiedigli di mostrarti cosa succede in tre casi: internet è spento, un campo obbligatorio è vuoto, e il server è lento. Se la risposta a uno qualunque di questi è “non mostra niente” oppure “mostra l’errore grezzo”, è quella la prossima cosa da sistemare.

Come testi i messaggi di errore della tua app?

Spegni il wifi, apri la tua app, e prova a fare l’azione principale — questo è tutto il test, e richiede due minuti.

Prenota lo slot, salva la nota, carica il file. Guarda cosa dice. Ti ha detto qualcosa che una persona normale capirebbe? Ha perso quello che avevi digitato? Ora riaccendi il wifi e digita deliberatamente dati sbagliati in un campo. Stesse domande.

La maggior parte delle app fallisce questo test la prima volta, ed è normale — ti mostra semplicemente da dove iniziare. Non devi rendere perfetto ogni messaggio di errore. Trova la cosa nella tua app che si rompe più spesso, e rendi quel messaggio gentile, chiaro e onesto per primo. La prossima volta che una persona vera lo incontrerà, riproverà invece di andarsene — e riprovare è tutto ciò che conta.