Come convincere gli utenti a leggere i messaggi di errore?


177

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.


12
wiki della comunità ....
jldupont

3
A quale pubblico rivolgi il tuo software? Per esempio. poche aziende o utenti di Internet? C'è una relazione che puoi stabilire con gli utenti?
Janusz Skonieczny,

@WooYek: Sarebbe (nel mio caso) una base di utenti piuttosto ampia, ma con un tempo di utilizzo limitato (ovvero non è un software che usi così spesso, è più un "uso occasionale" con una base di utenti molto ampia).
F'x

@MikeJ Forse è la stessa persona che pubblica la domanda su più siti?
settimane

7
Ero al laboratorio di informatica al college. Qualcuno si è seduto accanto a me e ha provato ad accedere. Su è arrivato il messaggio di errore: "Password errata. Verifica che non sia attivato il blocco maiuscole". La congedò senza leggere e riprovò. Parecchie volte. Quando mi ha chiesto aiuto, le ho appena detto di leggere il messaggio.
TRiG

Risposte:


70

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 ...


1
Interessante sulla barra di stato. Direi che le persone fanno preavviso quelle dai colori vivaci strisce nella parte superiore di una pagina web che indicano, ad esempio, "che hai appena guadagnato un buon distintivo risposta." Questo non equivale alla barra di stato, ma mi dice che la posizione e il colore di sfondo di un messaggio di errore sono fattori significativi. Oh, e una piccola nota ortografica: è Fiat Punto. Pinto era un prodotto Ford famoso per il suo serbatoio di gas montato sul retro che a volte esplodeva.
Eviterei

@DanM: Accidenti! hai ragione! Era guado ... cosa stavo pensando quando ho scritto la risposta ... sì, era Ford Pinto !!! Grazie per il testa a testa!!!
t0mm13b

@ Tommy, non dimenticare Nova (come in Chevy Nova). Si traduce in "No Go" o "Doesn't Go" in spagnolo :-P
devuxer

2
@DanM: corretto quello - ehi è interessante .... ahi! Sembra una macchina di legno con ruote di legno che vanno di legno .... :)
t0mm13b

Grazie per la bella risposta!
F'x

16

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.


2
Un grande +1 per questo. Si noti che la parte sviluppatore può contenere la traccia dello stack completo e altri dettagli. Se lo desideri, puoi anche catturare schermate dell'applicazione (in particolare per le app WinForms interne).
TrueWill

Sono un po 'riluttante a considerare "catturare schermate di applicazioni" un buon consiglio: dopo tutto, sembra una grave perdita di dati privati ​​(anche se la tua applicazione non è mai stata progettata per gestire le informazioni di classe A <nogrep> NS in primo luogo ) ...
F'x

Penso che sia più una decisione aziendale / politica che deve essere gestita dagli utenti del dominio che gli aspetti tecnici di fornire un supporto migliore avendo il supporto diagnostico di crash "scatola nera". Mi aspetto che le app LOB interne presentino preoccupazioni / obiettivi diversi rispetto alle relazioni di supporto client esterno con informazioni riservate.
MikeJ

11

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.


Quell'abitudine di fare clic sulle finestre di dialogo era un vero problema con la vecchia finestra di installazione di IE ActiveX.
Alex Jasmin

10

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.


1
Il mio problema con questa idea è che rompe l'uniformità dell'interfaccia utente che le persone si aspettano. Inoltre, come possono sapere che la "scrivania vuota" è un problema più minaccioso del "ragazzo che beve caffè"?
F'x

Realizziamo sistemi monouso (centri di controllo di emergenza), quindi ci preoccupiamo solo dell'uniformità dell'interfaccia utente all'interno di quel sistema. Nessuna gerarchia di minaccia è implicita qui comunque. Lo scopo è semplicemente quello di essere memorabili. Queste due grafiche rappresentano in realtà situazioni di inattività simili (l'operatore si è allontanato dalla scrivania, l'operatore probabilmente è in pausa), quindi sarebbero significativi ... ma non è questo il loro vero scopo. Vogliamo solo che siano memorabili. Forse non dovrei menzionare il topo che balla :-).
Bob Moore

10

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".


Mi ricorda il "suggerimento" nella parola MS - Correre con le forbici può essere pericoloso
MikeJ

7
scopri come inserire una data !! - Sicuro ma dammi un indizio. Non dovrei indovinare il formato corretto.
Alex Jasmin

4
+1 per il messaggio barocco, sono sempre intrattenuto da questo tipo di creatività :)
medopal

2
Non sono sicuro che mi piaccia molto quel tipo di messaggio ... Dopo tutto, perché dovrei imparare come inserire una data?
F'x

1
Invece di richiedere agli utenti di capire il formato della data, prenditi un paio di minuti in più e insegna al tuo software come analizzare le date in più formati. Il computer è intelligente: lascia che aiuti l'utente anziché schiaffeggiargli i polsi.
Bryan Oakley,

10

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".


1
1 e 3 sono buoni. 2 è discutibile, per motivi di accessibilità. I controlli standard di sistema possono essere gestiti in modo speciale. Le tue varianti non possono.
Phil Miller

1
@Novelocrat, le probabilità sono buone che se il resto dell'applicazione è accessibile, lo sarà anche la finestra di dialogo di errore personalizzata. E se il resto della tua applicazione ha già problemi di accessibilità, un'altra finestra di dialogo con problemi non avrà importanza.
Mike Daniels

@Novelocrat, sto parlando principalmente di applicazioni Web, invece della casella di avviso JavaScript predefinita, puoi creare una nuova scatola elegante e dargli le stesse proprietà. Ma la stessa idea potrebbe
valere

Come Novelocrat, non mi piace molto la parte "non usare mai l'interfaccia utente del sistema" della risposta. Le persone vogliono sentirsi in un territorio noto.
F'x

Inoltre, l'accessibilità è sempre migliore per l'interfaccia utente del sistema.
F'x

8

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.


6

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.


2
E poi admin / helpdesk / etc sentono parlare del messaggio e chiedono "Che diavolo dovrei fare al riguardo?". Il tuo secondo messaggio è generico fino al punto di inutilità. Per quanto riguarda il primo, non avendo mai usato il software Oracle (indovinare basato sul prefisso), posso ancora ipotizzare cosa dovrei fare al riguardo.
Phil Miller

Bene, l'helpdesk può informare lo sviluppatore per risolvere il problema. Aiuterebbe il cliente o l'helpdesk a scrivere il messaggio tecnico nell'errore? Tutto ciò che l'utente vuole sapere a questo punto è: cosa è successo e dove posso ottenere aiuto, se non è un errore che ha commesso (input errato o qualcosa del genere). E non fraintendetemi, questo è ovviamente il messaggio sul livello di presentazione. Nei registri del server è presente il messaggio di errore specifico che ti aiuterà a risolverlo.
bl4ckb0l7

1
@Novelocrat, appunto. Spesso puoi trovare personale di supporto tecnico che urla "Ma io sono l'amministratore di sistema e non ho f * @ # e indizio qual è il problema!" Faresti meglio ad aggiungere ai tuoi errori un'opzione "mostrami la tecnobabble".
Mike Daniels

l'helpdesk non può fornire molto aiuto quando si tratta di un'applicazione commerciale standard e l'errore non contiene informazioni utili.
Mike Daniels

5

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.



2

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/


2

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.


1
Alcune piattaforme non ti consentono di farlo. Ci sono anche buone ragioni per queste restrizioni.
Phil Miller

Secondo fortemente il commento di Novelocrat. Un'interfaccia utente standardizzata va bene per gli utenti (e quindi per te). Penso che attenersi alle etichette dei pulsanti standard raggiunga qualcosa che non si vuole perdere, anche per catturare l'attenzione (tranne forse in casi straordinari).
F'x

Non è necessario utilizzare gli avvisi JS () per visualizzare i messaggi di errore. Puoi costruire la tua finestra di dialogo. Anche lo scopo di usare i verbi piuttosto che solo le esclamazioni è perché se vedi 'Ok' come pulsante, dovrai leggere il contenuto della finestra di dialogo. Il problema è che alcuni utenti non si prenderanno il tempo per farlo, quindi faranno semplicemente clic su OK. Se usi i verbi per descrivere l'azione, un utente saprà cosa sta succedendo senza leggere la finestra di dialogo.
Segna il

Chiudere è un verbo. L'hai usato nella tua frase; "per chiudere i messaggi di errore"
Ricket,

Ma @Mark, questa domanda riguarda il lasciarli leggere: p
Bart van Heukelom,

2

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.


2

Vedi anche le risposte degli utenti di Slashdot qui .


2

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.


1
Puoi cercare un cartone animato Dilbert qui: bfmartin.ca/finder
SLaks

Dieci secondi? Guarda un orologio e conta dieci secondi. È un'eternità quando stai cercando di fare un dannato lavoro.
Mike Daniels

1
Mike, doveva essere un esempio, non scritto in pietra. Scegli il timeout desiderato. In alternativa, hai mai installato un adon di Firefox? Questo conto alla rovescia ti infastidisce davvero così tanto? Non ho sentito troppe persone lamentarsene.
settimane

@Roberto - parlando del conto alla rovescia del plugin Firefox ... che mi infastidisce. Voglio solo fare clic su Installa. Perché ho bisogno di un conto alla rovescia quando ho fatto clic su Installa un plug-in e ora devo attendere 10 secondi per confermare l'installazione.
Segna il

1
@Mark proprio per il motivo per cui è stata posta questa domanda Stack Overflow. Troppe persone sono felici e non si preoccupano di leggere i messaggi e le loro conseguenze e finiscono per fare qualcosa che non volevano. Mark, sai e capisci su cosa fai clic. Tuttavia, avendo lavorato in passato con il supporto tecnico HP, ci sono persone là fuori che fanno clic sulle cose solo perché possono. Il ritardo costringe l'utente a fermarsi e dare un'occhiata al messaggio, piuttosto che dire "sì, sì, qualunque cosa farò clic su OK, vai già"
7wp

2

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 :)


11
Questo "conto alla rovescia JavaScript" è la cosa più fastidiosa che puoi fare. L'utente odia "dover attendere che un orologio inizi il conto alla rovescia" e si concentra a malapena sul testo dell'errore piuttosto che sulla sua rabbia.
bl4ckb0l7

2

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

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


3
e che dire delle persone daltoniche?
Natrium

1
Come qualcuno che è daltonico non sono nemmeno sicuro di come sia il colore "rosso".
MikeJ,

Il rosso non è universalmente interpretato come un avviso. Alcune culture lo interpretano come felicità, per esempio. Sii consapevole di chi sono i tuoi potenziali utenti quando scelgono i colori.
Bryan Oakley

1
@MikeJ: chiaramente, invece, Tyzak dovrebbe far lampeggiare. Sarebbe molto più utile. C'è una differenza di valore (luminosità) tra i campi che altri dicono "rossi" e quelli che dicono sono chiari, no?
Phil Miller

hm, non ho pensato al daltonico, questo è un buon punto. sì, il colore è interpretato universalmente (Cina, India). Dipende dal pubblico, giusto.
Tyzak

1

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.


1

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.


1

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.


1

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


0

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.


I tuoi due paragrafi sembrano contraddittori: dare un feedback immediato, ma raccoglierlo alla fine della pagina?
F'x

@FX, L'idea era che si fanno entrambe le cose- avvisare immediatamente l'utente, ma, dal momento che potrebbe ancora ignorarlo, raccogliere tutti gli errori alla fine della pagina.
naivisti

0

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.


Il punto è far sì che gli utenti gestiscano gli errori stessi, almeno dove possibile. Un tale pulsante sarebbe una dichiarazione di totale fallimento dell'intento.
Seether

0

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,


0

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


0

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:

Leggi questo!

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

Scegli l'opzione corretta

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

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.