Come convincere gli utenti a leggere i messaggi di errore?

Se programmate per un pubblico non tecnico, vi trovate ad alto rischio che gli utenti non leggano i vostri messaggi di errore attentamente formulati e illuminanti, ma fate semplicemente clic sul primo pulsante disponibile con una scrollata di spalle di frustrazione.

Quindi, mi chiedo quali buone pratiche puoi consigliare per aiutare gli utenti a leggere effettivamente il tuo messaggio di errore, anziché semplicemente rinunciare a parte. Le idee a cui riesco a pensare cadono sulla falsariga di:

• Formattare naturalmente l'aiuto; forse un messaggio breve e semplice, con un pulsante "Ulteriori informazioni" che porta al messaggio di errore più lungo e dettagliato
• Avere tutti i messaggi di errore collegati ad alcune sezioni del manuale dell'utente (un po 'difficile da raggiungere)
• Basta non inviare messaggi di errore, semplicemente rifiutare di eseguire l'attività (un modo un po '"Apple" di gestire l'input dell'utente)

Modifica: il pubblico che ho in mente è una base di utenti piuttosto ampia che non usa il software troppo spesso e non è in cattività (cioè, nessun software interno o comunità ristretta). Una forma più generica di questa domanda è stata posta su slashdot , quindi potresti voler controllare lì per alcune delle risposte.

Questa è un'ottima domanda degna di un +1 da parte mia. La domanda, nonostante sia semplice, copre molti aspetti della natura degli utenti finali. Si riduce a una serie di fattori che potrebbero giovare a te e al software stesso, e ovviamente per gli utenti finali.

• Non inserire messaggi di errore nella barra di stato: non li leggeranno mai nonostante siano ravvivati ​​dai colori, ecc., Gli mancheranno sempre! Non importa quanto duramente proverai ... Ad un certo punto durante il test dell'interfaccia utente di Win 95 prima che fosse lanciato, MS ha condotto un esperimento per leggere l'interfaccia utente ( ndr - va notato che il messaggio ha dichiarato esplicitamente nel contesto di 'Guarda sotto la sedia' ), con una banconota da $ 100 registrata sul lato inferiore della sedia su cui erano seduti i soggetti ... nessuno ha notato il messaggio nella barra di stato!
• Abbrevia i messaggi, non usare parole intimidatorie come "Avviso: il sistema ha riscontrato un problema", l'utente finale premerà il pulsante di panico e reagirà in modo eccessivo ...
• Non importa quanto ci provi, non usare i colori per identificare il messaggio ... psicologicamente, è come sventolare una bandiera rossa sul toro!
• Usa parole dal suono neutro per comunicare una reazione minima e come procedere!
• Potrebbe essere meglio mostrare una finestra di dialogo che elenca il messaggio di errore neutro e includere una casella di controllo che indica "Desideri vedere più di questi messaggi di errore in futuro?", L'ultima cosa che un utente finale desidera, deve funzionare nel mezzo del software da bombardare con messaggi popup, saranno frustrati e saranno disattivati ​​dall'applicazione! Se la casella di controllo è stata selezionata, registrala invece in un file ...
• Tieni gli utenti finali informati di quali messaggi di errore ci saranno ... il che implica ... formazione e documentazione ... ora questo è difficile da trasmettere ... non vuoi che pensino che ci sarà essere "problemi" o "problemi" e cosa fare in caso ... non devono sapere che ci saranno errori possibili, anzi difficili.
• Sempre, sempre, non aver paura di chiedere feedback quando si verificano eventi senza incidenti, come "Quando è apparso quell'errore numero 1304, come hai reagito? Qual è stata la tua interpretazione "- il vantaggio è che l'utente finale potrebbe essere in grado di darti una spiegazione più coerente invece di" Errore 1304, oggetto del database perso! ", Invece potrebbe essere in grado di dire" Ho cliccato su questo così e così, quindi qualcuno ha accidentalmente tirato il cavo di rete della macchina ", questo ti indurrà a doverlo gestire e potrebbe modificare l'errore per dire" Spiacenti, connessione di rete disconnessa "... ottieni la deriva.
• Ultimo ma non meno importante, se vuoi indirizzare il pubblico internazionale, prendi in considerazione l'internazionalizzazione dei messaggi di errore - quindi è per questo che per mantenerlo neutrale, perché sarà più facile tradurre, evitare sinonimi, parole gergali, ecc. la traduzione non ha senso - per esempio, Fiat Ford, la società automobilistica vendeva il loro marchio Fiat Ford Pinto, ma notò che non stavano accadendo vendite in Sud America, si scoprì che Pinto era un gergo lì per "pene piccolo" e quindi nessuna vendita ...
• ( ed ) Documentare l'elenco dei messaggi di errore che ci si aspetta in una sezione separata della documentazione intitolata "Messaggi di errore" o "Azioni correttive" o simili, elencando i numeri di errore nell'ordine corretto con una o due dichiarazioni su come procedere. ..
• (a cura di ) Grazie a Victor Hurdugaci per il suo contributo, mantieni educati i messaggi, non far sentire stupidi gli utenti finali. Questo va contro la risposta di Jack Marchetti se la base di utenti è internazionale ...

Modifica: un ringraziamento speciale a gnibbler che ha menzionato anche un altro punto estremamente vitale!

• Consentire all'utente finale di essere in grado di selezionare / copiare il messaggio di errore in modo che, se lo desiderano, possano inviare un'e-mail al team di supporto o al team di sviluppo.

Modifica n. 2: Mio cattivo! Spiacenti , grazie a DanM che mi ha detto che sull'auto, ho confuso il nome, era Ford Pinto ... il mio cattivo ...

Modifica n. 3: sono stati evidenziati da ed per indicare elementi aggiuntivi o addendum e accreditati ad altri per i loro input ...

Modifica n. 4: in risposta al commento di Ken - ecco la mia opinione ... No, non lo è, usa colori Windows standard neutri ... non scegliere colori appariscenti! Attenersi al normale colore di sfondo grigio con testo nero, che è una normale linea guida GUI standard nelle specifiche Microsoft. Vedere Linee guida UX ( ndr ).

Se insisti sui colori sgargianti, almeno, prendi in considerazione i potenziali utenti daltonici, cioè l' accessibilità, che è un altro fattore importante per coloro che hanno una disabilità, messaggi di errore amichevoli per l'ingrandimento dello schermo, daltonismo, quelli che soffrono di albino, essi potrebbe essere sensibile ai colori sgargianti e anche agli epilettici ... che potrebbero soffrire di particolari colori che potrebbero scatenare un attacco ...

Mostra loro il messaggio. Dovuto dilligence e tutto, ma registra ogni errore in un file. Gli utenti non riescono a ricordare cosa stessero facendo o quale fosse il messaggio di errore pochi secondi dopo l'evento, è come una testimonianza oculare di autori.

Fornisci un buon modo per consentire loro di inviare e-mail o caricare il registro su di te in modo da poterli aiutare a riconciliare il problema. Se si tratta di un'applicazione Web: ancora meglio, puoi ricevere informazioni sulla situazione prima che chiunque abbia segnalato il problema.

Risposta breve: non puoi.

Risposta meno breve: rendili visibili, pertinenti e contestuali (evidenzia ciò che hanno incasinato). Tuttavia, stai combattendo una battaglia persa. Le persone non leggono sullo schermo del computer, scansionano e sono state addestrate a fare clic sui pulsanti fino a quando le finestre di dialogo scompaiono.

Mettiamo un semplice grafico memorabile nella casella dell'errore: non un'icona, una bitmap abbastanza grande e niente come le icone standard dei messaggi di Windows. Nessuno potrà mai ricordare il testo di una finestra di messaggio (la maggior parte non la leggerà nemmeno se la scatola ha un pulsante "OK" che può premere), ma la maggior parte delle persone ricorda l'immagine che hanno visto. Quindi il nostro personale di supporto può chiedere al cliente "hai visto il ragazzo che beve il caffè?" o "hai visto la scrivania vuota?". Almeno in questo modo sappiamo più o meno cosa è andato storto.

A seconda della base di utenti, scrivere messaggi di errore divertenti / maleducati / personali può funzionare alla grande.

Ad esempio, ho scritto un'applicazione che ha permesso ai nostri addetti alle risorse umane di tracciare meglio le date di assunzione / licenziamento dei dipendenti. [eravamo una piccola azienda, molto rilassata].

Quando hanno inserito date sbagliate scrivevo:

Ehi coglione, impara come inserire un appuntamento!

MODIFICA: Naturalmente un messaggio più utile è dire: "Inserisci la data come mm / gg / aaaa" o forse nel codice per cercare di capire cosa hanno inserito e se hanno inserito "blahblah" per mostrare un errore. Tuttavia, questa era un'applicazione molto piccola per una persona delle risorse umane che conoscevo personalmente. Quindi di nuovo gente, leggi la prima riga di questo post: a seconda della tua base di utenti ...

Di recente ho lavorato a un progetto dell'Art Institute, quindi i messaggi di errore erano rivolti al pubblico, come:

La maggior parte dell'arte prima del periodo barocco non era firmata. Tuttavia, ora siamo al di là del periodo barocco, quindi tutti i campi devono essere completati.

Fondamentalmente orientalo al tuo pubblico, se possibile, ed evita noiosi come tutti gli errori generici soprannaturali come: "per favore inserisci email" o "per favore inserisci email validi".

Gli avvisi / popup sono fastidiosi, ecco perché tutti premono il primo pulsante che vedono.

Rendilo meno fastidioso . Esempio: se l'utente ha inserito la data in modo errato o ha immesso un testo in cui sono previsti numeri, NON pop-up un messaggio, basta evidenziare il campo e scrivere un messaggio da qualche parte attorno ad esso.

Crea una finestra di messaggio personalizzata . Non utilizzare mai la finestra di messaggio predefinita del sistema, ad esempio le finestre di messaggio di Windows XP sono fastidiose. Crea una nuova finestra di messaggio colorata, con un colore di sfondo diverso rispetto all'impostazione predefinita del sistema.

Molto importante: non insistere . Alcune finestre di messaggio usano la finestra di dialogo modale e insistono nel farti leggere, questo è molto fastidioso. Se riesci a far apparire la finestra di messaggio come messaggio di avviso, sarebbe meglio, ad esempio, i messaggi Stack Overflow che appaiono proprio nella parte superiore della pagina, che informano ma non sono fastidiosi.

AGGIORNA
Rendi il messaggio significativo e utile . Ad esempio, non scrivere qualcosa del tipo "Nessuna tastiera trovata, premi F1 per continuare".

Il miglior design dell'interfaccia utente sarà dove praticamente non mostrerai mai un messaggio di errore. Il software dovrebbe adattarsi all'utente. Con quel tipo di design, un messaggio di errore sarà nuovo e attirerà l'attenzione degli utenti. Se conduci l'utente con dialoghi insensati come quello, li stai formando esplicitamente per ignorare i tuoi messaggi.

Secondo la mia opinione ed esperienza, sono gli utenti esperti, che non leggono i messaggi di errore. Il pubblico non tecnico che conosco legge ogni messaggio sullo schermo più attentamente e il problema a questo punto principalmente è: non lo capiscono.

Questo punto può essere la causa della tua esperienza, perché a un certo punto smetteranno di leggerli, perché "non lo capiscono comunque", quindi il tuo compito è facile:

Rendi il messaggio di errore il più semplice possibile da comprendere e tieni la parte tecnica sotto il cofano.

Ad esempio trasferisco un messaggio come questo:

ORA-00237: operazione di istantanea non consentita: file di controllo appena creato Causa: è stato effettuato un tentativo di richiamare cfileMakeAndUseSnapshot con un file di controllo attualmente montato che è stato appena creato con CREATE CONTROLFILE. Azione: montare un file di controllo corrente e ritentare l'operazione.

a qualcosa come:

Questo passaggio non è stato elaborato a causa di problemi momentanei con il database. Contatta (il tuo amministratore | l'helpdesk | chiunque possa contattare lo sviluppatore o l'amministratore per risolvere il problema). Ci dispiace per l'inconvenienza.

Mostra agli utenti che il messaggio di errore ha un significato ed è un modo per fornire assistenza a loro e loro lo leggeranno. Se è solo un gergo o un messaggio senza senso generico, impareranno a respingerli rapidamente.

Ho imparato che è una buona pratica includere una finestra di dialogo di errore con l'azione predefinita per inviare (ad esempio via e-mail) informazioni diagnostiche dettagliate, se si risponde rapidamente a tali e-mail con informazioni preziose o soluzioni alternative, ti adoreranno.

Questo è anche un ottimo strumento di apprendimento. Nelle versioni future è possibile risolvere i problemi noti o almeno fornire informazioni sulla soluzione alternativa sul posto. Fino ad allora gli utenti impareranno che questo messaggio è causato da X e il problema può essere risolto da Y - tutto perché qualcuno glielo ha spiegato.

Ovviamente questo non funzionerà su un'applicazione su larga scala, ma funziona molto bene in applicazioni aziendali con poche centinaia di utenti e, in un ambiente agile, rilascia spesso versioni anticipate, ambiente.

MODIFICARE:

Dato che hai una vasta base di utenti, ti consiglio di fornire un software che fa ciò che gli utenti sono / possono aspettarsi che faccia, ad es. non mostrare loro il messaggio di errore se il numero di telefono non è formattato correttamente, riformattare se per loro.

Personalmente mi piace il software che non mi fa pensare , e quando occasionalmente non c'è niente che tu (lo sviluppatore) puoi fare per interpretare le mie intenzioni, fornire messaggi molto ben scritti (e revisionati dagli utenti reali).

È risaputo che le persone non leggono la documentazione (hai letto le istruzioni back-to-back quando hai collegato l'elettrodomestico?), Cercano un modo per ottenere rapidamente risultati, quando fallisci devi attirare la loro attenzione (ad es. disabilita pulsante predefinito per un po '), con significativi e utili informazioni. A loro non importa del tuo fallimento del software, ora vogliono ottenere risultati.

Rendili divertenti . (Sembrava pertinente, dato il sito in cui ci troviamo :))

Per iniziare, scrivi messaggi di errore che gli utenti possano effettivamente comprendere. "Errore: 1023" non è un buon esempio. Penso che il modo migliore sia registrare l'errore, piuttosto che mostrarlo all'utente con un codice "elaborato". O se la registrazione non è possibile, fornire agli utenti il ​​modo corretto di inviare i dettagli dell'errore al dipartimento di supporto.

Inoltre, sii breve e abbastanza chiaro. Non includere alcuni dettagli tecnici. Non mostrare loro informazioni che non possono usare. Se possibile, fornire una soluzione alternativa per l'errore. In caso contrario, fornire un percorso predefinito, che dovrebbe essere preso.

Se l'applicazione è un'app Web, la progettazione di pagine di errore personalizzate è una buona idea. Sottolineano meno gli utenti, prendono SO per esempio. Puoi avere alcune idee su come progettare una buona pagina di errore qui: http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/

Una cosa che vorrei aggiungere.

Utilizzare i verbi per i pulsanti di azione per chiudere i messaggi di errore anziché le esclamazioni, ad esempio non utilizzare "Ok!" "Chiudi" ecc.

Un buon consiglio che ho imparato è che dovresti scrivere una finestra di dialogo come un articolo di giornale. Non nel senso della dimensione, ma nel senso dell'importanza. Lasciatemi spiegare.

Dovresti scrivere le cose più importanti da leggere, prima e fornire informazioni più dettagliate in secondo luogo.

In altre parole, questo non va bene:

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Do you want to retry opening the file?

Invece, cambia l'ordine:

Problem loading file, do you want to retry?

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

In questo modo, l'utente può leggere tutto ciò che vuole, o dare fastidio, e avere ancora un'idea di ciò che viene chiesto.

Vedi anche le risposte degli utenti di Slashdot qui .

A meno che tu non sia in grado di fornire all'utente una semplice soluzione, non preoccuparti di mostrare all'utente un messaggio di errore. Non ha senso, dal momento che il 90% degli utenti non si preoccuperà di ciò che dice.

D'altra parte, se in realtà PUOI mostrare all'utente un'utile soluzione, allora un modo per costringerlo a leggere è rendere il pulsante OK abilitato dopo circa 10 secondi. Ordinamento di come fa Firefox ogni volta che si tenta di installare un nuovo plug-in.

Se si tratta di un arresto anomalo totale dal quale non è possibile eseguire il ripristino con garbo, informare l'utente in termini molto profani dicendo:

" Mi dispiace che abbiamo sbagliato, vorremmo inviare alcune informazioni su questo incidente, ci permettete di farlo? SÌ / NO "

Inoltre, cerca di non prolungare i messaggi di errore di una frase. Quando le persone (me compreso) vedono un intero paragrafo che parla dell'errore, la mia mente si spegne.

Con così tanti social media e sovraccarico di informazioni, la mente delle persone si congela quando vedono un muro di testo.

MODIFICARE:

Qualcuno una volta ha anche suggerito di usare fumetti insieme a qualsiasi messaggio tu voglia mostrare. Come qualcosa di Dilbert che potrebbe essere vicino al tipo di errore che potresti avere.

Dalla mia esperienza: non hai gli utenti (soprattutto quelli non tecnici) per leggere i messaggi di errore. Non importa quanto sia chiaro e comprensibile, in grassetto, rosso e lampeggiante il messaggio, che visualizzi, la maggior parte degli utenti farà semplicemente clic su qualsiasi cosa a cui non sono abituati, anche se è "Vuoi davvero eliminare tutto?". Ho visto gli utenti fare clic sulla "finestra di chiusura" -icon invece di "OK" o "annulla" anche se non sapevano nemmeno quale opzione hanno scelto facendo così ...

Se hai davvero bisogno di forzare gli utenti a leggere ciò che stai visualizzando, ti suggerirei un conto alla rovescia JavaScript fino a quando un pulsante è cliccabile. In questo modo l'utente spera di usare il tempo di attesa per leggere davvero ciò che dovrebbe. Attenzione però: la maggior parte degli utenti ne sarà ancora più infastidita :)

Mi piace inoltre la tua idea di un link "leggi di più", anche se dubito che attirerà maggiormente gli utenti che vogliono semplicemente eliminare il messaggio in ogni modo ...

Solo per la cronaca: ci sono utenti che leggono i messaggi di errore ma hanno così paura di non farci nulla. Una volta ho ricevuto una chiamata di supporto in cui il cliente mi leggeva un messaggio di errore, chiedendomi cosa avrebbe dovuto fare. "Bene, quali sono le tue opzioni?", Ho chiesto. "La finestra ha solo un pulsante" OK ".", Rispose. ... mmh, difficile :)

Visualizzo spesso l'errore in rosso (quando il design lo consente).

Il rosso indica "avviso", ecc. Quindi viene letto più spesso.

Bene, per rispondere direttamente alla tua domanda: non lasciare che i tuoi programmatori scrivano i tuoi messaggi di errore. Se segui questo consiglio, risparmierai, cumulativamente, migliaia di ore di angoscia e produttività degli utenti e milioni di dollari in costi di supporto tecnico.

Il vero obiettivo, tuttavia, dovrebbe essere quello di progettare la tua applicazione in modo che gli utenti non possano commettere errori. Non lasciare che intraprendano azioni che portano a massaggi con errori e che richiedono il backup. Ad esempio, in un modulo Web che richiede la compilazione di tutti i suoi campi, invece di visualizzare un messaggio di errore quando gli utenti fanno clic sul pulsante Invia, non abilitare il pulsante Invia fino a quando tutto il campo non contenga contenuto valido. Significa più lavoro sul retro, ma si traduce in una migliore esperienza utente.

Certo, è un po 'un mondo ideale. A volte, gli errori del programma sono inevitabili. Quando si verificano, è necessario fornire informazioni chiare, complete e utili e, soprattutto, non esporre il sistema all'utente e non incolpare gli utenti per le loro azioni.

Un buon messaggio di errore dovrebbe contenere:

1. Qual è il problema e perché è successo.
2. Come risolvere il problema

Una delle cose peggiori che puoi fare è semplicemente trasmettere i messaggi di errore di sistema agli utenti. Ad esempio, quando il tuo programma Java genera un'eccezione, non passare semplicemente il programmatore all'interfaccia utente ed esporlo all'utente. Catturalo e crea un messaggio chiaro creato dallo sviluppatore dell'assistenza utente che puoi presentare al tuo utente.

Ho avuto la fortuna, nel mio ultimo lavoro, di lavorare con un team di programmatori che non avrebbe pensato di scrivere i propri messaggi di errore. Ogni volta che si trovavano in una situazione in cui era richiesto e il programma non poteva essere progettato per evitarlo (spesso a causa di risorse limitate), venivano sempre da me, mi spiegavano di cosa avevano bisogno e mi lasciavano creare un messaggio di errore che era chiaro e seguiva lo stile dell'azienda. Se quella fosse la mentalità predefinita di ogni programmatore, il mondo dell'informatica sarebbe un posto molto, molto migliore.

Meno errori

Se un'applicazione ti vomita regolarmente, diventi immune ad esso e gli errori diventano irritanti in background muzak. Se un errore è un evento raro, attirerà più attenzione.

Elimina tutto ciò che non è un grosso problema, elimina tutti quegli avvisi, trova il modo di comprendere l'intenzione dell'utente, prendi le decisioni ovunque possibile. Ho alcune app che continuo a ottimizzare in questo modo. Gli sviluppatori considerano ogni errore importante, ma ciò non è vero dal punto di vista dell'utente. Cercare risposta comune degli utenti di un problema e di acquisizione che, distribuire che, come la vostra risposta.

Se è necessario generare un errore: fattore di terrore breve, conciso, basso, senza punti esclamativi. I paragrafi non riescono .

Non esiste un proiettile d'argento, ma è necessario progettare socialmente per rendere importanti gli errori.

Abbiamo detto agli utenti che il loro manager era stato contattato (che era una bugia). Ha funzionato un po 'troppo bene e ha dovuto essere rimosso.

L'aggiunta di un pulsante "Avanzate" che abilita alcuni dettagli più tecnici fornirà un incentivo a leggerlo per la parte del pubblico target che si ritiene tecnico

Ti suggerirei di dare un feedback (affermando che l'utente ha commesso un errore) immediatamente dopo aver commesso l'errore. (Ad esempio, quando si inserisce un valore di un campo data, controllare il valore e, se è errato, rendere il campo di input visivamente diverso).

Se ci sono errori sulla pagina (sono più interessato allo sviluppo web, quindi mi riferisco ad esso come una "pagina", ma può anche essere chiamato "modulo"), mostra un "riepilogo degli errori", spiegando che lì erano errori e un elenco puntato di quali errori si sono verificati esattamente. Tuttavia, se ci sono più di 5-6 parole per messaggio, queste non verranno lette / comprese.

Che ne dici di rendere lo stato del pulsante "Fai clic qui per parlare con un tecnico dell'assistenza che ti assisterà in questo problema."

Esistono molti siti Web che offrono la possibilità di parlare con una persona reale.

Ho letto un candidato per la soluzione più orribile su slashdot:

Abbiamo scoperto che l'unico modo per far sì che gli utenti si assumano la responsabilità degli errori è quello di dare loro una penalità per aver forzato l'errore a scomparire. Per i principianti, laddove possibile, l'errore non si chiuderà effettivamente per loro a meno che non immettiamo una password amministratore per farla sparire e se si riavvia per sbarazzarsene (Task Manager è disabilitato su tutti i PC client) la macchina non aprirà il applicazione che si è arrestata in modo anomalo per 15 minuti. Naturalmente, tutto dipende dal tipo di utenti con cui hai a che fare, poiché gli utenti più tecnicamente competenti non accetterebbero questo tipo di sistema, ma dopo aver provato letteralmente ANNI per far sì che gli utenti si assumano la responsabilità degli arresti anomali e assicurandosi che il reparto IT sia a conoscenza per risolvere il problema prima che diventi troppo difficile da gestire, questi sono gli unici passaggi che hanno funzionato. Adesso,

"ATTENZIONE! ATTENZIONE! Se non leggi il messaggio di errore TU MORRERAI!"

Nonostante tutti i consigli nella risposta accettata, i miei utenti hanno continuato a fare clic sul primo pulsante che potevano trovare. Quindi ora mostro questo:

L'utente deve fare una scelta prima che appaia il pulsante OK

Se seleziona la terza opzione, può continuare, altrimenti l'applicazione si chiude.