Como faço para que os usuários leiam mensagens de erro?

Você sempre terá uma porcentagem significativa de usuários que ignora muitas ou todas as mensagens de erro. Mesmo quando ligam para o suporte, têm a mensagem de erro à frente e afirmam ter lido, eles podem muito bem ainda não ter assimilado o conteúdo da mensagem. Portanto, você deve tentar arduamente para evitar ter que abrir uma caixa de diálogo de erro.

Além dos conselhos dados em Sobre a Face (consulte a resposta de Aaron Lerch), é uma boa idéia registrar todas as mensagens de forma que possam ser inspecionadas posteriormente. Não confie no usuário para saber o que a mensagem de erro disse ou mesmo qual botão ele pressionou para se livrar da caixa de diálogo.

Se os usuários não forem técnicos, sugiro uma das duas abordagens:

1. Apenas forneça informações de contato para conversar com alguém. Basicamente, remova a oportunidade para eles tentarem resolver o problema, porque se eles não forem qualificados o suficiente para seguir as instruções, não importa o quão fácil você as faça, não se preocupe em dar a elas. Dê a eles um número de ajuda 1-800 ou e-mail clicável ou algo assim.

2. Se você realmente precisa dar instruções a eles, eles precisam ser não técnicos (também conhecidos por sua mãe, assumindo que sua mãe não é técnica). Mesmo o exemplo que você fornece "Não foi possível conectar ao servidor. Verifique sua conexão com a Internet". pode ser muito técnico para o usuário doméstico casual. Como verifico minha conexão com a Internet? Qual é a minha conexão com a internet? Lembre-se, são pessoas que chamam o computador de "máquina" e o monitor de "tv". Mostre-lhes fotos, explique-as em termos simples, etc. É melhor contratar alguém que não saiba nada sobre computadores, se você seguir esse caminho, a documentação de exemplo ou informações de erro que planeja apresentar e ver se elas entendem. (eu chamo isso de teste da sogra, se ela consegue entender, qualquer um pode).

Para que as pessoas leiam a mensagem importante que você tem em mente, primeiro pesquise no aplicativo todas as mensagens inúteis: "Entre em contato com o administrador (que na verdade não existe)!" e remova-os ou substitua-os por informações honestas. Depois que o ruído for removido do fluxo de mensagens, levará meses para que a base de usuários observe que a taxa de ruído para mensagem melhorou até o ponto em que é útil ler as mensagens novamente.

Localização, localização, localização!

Verifique se a mensagem de erro está em um local que, por um lado, não perturba o fluxo de trabalho, mas, por outro, é facilmente percebido.

Se a mensagem estiver no meio da tela e bloquear o acesso ao formulário principal, o usuário a fechará imediatamente, provavelmente sem lê-la, mas se não der certo, o usuário poderá nem perceber.

(Parece que parte do que tenho a dizer aqui foi respondida por outras pessoas antes de eu postar - algumas boas informações acima, principalmente o Sr. Lerch.)

Eu acho que a infeliz resposta rápida é "Eles não vão". De maneira semelhante ao fenômeno de usuários que possuem manuais de produtos, mas se recusam a abri-los, uma mensagem repentina e surpreendente fora do contexto (bem, pelo menos para o usuário base) será repentina, surpreendente e fora do contexto .

De lado meu pessimismo herdado, encontrei um sucesso anedótico com o espírito de suas sugestões. WRT o primeiro ponto, concordo com "curto", mas não tanto "preciso". O usuário não técnico terá problemas com qualquer mensagem de erro. Uma mensagem "precisa" ainda mais porque o usuário não técnico não precisa de menos informações, mas mais (ou seja, precisa de um pouco de educação) para realmente entender o que aconteceu.

Como exemplo, no segundo ponto, o usuário não técnico terá problemas com a primeira parte da sua mensagem de amostra.

• Com o que está se conectando?
• Qual servidor?
• Por que é incapaz?
• Fiz algo de errado?
• O software fez algo errado?

Algumas ou todas essas perguntas passarão por sua cabeça antes que realmente compreendam a resposta sugerida. Quando eles recuperarem a compostura e lerem a segunda parte, terão outras perguntas sobre como verificar sua conexão com a Internet. Alguns irão interpretá-lo como um problema de modem ou roteador e ligar e desligar toda essa pilha (sem brincadeira).

Um monte disso não é realmente solucionável na mensagem de erro; as pessoas têm um nível de conhecimento em informática e seu aplicativo provavelmente não terá um impacto significativo nisso. Mas se você fosse

• Forneça primeiro uma frase tão simples que você possa explicar por que eles estão vendo a mensagem. 5-7 palavras.
• Use uma linguagem simples de conversação para explicar um pouco mais detalhadamente.
• Ofereça (se a culpa for do site) um pedido de desculpas
• Encontre uma maneira inteligente de dizer a eles para não entrar em pânico
• Garanta que as coisas melhorem

você pode tornar a experiência um pouco mais agradável.

Observe que os últimos são fáceis de errar e acabam parecendo paternalistas; portanto, seja cauteloso e teste primeiro com alguns amigos.

Torne-os relevantes, concisos, em inglês claro e localizados em um local não muito longe de onde o usuário está procurando. Explique o que aconteceu e por que aconteceu, mas sem muito palavreado. Por fim, teste ou protótipo os estados de erro do seu aplicativo, assim como outras partes. Muitas vezes esquecemos e fazemos com que os usuários passem por um processo antes de incorporarmos todo o tratamento de erros, o que deixa de validar uma parte crítica e possivelmente frustrante da experiência.

Visualmente, faça-os se destacarem de outros elementos da interface. A animação pode ajudar a criar consciência; o técnica de desbotamento amarelo é um ótimo exemplo disso.

Muitos dos melhores conselhos já foram enviados. Quero acrescentar que as mensagens de erro devem estar alinhadas com o tom do restante do conteúdo da interface. http://www.visual-ii.com/ , que tem uma sensação muito conversacional e levemente nerd e cujo banner da página inicial diz "Descomplexação", criou uma página de erro 404 alinhada com a sua levemente nerd base: http://www.visual-ii.com/404 .

Para erros do tipo de exceção não tratada, que são raros, mas fatais, ao executar o aplicativo, criamos uma caixa de diálogo de erro com três botões:

• 'Copiar para área de transferência'. Isso copia os detalhes do erro para a área de transferência como texto. A suposição é que o usuário o usará para enviar um e-mail para o suporte técnico ou para colar no Bloco de Notas.
• 'Enviar relatório de erro'. Envia os detalhes do erro ao suporte técnico por email. Este é o botão padrão.
• 'Fechar'. Feche a caixa de diálogo. Este botão é desabilitado intencionalmente por 10 segundos ou até o usuário clicar em uma das ações acima. A contagem regressiva é mostrada no rótulo do botão.

Como salvaguarda, também registramos a mensagem de erro em um arquivo de texto local, caso o usuário não execute nenhuma ação, que poderá ser inspecionada posteriormente pelo suporte técnico.

Quando um aplicativo fornece mensagens de erro que são úteis para me ajudar a resolver o problema, eu as leio. Se um aplicativo (ou fornecedor) tem reputação de receber mensagens de erro que não são úteis, paro de lê-las.

Faça com que NÃO pareça uma mensagem de erro.

Não use alertas ou qualquer coisa que você precise fechar com um botão. Distribuir erros em um espaço estático reservado para esse fim (consulte webapps, painéis de administração do CMS etc.)

Use linguagem simples e engraçada.

Em vez de "erro interno do servidor 500", tente "Opa. Parece que não esperávamos essa entrada. Talvez você queira voltar e ver se colocou algo incomum no formulário".

Em vez de "erro ao inicializar o dispositivo", tente "Não foi possível usar o seu [dispositivo, por exemplo, modem GPRS]. Está tudo bem com isso? Verifique e veja o que está na configuração".

Use um efeito de caixa de luz encolhida e animado que concentre a atenção na mensagem de erro, juntamente com qualquer parte relevante da tela. Tenha o texto "(Clique aqui para remover a mensagem de erro)" em vez de um botão.

Se você deseja que eles enviem dados sobre o erro, mesmo com as entradas deles, é o que diz. Use a palavra "necessidade". "Aqui estão os dados sobre este erro que precisamos. Alguns deles podem se referir a você pessoalmente. Clique em -> aqui <- para enviá-lo para nós."

Existem inúmeras pesquisas mostrando que muitos usuários finais não técnicos solicitarão ajuda de alguém próximo a eles, ou suporte técnico, em vez de tentar resolver os próprios problemas. Essa é a natureza humana, e não tenho certeza de que algum dia conseguiremos contornar isso. Mas as mensagens de erro têm uma má reputação entre os usuários não técnicos que precisamos ultrapassar.

Além dos pontos mencionados acima, verifique se a sua mensagem de erro é:

• Claramente visível. Se for crítico, o usuário deverá interagir com a mensagem antes de retomar a interação com o aplicativo.
• Escrito em um tom amigável e casual, com linguagem não técnica. Por exemplo: Confira as mensagens do Firefox.
• Forneça uma descrição concisa, mas clara, do problema e por que ocorreu.
• Forneça instruções claras para corrigir o problema e um link para o local de partida (se possível).
• Inevitável. É muito melhor evitar que o erro do usuário ocorra do que tentar escrever uma mensagem de erro efetiva.

Um dos meios mais eficazes para exibir um alerta de erro é:

1. Coloque a nota de erro ao lado do elemento com o qual o usuário pode interagir para executar a correção
2. Role a página para focar no elemento e na nota de erro
3. forneça uma animação curta (movimento da caixa de nota de erro) para chamar a atenção do usuário quando a página já estiver centralizada na área do problema (por exemplo, formulários curtos)

Isso orienta o usuário para a ação corretiva de maneira útil e não ameaçadora, mas também insistente.