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

https://stackoverflow.com/questions/2356698

23-09-2019
|

Pergunta

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

Então, estou me perguntando quais boas práticas você pode recomendar para ajudar os usuários a realmente lerem sua mensagem de erro, em vez de simplesmente dispensá-la.As ideias que consigo pensar seriam mais ou menos assim:

A formatação, claro, ajuda;talvez uma mensagem simples e curta, com um botão "saiba mais" que leva a uma mensagem de erro mais longa e detalhada
Faça com que todas as mensagens de erro sejam vinculadas a alguma seção do guia do usuário (um pouco difícil de conseguir)
Apenas não emita mensagens de erro, simplesmente recuse-se a executar a tarefa (uma forma um tanto "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 uma comunidade restrita).Uma forma mais genérica desta pergunta foi feita em barra, então você pode querer confira lá para algumas das respostas.

Solução

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

Não coloque mensagens de erro na barra de status - eles nunca as lerão, apesar de terem sido incrementadas com cores, etc.... eles 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 seu lançamento, a MS realizou um experimento para ler a interface do usuário (Ed - deve-se notar que a mensagem explicitamente declarada no contexto de 'Olhe embaixo da cadeira'), com uma nota de US$ 100 colada na parte de baixo da cadeira em que os participantes estavam sentados... ninguém viu a mensagem na barra de status!
Faça 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á exageradamente...
Não importa o quanto você tente, não use cores para identificar a mensagem... psicologicamente, é o mesmo que agitar uma bandeira vermelha para o touro!
Use palavras que soem 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 neutra 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 é trabalhar no meio do software ser bombardeado com mensagens popup, eles ficarão frustrados e serão desligados 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, isso é complicado de transmitir... você não quer que eles pensem que haverá ser 'problemas' ou 'falhas' e o que fazer no caso disso...eles não devem saber que haverá possíveis erros, realmente complicados.
Sempre, sempre, não tenha medo de pedir feedback quando algo sem intercorrências acontecer - como 'Quando aquele número de erro 1304 apareceu, como você reagiu?Qual foi a sua interpretação' - o bônus é que o usuário final pode lhe dar uma explicação mais coerente em vez de 'Erro 1304, objeto de banco de dados perdido!', em vez disso, ele pode dizer 'Cliquei nisso, então e então, alguém puxou acidentalmente o cabo de rede da máquina', isso lhe dará uma dica sobre como lidar com isso e poderá modificar o erro para dizer 'Opa, conexão de rede desconectada'...você entende a tendência.
Por último, mas não menos importante, se quiser atingir públicos internacionais, tenha em conta a internacionalização das mensagens de erro - por isso é que deve mantê-las neutras, porque assim será mais fácil traduzir, evitar sinónimos, gírias, etc., o que tornaria a tradução sem sentido - por exemplo, ~~Fiat~~ Ford, a empresa automobilística estava vendendo sua marca ~~Fiat~~ Ford Pinto, mas notei que não havia vendas na América do Sul, descobriu-se que Pinto era uma gíria para 'pênis pequeno' e, portanto, não havia vendas...
(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 dos erros na ordem correta com uma declaração ou duas sobre como proceder...
(Ed) Graças a Victor Hurdugaci pela sua contribuição, mantenha as mensagens educadas, não faça os usuários finais se sentirem estúpidos.Isto vai contra a resposta de Jack Marchetti se a base de usuários for internacional...

Editar: Uma palavra especial de agradecimento a roedor que também mencionou outro ponto extremamente vital!

Permita que o usuário final seja capaz de selecionar/copiar a mensagem de erro para que possa, se desejar, enviar um e-mail para a equipe de suporte de ajuda ou equipe de desenvolvimento.

Edição nº 2: Meu erro!Opa, obrigado DanM quem falou isso do carro, confundi o nome, era Ford Pinto...que pena...

Edição nº 3: Destacado por Ed para indicar adicionais ou adendos e creditados a outros por suas contribuições...

Edição nº 4: Em resposta ao comentário de Ken - aqui está minha opinião...Não, não é, use cores neutras padrão do Windows... não opte por cores chamativas!Atenha-se à cor de fundo cinza normal com texto em preto, que é uma diretriz GUI padrão normal nas especificações da Microsoft. Diretrizes de experiência do usuário (Ed).

Se você insiste em cores chamativas, pelo menos leve em consideração os possíveis usuários daltônicos, ou seja, acessibilidade, que é outro fator importante para aqueles que têm deficiência, mensagens de erro fáceis de ampliar a tela, daltonismo, aqueles que sofrem de albinos, podem ser sensíveis a cores chamativas e também para epilépticos...que podem sofrer de uma cor específica que pode desencadear uma convulsão ...

Outras dicas

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

Forneça uma boa maneira de permitir que eles enviem e -mails ou envie o log para você, para que você possa ajudá -los a reconciliar o problema. Se for um aplicativo da Web: melhor ainda, você pode receber informações sobre a situação à frente de qualquer pessoa, mesmo relatando 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 leem nas telas de computador, digitalizam e foram treinadas para clicar nos botões até que as caixas de diálogo desapareçam.

Colocamos um gráfico memorável simples na caixa de erro: não é um ícone, um bitmap bastante grande e nada como os ícones da mensagem do Windows padrão. Ninguém se lembra da redação de uma caixa de mensagem (a maioria nem a lê se a caixa tiver um botão "OK" que eles podem pressionar), mas a maioria das pessoas se lembra da imagem que viu. Então, nossas pessoas de apoio podem perguntar ao cliente "Você viu o cara que bebe café?" ou "Você viu a mesa vazia?". Pelo menos dessa maneira, sabemos aproximadamente o que deu errado.

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

Por exemplo, escrevi um aplicativo que permitiu nosso Hr As pessoas para rastrear melhor as datas de aluguel/incêndio dos funcionários. [Nós éramos uma pequena empresa, muito descontraída].

Quando eles entraram em datas erradas, eu escrevia:

Ei idiota, aprenda a entrar em uma data!

EDIT: É claro que uma mensagem mais útil é dizer: "Entre na data como MM/DD/AAYYY" ou talvez no código para tentar descobrir o que eles entraram e se eles entraram "Blahblah" para mostrar um erro. No entanto, essa foi uma aplicação muito pequena para uma pessoa de RH que eu conhecia pessoalmente. Portanto, novamente, as pessoas, leia a primeira linha deste post: Dependendo da sua base de usuários ...

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

A maior parte da arte antes do período barroco não foi assinada. No entanto, estamos além do período barroco agora, para que todos os campos devem ser concluídos.

Basicamente, volte para o seu público, se possível, e evite entediar, pois todos os erros gerais sobrenaturais, como: "Por favor, digite email" ou "Insira o email válido".

Alertas/pop -ups são irritantes, é por isso que todos acertam o primeiro botão que vêem.

Faça menos chato. Exemplo: se o usuário inseriu a data incorretamente ou inseriu um texto em que os números são esperados, então NÃO Pop -up 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 mensagem padrão do sistema, por exemplo, as caixas de mensagens do Windows XP estão se irritando. 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 lê -lo, isso é muito irritante. Se você pode fazer com que a caixa de mensagem apareça como uma mensagem de aviso, seria melhor, por exemplo, as mensagens de transbordamento de empilhamento que aparecem bem na parte superior da página, informando, mas não irritantes.

ATUALIZAR
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 mostrará uma mensagem de erro. O software deve se adaptar ao usuário. Com esse tipo de design, uma mensagem de erro será nova e chamará a atenção dos usuários. Se você apimentar o usuário com diálogos sem sentido como esse está treinando explicitamente para ignorar suas mensagens.

Na minha opinião e experiência, são os usuários do poder, que não leem mensagens de erro. O público não técnico que conheço lê todas as mensagens na tela com mais cuidado e o problema neste momento é: eles não entendem.

Este ponto pode ser a causa da sua experiência, porque em algum momento eles pararão de lê -los, porque "eles não entendem de qualquer maneira", então 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 Snapshot não permitida: Controle Arquivo Recém-criado Causa: Uma tentativa de invocar CFILEMAKEANDUSESNAPSHOT com um arquivo de controle atualmente montado que foi criado recentemente com o Create ControlFile. Ação: Monte um arquivo de controle atual e tente novamente a operação.

Para algo como:

Esta etapa não pôde ser processada devido a problemas momentâneos com o banco de dados. Entre em contato com (seu administrador | o helpdesk | Qualquer pessoa que possa entrar em contato com o desenvolvedor ou o administrador para resolver o problema). Desculpe pela inconveniência.

Mostre aos usuários que o erro Mensagem tem um significado, e é uma maneira de prestar assistência a eles E eles vão ler. Se for apenas uma mensagem sem sentido em jargão ou genérico, eles aprenderão a descartá-los quicemente.

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

Esta também é uma ótima ferramenta de aprendizado. Em versões futuras, você pode resolver-se-edições conhecidas ou pelo menos fornecer informações alternativas no local. Até então, os usuários aprenderão que essa mensagem é causada por X e o problema pode resolver por Y - tudo porque alguém explicou a eles.

É claro que isso não funcionará em um aplicativo em larga escala, mas funciona muito bem em aplicativos corporativos com poucas centenas de usuários e, em um ágil enxuto, libere o lançamento antecipado com frequência, ambiente.

EDITAR:

Como você tem uma ampla base de usuários, recomendo fornecer software que faça o que os usuários são/podem esperar que faça, por exemplo. Não mostre -lhes a mensagem de Eroror se o número de telefone não for bem formatado, reformate se para eles.

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

É um conhecimento comum que As pessoas não leem documentação (Você leu as instruções consecutivas quando você conectou o eletrodoméstico?), Eles tentam uma maneira de obter resultados rapidamente, quando falhou que você precisa chamar a atenção deles (por exemplo, desative o botão padrão por um tempo) com significativo e útil Info. Eles não se importam com a falha do seu software, eles querem obter resultados agora.

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

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

Além disso, seja curto 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. Se não for fornecer uma rota padrão, isso deve ser tomado.

Se o seu aplicativo for um aplicativo da Web, projetar páginas de erro personalizadas é uma boa ideia. Eles enfatizam menos os usuários, tomem isso por exemplo. Você pode ter algumas idéias como projetar uma boa página de erro aqui: http://www.smingmagazine.com/2007/07/25/wanted-your-404-error-pages/

Uma coisa que eu gostaria de acrescentar.

Use verbos para seus botões de ação para fechar suas mensagens de erro em vez de exclamações, 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 tamanho do tamanho, mas no sentido da importância. Deixe-me explicar.

Você deve escrever as coisas mais importantes a ler, primeiro e fornecer informações mais detalhadas em segundo.

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, mude 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 tem uma idéia sobre o que está sendo solicitado.

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

A menos que você possa fornecer ao usuário um trabalho simples, não se preocupe em mostrar ao usuário uma mensagem de erro. Não há sentido, já que 90% dos usuários não se importam com o que diz.

Por outro lado, se você POSSO Na verdade, mostre ao usuário uma solução alternativa útil, então uma maneira de forçá -los a lê -lo é fazer com que o botão OK seja ativado após 10 segundos ou mais. Mais ou menos 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 graciosamente, informe o usuário em termos muito leigos dizendo:

"Sinto muito por estragar tudo, gostaríamos de enviar algumas informações sobre esse acidente, você nos permitirá fazê -lo? SIM NÃO"

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

Com tantas mídias sociais e sobrecarga de informações, a mente das pessoas congelou quando vê uma parede de texto.

EDITAR:

Alguém também sugeriu recentemente o uso de histórias em quadrinhos, juntamente com a mensagem que você deseja mostrar. Como algo de Dilbert Isso pode estar próximo do tipo de erro que você pode ter.

Da minha experiência:você não fazer com que os usuários (especialmente os não técnicos) leiam mensagens de erro.Não importa o quão clara e compreensível, em negrito, vermelho e piscante seja a mensagem que você exibe, a maioria dos usuários simplesmente clicará em qualquer coisa com a qual não estão acostumados, mesmo que seja "Você realmente deseja excluir tudo?".Já vi usuários clicarem no ícone "fechar janela" em vez de "OK" ou "cancelar", embora nem soubessem qual opção escolheram ao fazer isso ...

Se você realmente precisa forçar os usuários a lerem o que você está exibindo, sugiro uma contagem regressiva de JavaScript até que um botão seja clicável.Dessa forma, espera-se que o usuário use 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 ideia de um link "leia mais", embora duvide que isso desperte mais interesse dos usuários que desejam apenas se livrar da mensagem por todos os meios ...

Apenas para constar:existem usuários que leem 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 deveria fazer."Bem, quais são suas opções?", perguntei."A janela só tem um botão 'OK'.", ele respondeu....mmh, difícil :)

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

O Red significa "Alert", etc., então é mais frequentemente lido.

Bem, para responder diretamente à sua pergunta: não faça com que seus programadores escrevam suas mensagens de erro. Se você seguir esse conselho, economizaria, cumulativamente, milhares de horas de angústia do usuário e produtividade 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 deixe que eles tomem ações que levam a massagens de erros e exigem que elas voltem para o 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 clicarem no botão Enviar, não habilite 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, isso é um mundo ideal. Às vezes, os erros do programa são inevitáveis. Quando eles ocorrem, você precisa fornecer informações claras, completas e úteis e, o mais importante, não exponha o sistema ao usuário e não culpe os usuários por suas ações.

Uma boa mensagem de erro deve conter:

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

Uma das piores coisas que você pode fazer é simplesmente passar as mensagens de erro do sistema para os usuários. Por exemplo, quando o seu programa Java lançar uma exceção, não simplesmente passe o programador-ese para a interface do usuário e exponha-o ao usuário. Pegue -o e tenha uma mensagem clara criada pelo seu desenvolvedor de assistência ao usuário que você pode apresentar ao seu usuário.

Eu tive a sorte de trabalhar com uma equipe de programador que não pensaria em escrever suas próprias mensagens de erro. Sempre que eles se encontraram em uma situação em que era necessário e o programa não pôde ser projetado para evitá -lo (geralmente por causa de recursos limitados), eles sempre vieram a mim, explicaram o que precisavam e me permitam criar uma mensagem de erro que estava 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 regularmente, você se torna imune a ele e os erros se tornam muzak de fundo irritante. Se um erro for um evento raro, ele receberá mais atenção.

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

Se você precisar levantar um erro: fator terrorista curto, conciso e baixo, sem marcas de exclamação. Os parágrafos são falhou.

Não há bala de prata, mas você precisa projetar socialmente para tornar os erros importantes.

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

Adicionar um botão "avançado" que permite alguns detalhes mais 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ê feedback (afirmando que o usuário cometeu um erro) imediatamente após o cometimento do erro. (Por exemplo, ao inserir um 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 (eu gosto mais de desenvolvimento da web, portanto, estou me referindo a ela como uma "página", mas também pode ser chamada de "forma"), mostre um "resumo do erro", explicando que lá foram erros e uma lista de marcadores do que exatamente os erros aconteceram. No entanto, se houver mais de 5-6 palavras por mensagem, elas não serão lidas/compreendidas.

Que tal fazer o botão declarar "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 os usuários assumirem a responsabilidade por erros é dar a eles uma penalidade por forçar o erro a desaparecer. Para iniciantes, sempre que possível, o erro não se fecha para eles, a menos que digamos uma senha de administrador para fazê -la desaparecer 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 Aplicação que caiu por 15 minutos. Obviamente, tudo isso depende do tipo de usuário com o qual você está lidando, pois os usuários mais técnicos tecnicamente não aceitariam esse tipo de sistema, mas depois de tentar literalmente anos para fazer os usuários assumirem a responsabilidade por falhas e garantir que o departamento de TI esteja ciente de Para corrigir o problema antes que fique muito difícil de gerenciar, essas são as únicas etapas que funcionaram. Agora, todos os nossos usuários finais estão cientes de que, se ignorarem erros, eles vão sofrer por eles mesmos.

"Atenção! Atenção! Se você não leu a mensagem de erro, morrerá!"

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

Read this!

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

Chose the correct option

Se ele selecionar a terceira opção, poderá continuar, caso contrário, o aplicativo é desistido.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow