Criando mensagem de erro de forma mais clara para seu projeto

Data: 03.09.2015  Categoria: Tecnologia  Leitura: 9 minutes 

Já aviso que não sou manjadora de nada e não sou dona da verdade absoluta só que aprendi tanto com esse post que resolvi compartilhar o que aprendi, e to feliz com isso.

Sempre recebo e-mails do Medium com uma lista dos últimos conteúdos que podem me agradar baseado no que já gostei e no que as pessoas que eu sigo recomendam. Na lista da vez tinha o post do Thomas Fuchs, autor do Zepto.js, onde ele fala sobre boas práticas na hora de criar as mensagens de erro da sua aplicação, ou melhor, sobre o que não fazer na hora de criar uma. Já li coisas parecidas em alguns lugares mas ele escreveu de uma maneira tão legal que entrou bem na minha cabeça e me deixou inspirada pra vir aqui tentar fazer o mesmo. Não vou traduzir o texto dele, é só uma união do que achei importante e do que pesquisei em outros lugares para escrever o post. Se quiser ver com mais detalhes o que ele escreveu, o link da publicação original está no final do post junto com as outras referencias que usei.

Imagina que você está utilizando o seu computador e pula a seguinte mensagem de erro na sua frente:

1-veXRiLqrxPbguaxFIcFbPA

Uma mensagem de erro que não significa absolutamente nada para o usuário ou pra qualquer um que olhar. Uma janela totalmente genérica, que na verdade não serve para ser utilizada em nenhuma ocasião.

Agora imagine que você queira compartilhar essa imagem anterior com os seus seguidores no Twitter e ao fazer o upload da imagem você recebe esta mensagem de erro:

1-NN3x0pHBNq7sUpEb7gjmHw

Isso foi o que aconteceu com o autor do post original, ao menos é o que ele diz. Essa janela de erro apareceu porque ele tentou fazer o upload da imagem anterior em uma resolução muito alta e o twitter tem um limite para isso.
Não seria mais fácil avisar o usuário deste limite antes de fazer o upload, ou melhor ainda, o próprio serviço diminuir a resolução da imagem, poupando o usuário de fazer este trabalho pois queremos compartilhar tudo rapidamente, e avisá-lo que isso foi feito?

Como deveria ser feita uma boa janela de erro?

Euzinha aqui aprendi que uma mensagem de erro deve ser clara e que não devemos culpar o usuário pelo erro, devemos ser legais e gentis nas nossas palavras. E o que o guideline OS X Human Interface Guidelines diz é exatamente isso. Aliás, muitas das idéias do Thomas saiu deste guia.

Escreva uma mensagem de erro que descreva a situação de forma sucinta e clara. Coisas genéricas como “Algo aconteceu“, “Ops! Tem algo errado acontecendo” não significam nada e não ajuda o usuário a resolver o problema dele.
Escreva um texto informando as consequências do erro e sugira soluções e alternativas para o que aconteceu. Dê o máximo de informações que forem necessárias para informar o usuário de forma clara. Não use linguagem técnica, afinal, a sua vó precisa saber porque não está conseguindo enviar a selfie dela para o Facebook.
Usar o termo “OK” em um botão não é nada legal, ele pode significar muitas coisas, “OK, eu quero continuar com isso, vamos em frente” ou “OK, agora eu entendo o que fiz de errado.

dodontandroid

Essa imagem acima mostra bem como é ruim o uso de termos genéricos nos botões de um alert. As imagens foram retiradas do guideline da Google para Android. O botão de ação com o termo “Discard” indica claramente o que vai acontecer se você escolher essa opção já o termo “No” responde a pergunta do dialog mas não sugere o que vai acontecer se você clicar ali.

Vamos ver mais exemplos:
1-JWd4UlV9MYA311f2fdKoVw

Ok Windows Phone, o que esses números significam? E porque você não é capaz de verificar se há updates me esperando? O que você pode fazer por mim?
Essa mensagem de erro não diz nada pra o usuário, não fala qual é o problema, não mostra a solução e você não pode fazer absolutamente nada. Se você é desenvolvedor provavelmente já sabe o que fazer, vai copiar o número do erro e procurar a solução no Bing Google, mas se não é…

O problema está com a data e horário do seu dispositivo. Se os dados não baterem com os do serviço Windows Update esse erro pode acontecer. Os dados não precisam ser iguais, mas a diferença não pode ser gritante. Pra resolver é simples, basta ativar a atualização automática de data e hora.

A mensagem de erro poderia ser algo como “Por motivos de segurança não foi possível verificar as atualizações. Isso pode acontecer se as configurações de data e hora do seu aparelho não estiverem corretas, verifique e tente novamente.” e ninguém sairia reclamando na internet que o SO é uma porcaria. Detalhes podem fazer toda a diferença e acabar com a sua credibilidade. Imagina se é um aplicativo na Google Play a quantidade de comentários “Lixo, não baixem” que iria ter. Você não vai querer isso!

Outra coisa, nunca interrompa o usuário no meio de algo que ele estiver fazendo para mostrar um dialog que não significa nada. Procure outras alternativas, mas não jogue uma tela de erro na frente dele se aquilo não for um erro ou um aviso de algo que pode impactar de maneira fundamental o valor que o usuário pode obter do aplicativo.

alert_2x

IC561114

O banner do Gmail para cancelar o envio de um e-mail é um bom exemplo do que estou falando, faz muito mais sentido no contexto e é menos agressivo do que receber um alerta com a mensagem “Está certo de que deseja enviar este e-mail?” Se você clicou em “Send” é porque é o que você quer fazer, não é necessário confirmar duas vezes a mesma ação. Se por um acidente você clicou ali ou esqueceu de adicionar algo você tem a opção de desfazer o envio, mas ela não te atrapalha e permite que você continue o que está fazendo.

bannergmail

As imagens abaixo mostram também um outro exemplo de como seguir na hora de criar mensagens de erro:

printtrouble

A primeira coluna da imagem acima mostra o que é errado de se fazer já na segunda ela mostra a melhor opção. Por exemplo, você quer mover um arquivo de uma pasta para outra mas ele já foi movido ou excluído, ou você não possui permissão para isso. Se o programa pode identificar facilmente o problema porque fazer o usuário descobrir por conta própria deixando todo o peso da resolução para ele?

No final do artigo Thomas da 3 dicas:

  1. Não abuse de alertas para aumentar vendas e propagandas ou mostrar informações desnecessárias. O usuário vai parar de ler até mesmo as mensagens importantes.
  2. Não esteja tão certo de que o usuário saiba o contexto daquela mensagem. Por algum motivo ele pode ver a mensagem de erro muito tempo depois e não lembrar o que levou ele até ali.
  3. Não use termos técnicos e seja amigável com o usuário.
Uma das maiores falácias quando se está fazendo UI/UX é: “Isso parece normal para mim, portanto parece para todo mundo.” Em uma tradução bem meh…

O que Fuchs quer dizer nesse tweet é que só porque alguma ação, opção, erro, botão ou qualquer outra coisa na sua aplicação parece óbvio para você não significa que é obvio para todo mundo.

Fora as sugestões do Thomas, Apple e Google a Microsoft da mais algumas:

  • Não informe erros dos quais o usuário não se importa.
  • Não informe erros para condições que o usuário acha aceitável.
  • Não encha uma janela de erro com termos técnicos e não ache compreensível colocar só porque a sua aplicação é para programadores.
  • Deve permitir que o usuário resolva o problema ou escolha fazer outra coisa como resultado.
  • A mensagem deve estar focada no usuário e não falar de códigos (a gente sabe o que significa um erro 500, ou um NullPointerException, o usuário não).
  • A mensagem deve ser o mais breve possível, mas não tão curta.
  • O usuário não deve ser culpado ou se sentir um estúpido por ter feito algo de errado.

A melhor mensagem de erro é aquela que nunca aparece.

Não importa para quem você está programando, essas práticas funcionam bem em qualquer plataforma, o segredo está em ser simples e claro. Sei que encher o código de “ifs” para fazer essas verificações e evitar que apareça uma janela de erro é algo chato de se fazer e sei também que se todo mundo soubesse usar os aplicativos e programas corretamente a vida de quem programa seria mais fácil, mas nós existimos pra deixar a vida do usuário mais simples, e não o contrário.

 

Referencias:

Comentários

Be kind / Be nice

Seja o primeiro a comentar!

Os comentários estão fechados

%d blogueiros gostam disto: