Como fazer com que os usuários leiam mensagens de erro?

Se você programa para um público não técnico, corre o risco de os usuários não lerem suas mensagens de erro cuidadosamente redigidas e esclarecedoras, mas apenas clica no primeiro botão disponível com um encolher de ombros de frustração.

Então, estou pensando em quais boas práticas você pode recomendar para ajudar os usuários a realmente ler sua mensagem de erro, em vez de simplesmente renunciar a ela. As idéias em que eu consigo pensar se encaixam nas seguintes linhas:

• Formatação de ajuda do curso; talvez uma mensagem curta e simples, com um botão "saiba mais", que leva a uma mensagem de erro mais longa e detalhada
• Todas as mensagens de erro estão vinculadas a alguma seção do guia do usuário (um pouco difícil de alcançar)
• Apenas não emita mensagens de erro, simplesmente se recuse a executar a tarefa (uma maneira um pouco "Apple" de lidar com a entrada do usuário)

Editar: o público que tenho em mente é uma base de usuários bastante ampla que não usa o software com muita frequência e não é cativa (ou seja, nenhum software interno ou comunidade restrita). Uma forma mais genérica dessa pergunta foi feita no slashdot , portanto, você deve procurar aqui algumas respostas.

Essa é uma excelente pergunta digna de um +1 de mim. A questão, apesar de simples, abrange muitos aspectos da natureza dos usuários finais. Aqui tudo se resume a vários fatores que beneficiariam você e o próprio software e, é claro, para os usuários finais.

• Não coloque mensagens de erro na barra de status - elas nunca as lerão, apesar de terem cores vibrantes, etc ... sempre sentirão falta delas! Não importa o quanto você tente ... Em um estágio durante o teste da interface do usuário do Win 95 antes de ser lançado, a MS realizou um experimento para ler a interface do usuário ( ed - note-se que a mensagem declarada explicitamente no contexto de 'Olhe embaixo da cadeira' ), com uma nota de 100 dólares colada na parte inferior da cadeira em que os participantes estavam sentados ... ninguém viu a mensagem na barra de status!
• Torne as mensagens curtas, não use palavras intimidadoras, como 'Alerta: o sistema encontrou um problema', o usuário final apertará o botão de pânico e reagirá em excesso ...
• Não importa o quanto você tente, não use cores para identificar a mensagem ... psicologicamente, é como acenar uma bandeira vermelha para o touro!
• Use palavras neutras para transmitir uma reação mínima e como proceder!
• Talvez seja melhor mostrar uma caixa de diálogo listando a mensagem de erro neutro e incluir uma caixa de seleção indicando 'Deseja ver mais dessas mensagens de erro no futuro?', A última coisa que um usuário final deseja é estar trabalhando no meio do software a ser bombardeado com mensagens pop-up, eles ficarão frustrados e serão desativados pelo aplicativo! Se a caixa de seleção estiver marcada, registre-a em um arquivo ...
• Mantenha os usuários finais informados sobre quais mensagens de erro haverá ... o que implica ... treinamento e documentação ... agora é difícil de transmitir ... você não quer que eles pensem que haverá 'problemas' ou 'falhas' e o que fazer no caso disso ... eles não devem saber que haverá erros possíveis, de fato complicado.
• Sempre, sempre, não tenha medo de pedir feedback quando acontecer o sem intercorrências - como 'Quando esse erro número 1304 apareceu, como você reagiu? Qual foi a sua interpretação '- o bônus com isso, o usuário final poderá fornecer uma explicação mais coerente em vez de' Erro 1304, objeto de banco de dados perdido! ', Em vez disso, poderá dizer' cliquei sobre isso para e então, alguém puxou o cabo de rede da máquina acidentalmente ', isso indica que você precisa lidar com isso e pode modificar o erro para dizer' Opa, conexão de rede desconectada '... você entendeu.
• Por último, mas não menos importante, se você deseja atingir o público internacional, leve em consideração a internacionalização das mensagens de erro - por isso, mantenha-o neutro, pois será mais fácil traduzir, evitar sinônimos, gírias etc. a tradução sem sentido - por exemplo, a Fiat Ford, a empresa de automóveis que vendia sua marca Fiat Ford Pinto, mas percebeu que não estava acontecendo nenhuma venda na América do Sul; no final, Pinto era uma gíria para 'pênis pequeno' e, portanto, nenhuma venda ...
• ( ed ) Documente a lista de mensagens de erro esperadas em uma seção separada da documentação intitulada 'Mensagens de erro' ou 'Ações corretivas' ou similar, listando os números de erro na ordem correta com uma declaração ou duas sobre como proceder. ..
• ( ed ) Obrigado a Victor Hurdugaci por sua contribuição, mantenha as mensagens educadas, não faça com que os usuários finais se sintam estúpidos. Isso contraria a resposta de Jack Marchetti se a base de usuários for internacional ...

Edit: Uma palavra especial de agradecimento ao gnibbler que mencionou outro ponto extremamente vital também!

• Permita que o usuário final possa selecionar / copiar a mensagem de erro para que, se assim o desejarem, envie um email para a equipe de suporte de ajuda ou a equipe de desenvolvimento.

Editar # 2: Meu mal! Ops , graças ao DanM que mencionou isso sobre o carro, eu confundi o nome, era Ford Pinto ... meu mal ...

Edição nº 3: destaque por ed para indicar itens adicionais ou aditivos e creditados a outros por suas entradas ...

Editar # 4: Em resposta ao comentário de Ken - eis a minha opinião ... Não, não é, use cores neutras padrão do Windows ... não use cores chamativas! Atenha-se à cor de fundo cinza normal com texto em preto, que é uma diretriz padrão da GUI normal nas especificações da Microsoft. Consulte as Diretrizes UX ( ed ).

Se você insiste em cores chamativas, pelo menos, leve em consideração os usuários potencialmente daltônicos, ou seja, a acessibilidade, que é outro fator importante para os portadores de deficiência, mensagens de erro amigáveis ​​à ampliação da tela, daltonismo, aqueles que sofrem com albinos, eles pode ser sensível a cores chamativas e epiléticos também ... que podem sofrer de determinadas cores que podem desencadear uma convulsão ...

Mostre a mensagem. Due dilligence e tudo, mas registre todos os erros em um arquivo. Os usuários não conseguem se lembrar do que estavam fazendo ou qual foi a mensagem de erro segundos após o evento, são como relatos de testemunhas oculares de criminosos.

Forneça uma boa maneira de permitir que eles enviem por email ou carreguem o log para você, para ajudá-los a reconciliar o problema. Se for um aplicativo da Web: melhor ainda, você pode receber informações sobre a situação antes de qualquer pessoa que relate o problema.

Resposta curta: você não pode.

Resposta menos curta: torne-os visíveis, relevantes e contextuais (destaque o que eles estragaram). Mas ainda assim, você está travando uma batalha perdida. As pessoas não lêem nas telas dos computadores, digitalizam e foram treinadas para clicar nos botões até as caixas de diálogo desaparecerem.

Colocamos um gráfico simples e memorável na caixa de erro: não um ícone, um bitmap razoavelmente grande e nada como os ícones de mensagens padrão do Windows. Ninguém consegue se lembrar do texto de uma caixa de mensagens (a maioria nem lê se a caixa tem um botão "OK" que pode ser pressionado), mas a maioria das pessoas se lembra da imagem que viu. Para que nosso pessoal de suporte possa perguntar ao cliente "você viu o cara que toma café?" ou "você viu a mesa vazia?". Pelo menos assim, sabemos aproximadamente o que deu errado.

Dependendo da sua base de usuários, escrever mensagens de erro engraçadas / rudes / pessoais pode funcionar muito bem.

Por exemplo, escrevi um aplicativo que permitia ao nosso pessoal de RH acompanhar melhor as datas de contratação / demissão de funcionários. [éramos uma empresa pequena, muito descontraída].

Quando eles digitavam datas erradas, eu escrevia:

Ei, idiota, aprenda a inserir uma data!

EDIT: É claro que uma mensagem mais útil é dizer: "Digite a data como mm / dd / aaaa" ou talvez no código para tentar descobrir o que eles inseriram e se eles digitaram "blahblah" para mostrar um erro. No entanto, essa era uma aplicação muito pequena para uma pessoa de RH que eu conhecia pessoalmente. Daí novamente pessoas, leia a primeira linha deste post: Dependendo da sua base de usuários ...

Recentemente, trabalhei em um projeto do Art Institute, para que as mensagens de erro fossem voltadas para o público, como:

A maior parte da arte antes do período barroco não era assinada. No entanto, estamos além do período barroco agora, portanto todos os campos devem ser preenchidos.

Basicamente, direcione-o para o seu público, se possível, e evite os chatos, como todos os erros gerais sobrenaturais, como: "insira o email" ou "insira o email válido".

Alertas / pop-ups são irritantes, é por isso que todo mundo pressiona o primeiro botão que vê.

Torne-o menos irritante . Exemplo: se o usuário digitou a data incorretamente ou digitou um texto em que os números são esperados, NÃO envie uma mensagem, basta destacar o campo e escrever uma mensagem em algum lugar ao seu redor.

Faça uma caixa de mensagem personalizada . Nunca use a caixa de mensagens padrão do sistema, por exemplo, as caixas de mensagens do Windows XP são irritantes. Faça uma nova caixa de mensagem colorida, com uma cor de fundo diferente do padrão do sistema.

Muito importante: não insista . Algumas caixas de mensagem usam a caixa de diálogo Modal e insistem em fazê-lo ler, isso é muito irritante. Se você pode fazer com que a caixa de mensagem apareça como uma mensagem de aviso, seria melhor, por exemplo, mensagens de estouro de pilha que apareçam na parte superior da página, informando, mas não irritando.

ATUALIZAÇÃO
Torne a mensagem significativa e útil . Por exemplo, não escreva algo como "Nenhum teclado encontrado, pressione F1 para continuar".

O melhor design da interface do usuário será onde você praticamente nunca mostra uma mensagem de erro. O software deve se adaptar ao usuário. Com esse tipo de design, uma mensagem de erro será nova e atrairá a atenção dos usuários. Se você apimentar o usuário com diálogos sem sentido como esse, você está explicitamente treinando-o para ignorar suas mensagens.

Na minha opinião e experiência, são os usuários avançados, que não lêem mensagens de erro. O público não técnico que conheço lê cada mensagem na tela com mais cuidado e o problema neste momento é principalmente: eles não entendem.

Esse ponto pode ser a causa de sua experiência, porque em algum momento eles deixarão de lê-los, porque "eles não o entendem", portanto, sua tarefa é fácil:

Torne a mensagem de erro o mais fácil de entender possível e mantenha a parte técnica sob o capô.

Por exemplo, transfiro uma mensagem como esta:

ORA-00237: operação de captura instantânea não permitida: arquivo de controle recém-criado Causa: Foi feita uma tentativa de chamar cfileMakeAndUseSnapshot com um arquivo de controle montado atualmente que foi criado recentemente com CREATE CONTROLFILE. Ação: Monte um arquivo de controle atual e tente novamente a operação.

para algo como:

Não foi possível processar esta etapa devido a problemas momentâneos no banco de dados. Entre em contato (seu administrador | o suporte técnico | qualquer pessoa que possa entrar em contato com o desenvolvedor ou administrador para resolver o problema). Desculpe pela inconveniência.

Mostre aos usuários que a mensagem de erro tem um significado e é uma maneira de fornecer assistência a eles e eles a lerão. Se for apenas uma mensagem de jargão ou bobagem genérica, eles aprenderão a descartá-los rapidamente.

Aprendi que é uma prática muito boa incluir uma caixa de diálogo de erro com ação padrão para enviar (por exemplo, por email) informações detalhadas de diagnóstico; se você responder rapidamente a esses emails com informações valiosas ou soluções alternativas, eles o adorarão.

Essa também é uma ótima ferramenta de aprendizado. Nas versões futuras, você pode resolver problemas conhecidos ou, pelo menos, fornecer informações alternativas sobre o local. Até lá, os usuários aprenderão que essa mensagem é causada por X e o problema pode ser resolvido por Y - tudo porque alguém lhes explicou.

Obviamente, isso não funcionará em um aplicativo de larga escala, mas funcionará muito bem em aplicativos corporativos com poucas centenas de usuários e, em um ambiente ágil, com liberação ágil e com liberação frequente.

EDITAR:

Como você possui uma ampla base de usuários, recomendo fornecer um software que faça o que os usuários são / podem esperar, por exemplo. não mostre a mensagem de erro se o número de telefone não estiver formatado corretamente, reformate se for para eles.

Pessoalmente, gosto de software que não me faz pensar e, quando ocasionalmente não há nada que você (o desenvolvedor) possa fazer para interpretar minha intenção, forneça mensagens muito bem escritas (e revisadas por usuários reais).

É do conhecimento comum que as pessoas não leem a documentação (você leu as instruções consecutivas quando você conectou o eletrodoméstico?), Elas tentam uma maneira de obter resultados rapidamente, quando falham, você precisa chamar a atenção delas (por exemplo, desativar o botão padrão por um tempo) com informações úteis e significativas . Eles não se preocupam com a falha do seu software, querem obter resultados agora.

Torne-os divertidos . (Pareceu relevante, dado o site em que estamos :))

Para começar, escreva mensagens de erro que os usuários possam realmente entender. "Erro: 1023" não é um bom exemplo. Eu acho que a melhor maneira é registrar o erro, do que mostrá-lo ao usuário com algum código "sofisticado". Ou, se o registro não for possível, forneça aos usuários a maneira correta de enviar os detalhes do erro ao departamento de suporte.

Além disso, seja breve e claro o suficiente. Não inclua alguns detalhes técnicos. Não mostre a eles informações que eles não podem usar. Se possível, forneça uma solução alternativa para o erro. Caso contrário, forneça uma rota padrão, isso deve ser seguido.

Se seu aplicativo for um aplicativo Web, é recomendável projetar páginas de erro personalizadas. Eles enfatizam menos os usuários, como o SO, por exemplo. Você pode obter algumas idéias sobre como criar uma boa página de erro aqui: http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/

Uma coisa que eu gostaria de acrescentar.

Use verbos nos botões de ação para fechar suas mensagens de erro em vez de exclamações. Por exemplo, não use "Ok!" "Fechar" etc.

Uma boa dica que aprendi é que você deve escrever uma caixa de diálogo como um artigo de jornal. Não no sentido do tamanho, mas no sentido da importância. Deixe-me explicar.

Você deve escrever as coisas mais importantes para ler primeiro e depois fornecer informações mais detalhadas.

Em outras palavras, isso não é bom:

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?

Em vez disso, altere a ordem:

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.

Dessa forma, o usuário pode ler o quanto quiser ou incomodar e ainda ter uma idéia do que está sendo solicitado.

Veja também as respostas dos usuários do Slashdot aqui .

A menos que você possa fornecer ao usuário algumas soluções simples, não se preocupe em mostrar ao usuário uma mensagem de erro. Simplesmente não faz sentido, já que 90% dos usuários não se importam com o que diz.

Por outro lado, se você PODE realmente mostrar ao usuário uma solução alternativa útil, uma maneira de forçá-lo a lê-lo é ativar o botão OK após 10 segundos ou mais. Classifica como o Firefox faz isso sempre que você está tentando instalar um novo plug-in.

Se for uma falha total da qual você não pode se recuperar normalmente, informe o usuário em termos muito leigos, dizendo:

" Desculpe-nos por termos estragado tudo, gostaríamos de enviar algumas informações sobre este acidente. Você nos permite fazer isso? SIM / NÃO "

Além disso, tente não tornar suas mensagens de erro mais longas que uma frase. Quando as pessoas (eu incluído) veem um parágrafo inteiro falando sobre o erro, minha mente simplesmente desliga.

Com tanta mídia social e sobrecarga de informações, a mente das pessoas congela quando vê uma parede de texto.

EDITAR:

Alguém também sugeriu recentemente usar histórias em quadrinhos junto com a mensagem que você deseja mostrar. Como algo de Dilbert que pode estar próximo ao tipo de erro que você pode ter.

Da minha experiência: você não faz com que os usuários (especialmente os não técnicos) leiam as mensagens de erro. Por mais clara e compreensível, em negrito, em vermelho e intermitente exibida, a maioria dos usuários clica em qualquer coisa a que não esteja acostumada, mesmo que seja "Deseja realmente apagar tudo?". Vi usuários clicarem no ícone "fechar janela" em vez de em "OK" ou "cancelar", mesmo sem saberem qual opção escolheram ao fazê-lo ...

Se você realmente precisar forçar os usuários a ler o que está exibindo, sugiro uma contagem regressiva de JavaScript até que um botão seja clicado. Dessa forma, o usuário esperançosamente usará o tempo de espera para realmente ler o que deveria. Porém, tenha cuidado: a maioria dos usuários ficará ainda mais irritada com isso :)

Além disso, gosto da sua idéia de um link "leia mais", embora eu duvide que os usuários se interessem mais e que queiram apenas se livrar da mensagem por todos os meios ...

Apenas para constar: existem usuários que lêem mensagens de erro, mas têm tanto medo de não fazer nada com isso. Certa vez, recebi uma ligação de suporte em que o cliente lia uma mensagem de erro para mim, perguntando o que ele deveria fazer. "Bem, quais são suas opções?", Perguntei. "A janela possui apenas um botão 'OK'.", Ele respondeu. ... mmh, difícil :)

Costumo exibir o erro em vermelho (quando o design permite).

Vermelho significa "alerta", etc., por isso é mais frequentemente lido.

Bem, para responder sua pergunta diretamente: Não deixe seus programadores escreverem suas mensagens de erro. Se você seguir este conselho, economizará, cumulativamente, milhares de horas de angústia e produtividade do usuário e milhões de dólares em custos de suporte técnico.

O objetivo real, no entanto, deve ser projetar seu aplicativo para que os usuários não possam cometer erros. Não permita que eles executem ações que levem a massagens de erro e exijam que eles façam backup. Como exemplo simples, em um formulário da Web que exige que todos os seus campos sejam preenchidos, em vez de exibir uma mensagem de erro quando os usuários clicam no botão Enviar, não ative o botão Enviar até que todo o campo contenha conteúdo válido. Isso significa mais trabalho na parte de trás, mas resulta em uma melhor experiência do usuário.

Claro, esse é um mundo ideal. Às vezes, os erros do programa são inevitáveis. Quando elas ocorrem, você precisa fornecer informações claras, completas e úteis e, o mais importante, não expõe o sistema ao usuário e não culpa os usuários por suas ações.

Uma boa mensagem de erro deve conter:

1. Qual é o problema e por que aconteceu.
2. Como resolver o problema.

Uma das piores coisas que você pode fazer é simplesmente transmitir mensagens de erro do sistema aos usuários. Por exemplo, quando seu programa Java lança uma exceção, não basta passar o programador para a interface do usuário e expô-lo ao usuário. Capture-o e tenha uma mensagem clara criada pelo desenvolvedor de assistência ao usuário que você pode apresentar ao usuário.

Tive a sorte de, no meu último emprego, trabalhar com uma equipe de programadores que não pensaria em escrever suas próprias mensagens de erro. Sempre que se encontravam em uma situação em que era necessário e o programa não podia ser projetado para evitá-lo (geralmente por causa de recursos limitados), eles sempre vinham a mim, explicavam o que precisavam e deixavam-me criar uma mensagem de erro que foi claro e seguiu o estilo da empresa. Se essa fosse a mentalidade padrão de todo programador, o mundo da computação seria um lugar muito, muito melhor.

Menos erros

Se um aplicativo lança vômito em você regularmente, você se torna imune a ele e os erros se tornam irritantes. Se um erro for um evento raro, ele atrairá mais atenção.

Escolha qualquer coisa que não seja importante, jogue fora todos esses avisos, encontre maneiras de entender a intenção do usuário, tome as decisões sempre que possível. Eu tenho alguns aplicativos que continuo otimizando dessa maneira. Os desenvolvedores veem todos os erros como importantes, mas isso não é verdade da perspectiva do usuário. Procure a resposta comum dos usuários a um problema e capture-o, implante-o como sua resposta.

Se você precisar gerar um erro: fator de terror curto, conciso e baixo, sem pontos de exclamação. Os parágrafos são falhos .

Não existe uma bala de prata, mas você precisa de engenharia social para cometer erros importantes.

Dissemos aos usuários que seu gerente havia sido contatado (o que era uma mentira). Funcionou um pouco bem demais e teve que ser removido.

Adicionar um botão "Avançado" que permita mais detalhes técnicos fornecerá um incentivo para lê-lo para a parte do público-alvo que se considera técnico

Eu sugiro que você dê um feedback (afirmando que o usuário cometeu um erro) imediatamente após o erro. (Por exemplo, ao inserir o valor de um campo de data, verifique o valor e, se estiver errado, torne o campo de entrada visualmente diferente).

Se houver erros na página (estou mais interessado no desenvolvimento da Web, por isso estou me referindo a ela como uma "página", mas também pode ser chamada de "formulário"), mostre um "resumo de erro", explicando que há foram erros e uma lista com marcadores do que exatamente ocorreram erros. No entanto, se houver mais de 5 a 6 palavras por mensagem, elas não serão lidas / compreendidas.

Que tal definir o botão "Clique aqui para falar com um técnico de suporte que o ajudará com esse problema".

Existem muitos sites que oferecem a opção de falar com uma pessoa real.

Eu li um candidato para a solução mais horrível no slashdot:

Descobrimos que a única maneira de fazer com que os usuários se responsabilizem por erros é aplicá-los a uma penalidade por forçar o erro a desaparecer. Para iniciantes, sempre que possível, o erro não será fechado para eles, a menos que insira uma senha de administrador para que ela desapareça e, se eles reiniciarem para se livrar dela (o Gerenciador de Tarefas está desativado em todos os PCs clientes), a máquina não abrirá o aplicativo que travou por 15 minutos. Obviamente, tudo isso depende do tipo de usuário com o qual você está lidando, já que usuários mais tecnicamente qualificados não aceitariam esse tipo de sistema, mas depois de tentar, literalmente, YEARS, fazer com que os usuários assumam a responsabilidade por falhas e garantir que o departamento de TI esteja ciente de para corrigir o problema antes que ele fique muito difícil de gerenciar, essas são as únicas etapas que funcionaram. Agora,

"ATENÇÃO! ATENÇÃO! Se você não ler a mensagem de erro, VAI MORRER!"

Apesar de todas as recomendações na resposta aceita, meus usuários continuaram a clicar no primeiro botão que encontraram. Então agora eu mostro isso:

O usuário deve fazer uma escolha antes que o botão OK apareça

Se ele selecionar a 3ª opção, ele poderá continuar, caso contrário, o aplicativo será encerrado.