Miglioratore UX dei Messaggi di Errore
Il Miglioratore UX dei Messaggi di Errore prende i messaggi di errore esistenti della tua applicazione e li riscrive in testi chiari, pensati per le persone, che dicono all'utente cosa è successo, perché è successo e cosa fare dopo. Trasforma stringhe criptiche come "Error 403: Forbidden" in indicazioni concrete che riducono confusione e volume di ticket di supporto.
Sviluppatori frontend, UX writer, product manager e team di design usano questo template durante le fasi di rifinitura della UI, audit di accessibilità, analisi dei ticket di supporto o quando costruiscono da zero un sistema di gestione errori. È particolarmente utile per team composti principalmente da sviluppatori senza un UX writer dedicato, dove i messaggi di errore tendono a riflettere stati interni del sistema piuttosto che il modello mentale dell'utente.
Il prompt funziona richiedendo di fornire il contesto tecnico dietro ogni errore (cosa lo ha attivato, chi lo vede, quali opzioni di recupero esistono) così l'AI può scrivere messaggi ancorati all'esperienza reale dell'utente, invece di produrre frasi generiche. L'output segue le best practice di UX writing: inizia con cosa è andato storto in linguaggio semplice, spiega la causa senza gergo tecnico, fornisce un'azione di recupero specifica e mantiene il tono emotivo giusto (utile, non condiscendente; onesto, non allarmante). La difficoltà avanzata riflette il giudizio necessario per bilanciare accuratezza tecnica ed empatia verso l'utente.
This prompt is just the starting point
Score it with AI, optimize it with one click, track versions, and build your prompt library.
The Prompt
Riscrivi i seguenti messaggi di errore per renderli user-friendly e azionabili:
**Tipo di Applicazione**: [web app / app mobile / strumento CLI / API / software desktop]
**Tono del Brand**: [amichevole / professionale / neutro / giocoso]
**Livello Tecnico del Pubblico**: [utenti non tecnici / misto / utenti tecnici]
Per ogni messaggio di errore qui sotto, fornisci il contesto e il messaggio attuale:
**Errore 1**:
- Messaggio attuale: [INCOLLA IL MESSAGGIO DI ERRORE ATTUALE, es. "Error 403: Access denied. Invalid permissions."]
- Quando appare: [DESCRIVI IL TRIGGER, es. "Quando un utente del piano gratuito tenta di accedere a una funzionalità premium"]
- Opzioni di recupero disponibili: [COSA PUÒ FARE L'UTENTE, es. "Aggiornare il piano, contattare l'admin o tornare alla dashboard"]
**Errore 2**:
- Messaggio attuale: [INCOLLA IL MESSAGGIO DI ERRORE ATTUALE]
- Quando appare: [DESCRIVI IL TRIGGER]
- Opzioni di recupero disponibili: [COSA PUÒ FARE L'UTENTE]
**Errore 3**:
- Messaggio attuale: [INCOLLA IL MESSAGGIO DI ERRORE ATTUALE]
- Quando appare: [DESCRIVI IL TRIGGER]
- Opzioni di recupero disponibili: [COSA PUÒ FARE L'UTENTE]
[Aggiungi altri errori se necessario]
Per ogni errore, fornisci:
1. **Messaggio Riscritto** con tre componenti:
- **Titolo** (5-8 parole): Cosa è andato storto, in linguaggio semplice
- **Corpo** (1-2 frasi): Perché è successo e cosa fare dopo, con un'azione specifica
- **Testo del pulsante di azione** (2-4 parole): L'azione di recupero principale come etichetta di un pulsante
2. **Versione Alternativa**: Una seconda riscrittura con un tono o un'angolazione diversa, così puoi scegliere quale si adatta meglio.
3. **Note di Microcopy**:
- Se l'errore deve essere inline (accanto al campo di input), toast/snackbar (notifica temporanea), modale (richiede un'azione) o a pagina intera
- Icona o indicatore visivo suggerito (triangolo di warning, cerchio info, alert rosso)
- Se registrare l'errore silenziosamente, mostrarlo all'utente, o entrambi
- Considerazione di accessibilità: come uno screen reader dovrebbe annunciare questo messaggio
4. **Anti-pattern Evitati**: Spiega cosa c'era di sbagliato nel messaggio originale (es. gergo tecnico, colpevolizzazione dell'utente, nessun percorso di recupero, troppo vago) e quale principio segue la riscrittura.
Segui questi principi per tutte le riscritture:
- Non colpevolizzare mai l'utente ("Hai inserito un formato non valido..." diventa "Questo formato non è stato riconosciuto...")
- Non usare mai codici di errore come messaggio principale (i codici possono apparire in piccolo come riferimento per il supporto)
- Includi sempre almeno un'azione specifica che l'utente può compiere
- Adatta il livello di lettura al pubblico (punta a un livello di lettura da terza media per utenti non tecnici)
- Mantieni il messaggio sotto le 30 parole totali (titolo + corpo) per errori inline e toast, sotto le 60 parole per modali e pagine intereUsage Tips
- Raggruppa gli errori per categoria: Raggruppa errori di validazione, permessi, rete e sistema separatamente. Ogni categoria ha pattern UX e requisiti di tono diversi, e il raggruppamento aiuta l'AI a mantenere coerenza all'interno di ogni gruppo.
- Includi esplicitamente le opzioni di recupero: L'AI non può inventare percorsi di recupero che la tua applicazione non supporta. Se l'unica opzione è "riprova più tardi", dillo. Se l'utente può riprovare, modificare un'impostazione o contattare il supporto, elenca tutte le opzioni disponibili.
- Testa le riscritture con utenti reali: I messaggi di errore sono notoriamente difficili da valutare in isolamento. Fai leggere i messaggi riscritti a 3-5 utenti del tuo target e chiedi cosa farebbero dopo aver visto ogni messaggio. Se esitano, il messaggio va rivisto.
- Crea una guida di stile dai risultati: Dopo aver riscritto 10-15 errori, noterai pattern ricorrenti nel tono, nella struttura e nella lunghezza. Documenta questi pattern come guida di stile così il team potrà scrivere messaggi di errore coerenti senza ricorrere a questo prompt ogni volta.
- Abbina al logging degli errori: Per ogni messaggio visibile all'utente, assicurati che l'errore tecnico originale (inclusi codici e contesto dello stack) sia registrato lato server. Questo ti permette di semplificare il messaggio per l'utente senza perdere informazioni diagnostiche.
Get more from this prompt
Save it, score it with AI, optimize it, and track every version. Free to start.