Uma mensagem de erro aparece quando a tarefa já encontrou um obstáculo. Se a interface apenas diz “algo deu errado”, a pessoa ainda precisa descobrir o que aconteceu, se perdeu algum dado e qual caminho pode tentar. Em vez de orientar, a mensagem acrescenta mais uma dúvida.
Uma mensagem útil identifica o problema em linguagem compreensível, aponta o próximo passo possível e esclarece o que aconteceu com os dados ou com a ação. Ela não precisa prometer uma solução imediata; precisa oferecer informação suficiente para a pessoa decidir como continuar.
O que a mensagem de erro precisa responder?
- O que aconteceu? A ação foi concluída, parcialmente concluída ou não foi realizada?
- Por que ocorreu? Há uma causa conhecida que seja útil explicar?
- O que faço agora? Corrijo um campo, tento de novo, escolho outro formato ou procuro ajuda?
- O que aconteceu com o que informei? Os dados foram mantidos, enviados ou descartados?
Nem todo erro permite identificar a causa técnica com precisão. Não invente uma explicação só para preencher a lacuna. Diga o que a interface sabe, o impacto para a tarefa e a alternativa segura disponível.
O tutorial de formulários da W3C WAI recomenda notificações concisas e claras, com instruções simples para resolver o erro. Para campos, identifique qual controle apresenta o problema e forneça uma descrição textual; não dependa apenas de cor ou ícone.
1. Identifique o que falhou sem culpar quem usa
Evite “Você fez algo errado” ou “Entrada inválida”. Essas frases atribuem responsabilidade sem dizer qual condição precisa ser corrigida. Prefira explicar o que está acontecendo:
- Vago: “Erro ao salvar.”
- Mais claro: “Não conseguimos salvar as alterações. Suas informações continuam nesta página. Verifique sua conexão e tente salvar novamente.”
- Vago: “E-mail inválido.”
- Mais claro: “Confira o endereço de e-mail. Ele precisa ter um nome, o símbolo @ e um domínio, como nome@empresa.com.”
Use um tom respeitoso e direto. Evite sarcasmo, dramatização, códigos internos e exclamações excessivas. Se a causa for conhecida, explique sem jargão; se não for, não a atribua a uma ação da pessoa.
2. Diga o próximo passo e nomeie a ação
“Tente novamente” ajuda apenas quando repetir a ação é seguro e pode funcionar. Caso a pessoa precise fazer algo diferente, explique o que fazer. Em formulários, indique o campo e o formato aceito. Em uma falha de pagamento, informe se a cobrança foi processada antes de sugerir outra tentativa. Em uma etapa indisponível, mostre uma alternativa real, como salvar e voltar mais tarde ou falar com suporte.
O botão também deve descrever o resultado: “Reenviar código”, “Corrigir endereço” ou “Salvar rascunho” são mais informativos do que “OK” quando a ação não é óbvia.
3. Preserve o trabalho já feito
Quando uma validação falha, mantenha os campos preenchidos sempre que for seguro. Se não for possível preservar o conteúdo, informe isso antes da ação que pode descartá-lo e ofereça uma forma de copiar, salvar ou recuperar os dados quando viável.
Depois de uma ação importante, confirme o estado. A interface deve distinguir “processando”, “concluído”, “não concluído” e “concluído parcialmente”. Isso evita cliques repetidos e reduz incerteza. A W3C WAI destaca a importância do feedback sobre o resultado do envio, seja sucesso ou erro.
4. Torne o estado compreensível e acessível
Uma borda vermelha, sozinha, não explica qual campo precisa de atenção. Combine sinal visual com texto e relacione programaticamente a mensagem ao campo quando aplicável. Em formulários extensos, um resumo no início pode ajudar a encontrar problemas; links para os campos encurtam o caminho.
- Considere leitores de tela e mensagens dinâmicas.
- Permita navegação por teclado e foco no primeiro erro relevante.
- Garanta que o significado não dependa somente da cor.
- Use linguagem simples para quem não conhece os termos técnicos.
- Permita corrigir uma informação sem recomeçar toda a tarefa.
A W3C WAI descreve práticas no guia de notificações de formulários e no critério WCAG 3.3.1 — Identificação de Erros. Isso não substitui uma auditoria de conformidade; serve de referência para projetar feedback mais claro e acessível.
5. Escolha o momento e o lugar adequados
Mensagens inline funcionam quando o problema se relaciona a um campo. Um resumo no topo pode ajudar se houver vários erros ou retorno após envio. Um alerta intrusivo pode ser adequado para algo urgente, mas diálogos modais não devem interromper qualquer falha pequena.
Evite mostrar erros antes de a pessoa ter oportunidade de concluir a entrada, a menos que o feedback imediato realmente ajude. Durante a digitação, não anuncie repetidamente a cada caractere. Ao submeter, ofereça navegação clara para a primeira correção necessária.
Exemplos de antes e depois
- Em vez de: “Falha.” Prefira: “Não foi possível enviar o formulário. Seus dados continuam preenchidos. Revise os campos destacados e tente novamente.”
- Em vez de: “Campo incorreto.” Prefira: “Informe o CNPJ com 14 números. Você pode digitar com ou sem pontuação.”
- Em vez de: “Erro 502.” Prefira: “O serviço está temporariamente indisponível. Suas alterações não foram enviadas; salve uma cópia e tente novamente em alguns minutos.”
- Em vez de: “Pagamento recusado.” Prefira: explique o estado confirmado e recomende verificar com o banco antes de uma nova tentativa, se isso corresponder ao comportamento real.
As mensagens devem refletir o que o sistema realmente sabe. Nunca afirme que os dados foram preservados, o pagamento não ocorreu ou o envio foi concluído sem confirmação técnica.
Checklist de mensagens de erro
- O texto explica o que falhou em linguagem simples?
- Identifica o campo, ação ou etapa afetada?
- Indica um próximo passo executável?
- Esclarece o estado do trabalho já feito?
- Evita culpa, jargão e causas inventadas?
- Pode ser percebido por leitor de tela e teclado?
- Continua claro sem cor ou ícone?
- A pessoa consegue corrigir sem refazer trabalho?
Conclusão
Uma mensagem de erro não precisa encerrar a tarefa. Precisa mostrar o que aconteceu, o que isso significa para o progresso e qual passo seguro está disponível. Quando explica sem culpar, preserva o trabalho e aparece de forma acessível, o erro deixa de ser um beco sem saída e se torna um estado compreensível.
Revise os erros mais frequentes do produto e teste se alguém que não conhece o sistema consegue responder: “o que aconteceu e o que posso fazer agora?”.
