Como escrever mensagens de erro de validação de formulários

Uma pessoa informa um endereço de e-mail, passa para o campo seguinte e recebe uma orientação útil para corrigi-lo. Outra vê uma frase quase igual enquanto ainda está digitando e se pergunta o que fez de errado. As palavras podem ser idênticas, mas a experiência é diferente.

É isso que torna o design de mensagens de erro de validação de formulários mais difícil do que parece. Uma frase mais acolhedora não compensa um aviso que aparece cedo demais, e uma explicação precisa não ajuda quando aponta para a resposta errada. O trabalho de fato é decidir o que o sistema sabe, em que momento deve se manifestar e o que a pessoa pode fazer em seguida.

Existem boas evidências para orientar essas decisões, mas elas não convergem para um único padrão universal. Pesquisas sobre comércio eletrônico, orientações para serviços públicos e experimentos com formulários de cadastro atribuem pesos diferentes às interrupções e ao retorno antecipado. Entender essas diferenças é mais útil do que reunir uma lista de mensagens de erro supostamente perfeitas.

O que os usuários reais nos mostram sobre validação

No relatório de janeiro de 2024 de Edward Scott sobre os testes de validação junto aos campos da Baymard, uma participante deixou de colocar o símbolo @ em um endereço de e-mail no site da L.L.Bean. O aviso apareceu depois que ela passou para o campo seguinte, e a correção levou poucos segundos. Na Etsy, outro participante recebeu um erro ao entrar em um campo de endereço que ainda não havia preenchido e sentiu que a interface o repreendia antes de ele responder. A REI ofereceu outro exemplo de recuperação: um erro no código de segurança do cartão desapareceu quando a participante informou o terceiro dígito que faltava.

Essas observações históricas mostram por que dizer que um formulário “usa validação junto aos campos” é uma descrição incompleta. O momento em que a mensagem aparece e aquele em que ela desaparece podem ser tão importantes quanto o texto.

Nas nossas próprias revisões de formulários, eu transformaria essas observações em uma pergunta: a mensagem responde a uma ação que a pessoa considera concluída? Clicar em Continuar expressa claramente essa intenção. Sair de um campo às vezes também expressa. Colocar o cursor em um campo vazio, em geral, não. A interface precisa de um motivo para interromper a pessoa; não basta que o valor atual descumpra uma regra.

Um contraponto útil vem do estudo de 2009 sobre formulários de cadastro, de Luke Wroblewski e da Etre. Vinte e dois participantes testaram seis versões. Em comparação com o controle, a melhor versão com validação junto aos campos apresentou, segundo o estudo, aumento de 22% na taxa de sucesso e redução de 42% no tempo de conclusão. Um participante comentou que preferia saber dos erros à medida que avançava. Ao mesmo tempo, sinais verdes de confirmação ao lado de respostas familiares causaram dúvidas sobre o que o sistema realmente havia verificado.

A lição mais útil do estudo diz respeito à incerteza: quem está escolhendo um nome de usuário disponível precisa de uma informação que o sistema possui; quem está digitando o próprio nome talvez não precise dessa confirmação. Eu daria prioridade ao retorno que esclarece uma dúvida, em vez de distribuir símbolos de aprovação por todo o formulário.

Por que o GOV.UK escolhe outro momento para validar

O padrão de validação do GOV.UK recomenda aguardar até que a pessoa tente continuar ou enviar o formulário, em vez de validar quando ela sai de um campo. Também orienta preservar as respostas já preenchidas, colocar um resumo dos erros no topo, mover o foco para esse resumo e identificar cada erro junto ao campo correspondente. A validação antecipada precisa ser sustentada por pesquisa com usuários.

Vale manter explícita a diferença em relação aos exemplos de comércio eletrônico. Em uma etapa curta, com apenas uma pergunta, a correção após o envio permanece relativamente próxima: a resposta ainda está diante da pessoa. Em um checkout longo, o campo incorreto pode estar muito para trás quando ela finalmente envia o formulário.

Se eu estivesse revisando um fluxo de inscrição em um workshop, começaria pelo formato da tarefa. Em uma página com uma única pergunta sobre a data, clicar em Continuar é um momento razoável para explicar que a opção não está disponível. Já em uma página com dados de contato, necessidades de acessibilidade, quantidade de vagas e informações de cobrança, esperar até o final pode obrigar a pessoa a percorrer um caminho maior de volta pelo formulário. Isso não justifica automaticamente validar tudo durante a digitação. Significa que vale testar um retorno antecipado em campos selecionados.

Também há diferença entre uma orientação e um erro. Uma lista de requisitos de senha pode explicar as condições durante a digitação sem tratar cada requisito ainda não atendido como uma falha. Uma dica sobre datas pode informar o período disponível para reserva antes de haver qualquer valor preenchido. Uma ajuda útil não precisa esperar pelo envio, nem precisa parecer um alerta vermelho quando é apresentada antes dele.

Registre qual evento aciona a validação de cada campo. Sem isso, a afirmação “validamos junto aos campos” pode esconder três comportamentos diferentes, implementados por três pessoas diferentes.

Escreva apenas a correção que o sistema pode justificar

“Informe um endereço de e-mail válido” costuma encerrar a conversa quando deveria iniciá-la. O que significa válido nesse contexto? Ausente, com formato incorreto, indisponível e não verificado são estados diferentes. Tratá-los como sinônimos produz mensagens que parecem seguras, mas não explicam o próximo passo.

Em um formulário fictício de workshop, um campo de contato vazio poderia exibir: “Informe um endereço de e-mail para receber a confirmação da sua inscrição.” Se o texto digitado não tiver @, a frase “Informe um endereço de e-mail com o símbolo @” descreve um problema observável. Nenhuma dessas mensagens comprova que a caixa de e-mail existe ou pertence à pessoa. Para isso, seria necessária uma etapa separada de verificação.

É tentador escrever uma mensagem muito específica para cada possível erro de digitação. Eu evitaria isso, a menos que a lógica de validação consiga distingui-los com confiabilidade. Dizer que o domínio foi digitado errado não ajuda quem usa um domínio pouco conhecido, mas legítimo. Quando o sistema não tem certeza, uma sugestão opcional pode ser melhor do que uma recusa obrigatória. A equipe precisa concordar sobre essa diferença antes de aprovar os textos.

Abaixo está um pequeno conjunto de mensagens para esse exemplo de workshop. Cada linha começa com uma condição, porque o mesmo campo pode exigir várias mensagens diferentes.

A última linha exige, de propósito, mais do produto do que uma frase. Só faz sentido orientar a pessoa a consultar o status se o serviço oferecer uma maneira utilizável de fazer isso. Caso contrário, o design precisa de outro caminho de recuperação, definido com as equipes de engenharia e atendimento. O texto deve revelar essa decisão que falta, em vez de escondê-la atrás de “Tente novamente”.

Permita navegar por um formulário longo depois de uma falha

Imagine clicar em Continuar perto do final de uma página de inscrição. Agora, dois campos próximos ao topo apresentam erros, mas a área visível ainda mostra o botão. Uma borda vermelha em algum ponto fora da tela não basta. A pessoa precisa perceber que a ação não foi concluída e voltar às respostas que exigem atenção.

No exemplo do workshop, um resumo pode identificar os problemas na quantidade de vagas e na data, com um link para cada campo. Durante a correção, a mensagem local continua ao lado da resposta. Essa repetição tem uma função: o resumo ajuda a chegar ao lugar certo; a mensagem junto ao campo ajuda a editar. Usar textos diferentes nesses dois locais acrescenta um esforço desnecessário de interpretação.

O resumo também deve ser seletivo. Um e-mail de contato que passou pelas verificações pertinentes não deve aparecer na lista de erros. Tampouco se deve apagar todo o formulário só para deixá-lo visualmente limpo. Ver a resposta anterior ajuda a pessoa a entender o que aconteceu e a alterar apenas o necessário. Para informações sensíveis, a retenção exige uma decisão específica de produto e segurança; não prometa que todos os campos sempre serão armazenados.

É nesse ponto que uma revisão de design estático precisa se tornar uma revisão da interação. Use o teclado para seguir um link do resumo. Confira onde o foco chega, se o rótulo do campo continua visível abaixo de um cabeçalho fixo e se a explicação está disponível ao alcançar o campo. Depois faça a correção e envie novamente. Uma captura de tela mostra uma caixa vermelha, mas não comprova que esse percurso pela página funciona.

No celular, revise a mesma sequência com o teclado aberto. Uma mensagem pode se encaixar muito bem na versão para desktop e ficar escondida sob o teclado no telefone. Mensagens longas devem quebrar em várias linhas, sem reduzir o texto a um tamanho ilegível. Eu preferiria dar mais uma linha à orientação de correção a obrigar a pessoa a ampliar a instrução de que precisa para concluir a tarefa.

A mensagem precisa mudar quando os fatos mudam

Um erro frequente de revisão é aprovar apenas duas telas: a normal e a de erro. O problema costuma estar entre elas. A pessoa edita a resposta, a causa original deixa de existir, mas a mensagem vermelha permanece. Para ela, pode parecer que a correção não funcionou.

Suponha que, no formulário do workshop, tenham sido solicitadas quatro vagas e restem apenas duas. Alterar a quantidade para duas deve acionar uma nova verificação da regra aplicável. Trocar a data é diferente: muda o estoque de vagas do qual a regra depende. Um aviso sobre a sessão anterior não pode simplesmente continuar associado à nova. Essa relação é mais importante do que a aparência da borda vermelha.

Na entrega para implementação, eu pediria três estados adicionais: em verificação, aceito para esta etapa e não foi possível verificar. “Verificando disponibilidade…” não significa “Duas vagas disponíveis”, e nenhum dos dois significa que a inscrição foi confirmada. Essas distinções mantêm a interface fiel aos fatos quando uma solicitação demora mais que o esperado ou as vagas acabam entre duas verificações.

Há ainda um caso menos visível. A pessoa muda a data duas vezes, e a primeira consulta de disponibilidade termina depois da segunda. Se a resposta antiga substituir a mais recente, a interface pode mostrar uma resposta perfeitamente legível para a pergunta errada. As notas de design devem exigir que o resultado corresponda à seleção atual; a engenharia pode escolher como garantir isso.

Ao revisar animações ou indicadores de carregamento, mantenha essa distinção entre estados em vista. O objetivo não é dar uma aparência de atividade à transição, mas evitar que a pessoa interprete um resultado antigo como novo. Se o sistema não consegue verificar algo naquele momento, uma explicação neutra é mais precisa do que marcar a resposta como inválida.

Uma falha do serviço não é uma resposta incorreta

O erro de texto mais custoso em um fluxo de inscrição pode ser pedir que alguém corrija uma resposta que nunca esteve errada. Uma solicitação malsucedida pode significar que os dados foram rejeitados, que o servidor estava indisponível ou que o resultado é desconhecido. Cada possibilidade exige um próximo passo diferente.

Considere um tempo limite excedido depois que a pessoa clica em Reservar. A solicitação pode não ter chegado ao serviço. Também pode ter sido concluída, mas a resposta se perdido. Sem saber o que ocorreu, afirmar “Sua reserva falhou” é ter certeza demais. Um segundo envio imediato pode ser inofensivo ou gerar uma duplicação. O produto precisa decidir explicitamente como lidar com essa incerteza.

No nosso exemplo, eu revisaria o caminho de recuperação com uma pessoa da engenharia antes de aprimorar a mensagem. O serviço consegue recuperar o resultado usando uma referência da solicitação? Repetir o pedido devolve com segurança o resultado original? O atendimento consegue localizar a tentativa? Quais respostas permanecem na página? Essas perguntas determinam se a próxima ação adequada é consultar o status, tentar de novo com segurança ou falar com o atendimento informando uma referência.

Isso não é motivo para incluir detalhes técnicos internos no texto de erro. O leitor não precisa de uma aula sobre falhas de rede. Precisa de uma declaração fiel ao que se sabe e de um próximo passo que funcione. Uma referência da solicitação pode ser útil se o atendimento souber usá-la; um código de erro sem explicação é apenas mais um problema para a pessoa interpretar.

As boas práticas de validação incluem o caminho de recuperação

No OpenDesign, uma prévia HTML compatível pode ajudar a equipe a comparar o campo normal, o erro e o estado corrigido. Use valores realistas e uma mensagem longa, examine uma área de visualização estreita e comente o elemento específico que precisa mudar. Depois teste a mesma sequência com o backend em funcionamento, a navegação por teclado e os anúncios do leitor de tela.

Uma pequena sessão de revisão pode revelar mais do que outra rodada de adjetivos. Dê a alguém uma tarefa concreta, como reservar quatro vagas em um workshop, e deixe que encontre o conflito de disponibilidade. Pergunte o que acredita ter acontecido e o que faria em seguida. Evite explicar primeiro o significado pretendido; isso eliminaria justamente a ambiguidade que você está tentando descobrir.

Observe o que a pessoa faz depois da correção com o mesmo cuidado que dedica ao que ela diz sobre a mensagem. Se relê o aviso várias vezes, talvez ele não tenha desaparecido. Se altera um e-mail válido depois que o serviço excede o tempo limite, a interface pode estar atribuindo a responsabilidade ao lugar errado. Se recomeça todo o formulário, o caminho de recuperação pode estar mais difícil de encontrar do que a tarefa original.

Em um serviço em produção, envios repetidos e ciclos de correção podem indicar onde investigar. Eles não explicam automaticamente a causa. Uma quantidade alta de erros pode decorrer de instruções confusas, uma regra restritiva demais, falta de vagas ou um defeito de implementação. Combine a sequência de eventos com o comportamento observado e evite coletar as respostas pessoais em formato bruto apenas para diagnosticar o formulário.

Antes de aprovar o exemplo, eu percorreria esta sequência breve:

1. Preencha uma resposta incompleta e observe quando o aviso aparece.
2. Envie o formulário com dois erros e chegue aos dois campos pelo resumo.
3. Corrija uma resposta e confirme que os valores não relacionados continuam preenchidos.
4. Altere uma resposta da qual outras dependam, como a data do workshop, e examine o novo resultado.
5. Encontre uma situação de serviço indisponível e siga o caminho de recuperação oferecido.

A última verificação é o resultado bem-sucedido. A confirmação mostra a data e a quantidade corrigidas? A pessoa consegue saber se existe uma reserva? O formulário não se recuperou apenas porque o texto vermelho desapareceu.

Boas mensagens de erro de validação deixam menos trabalho de interpretação para a pessoa. Os exemplos do setor ajudam porque mostram onde essa interpretação falha: antes de uma resposta ser concluída, depois de uma correção ou quando a interface afirma saber mais do que realmente sabe. Aproveite esse raciocínio, teste-o na sua própria tarefa e escreva a mensagem de acordo com o comportamento que você consegue entregar.