Formulário com erro de campo: o que a pesquisa recomenda

A pesquisa sobre erro de formulário parte de uma ideia simples: quem encontra um erro está tentando terminar uma tarefa, e cada passo extra custa atenção. O acervo do NN/g testou durante anos como um formulário reporta um problema, e o resultado é mais concreto do que a média das telas de cadastro segue. O índice de tema de interaction design (em inglês) reúne as peças por trás deste post.

Quando validar enquanto digita e quando esperar

Valide dentro do campo quando a ferramenta consegue, e mantenha a mensagem ao lado desse campo. A diretriz pede retorno instantâneo em campo complexo, como uma senha com regras, porque a pessoa precisa conhecer a regra antes de seguir.

A mesma diretriz manda não disparar validação antes de a pessoa terminar o campo. Marcar um campo como errado enquanto o cursor ainda está lá interrompe o fluxo e trata um valor pela metade como falha.

Quem decide é o tipo de campo, não uma regra fixa. Campo simples espera a pessoa sair, e campo com regra visível pode responder enquanto ela digita. O acervo convive com as duas leituras e não oferece critério de desempate.

Mostrar que deu certo também importa. Quando o campo é complexo, uma confirmação discreta avisa que o valor passou.

Rótulo, placeholder e espaço em branco

Um placeholder dentro do campo não é rótulo. Ele some na primeira tecla, e a pessoa perde a pergunta justamente quando começa a responder. Também aposta na memória de curto prazo: depois de digitar, não sobra texto para conferir antes de enviar.

O mesmo padrão atrapalha quem navega por teclado e faz o campo vazio parecer menos importante que o preenchido, porque o texto dentro da caixa puxa o olho. O placeholder ainda pode ser confundido com preenchimento automático, e às vezes obriga a pessoa a apagá-lo à mão. Um rótulo flutuante mantém o rótulo visível e resolve parte do problema, mas não resolve a atenção nem a confusão com dado automático.

A resposta recomendada é rótulo e dica fora do campo, sempre visíveis. A exceção declarada é formulário com um ou dois campos muito frequentes, como busca e login.

Espaço em branco tem regra própria. O rótulo pertence mais ao campo dele do que ao campo seguinte, pela lei da proximidade, a mesma que a microcópia de produto respeita. Agrupar campos relacionados faz o formulário parecer menor, porque o olho lê blocos em vez de uma coluna de caixas. Rótulo acima do campo é o mais fácil de varrer, rótulo à esquerda serve quando a largura aperta, e rótulo à direita briga com a varredura.

Como escrever a mensagem de erro

A mensagem precisa ser explícita, legível, educada e precisa, com conselho prático. Dizer que o campo está vazio não é mensagem de erro; dizer o que digitar é. Acerto também merece resposta, então campo complexo deve confirmar que passou.

A cor separa erro de estado normal, e o vermelho carrega a falha na maioria dos sistemas. Amarelo serve ao aviso, e verde ou azul servem ao sucesso. Cor sozinha não basta, então ícone ou animação discreta ajuda o olho a achar o problema em formulário longo.

Não esconda a mensagem em tooltip. O ícone passa despercebido e o texto só aparece no hover ou no foco, o que cobra um passo que o erro não precisava. Resumo de validação no topo da página também não sustenta o trabalho sozinho, porque a pessoa tem que casar cada linha com um campo.

Deixe o modal para casos raros. O diálogo interrompe a tarefa e aumenta a carga, o que cai bem em evento do sistema que exige decisão e não em campo isolado que precisa de conserto.

Indicador de obrigatório e ruído de aviso

Um texto sobre indicadores, validações e notificações (em inglês) separa três formas de a tela falar. Indicador é contextual, condicional e passivo. Validação é a mensagem de erro ligada ao campo, e ela fica até a pessoa agir sobre ela. Notificação vem de evento do sistema e não da ação imediata, e se divide entre a versão que exige ação, que deve interromper, e a passiva, que pode passar despercebida.

A distinção importa porque o mesmo componente recebe veredito oposto em cada papel. O modal é ruído no erro de campo e ferramenta certa no evento do sistema que pede decisão.

Aviso que aparece e some é notificação passiva, e falha como erro porque a pessoa pode desviar o olhar no instante em que ele surge. Se o erro some antes de alguém ler, é como se ele nunca tivesse aparecido. É por isso que o estado de carregamento e vazio precisa de um desenho que segure a informação, e não de um piscar.

Campo de data e formato

O acervo lista quatro formas de pedir data: calendário, seletor de rolagem no celular, três menus separados para dia, mês e ano, e digitação. O calendário serve ao intervalo curto e ao intervalo entre duas datas. O seletor de rolagem sofre quando a lista cresce. Os três menus cobram passos desnecessários. A digitação costuma ser o caminho mais eficiente, sobretudo para data distante, e deve estar sempre disponível.

Campo de data bem feito aceita qualquer separador e não exige formato fixo nem caractere especial. Ele avisa quando a data é impossível em vez de presumir e remove opção sem sentido. Também preserva o que a pessoa já digitou e mantém o intervalo coerente quando uma das pontas muda.

Para público internacional, o mês por extenso ou o conjunto de campos separados evita o problema de ordem entre dia e mês, que muda de país para país.

Formulário longo contra fluxo em etapas

Comprimento sozinho não decide se o formulário virou aplicação. O teste é o tipo de informação, o número de passos, a área condicional e a linearidade do caminho. Formulário que passa de duas telas costuma apontar para uma tarefa que pede aplicação, com retorno próprio, ajuda no contexto e fluxo flexível.

Uma página longa pode ser a resposta certa quando todos os campos são mesmo necessários. Agrupar esses campos em blocos visíveis mantém a página legível sem virar um fluxo em várias etapas. Essa correção mais discreta serve à maioria dos sites.

Cortar a pergunta antes de enfeitar o campo

O framework EAS anda em três movimentos: eliminar, automatizar e simplificar. Eliminar é cortar pergunta que não é necessária nem urgente, adiar o que pode ser perguntado depois e não obrigar cadastro antes da compra.

Automatizar é reusar dado que o sistema já tem e inferir em vez de pedir, como derivar cidade do código postal. É também oferecer guardar o valor para a próxima vez.

Simplificar é valor padrão útil, formato livre que o sistema limpa por trás, e recurso do celular para foto ou resposta falada. Um formulário que cabe em um campo, como o padrão de cadastro de campo único, mostra até onde vai o primeiro movimento.

O framework fecha com uma ressalva. Simplificar não é o mesmo que apagar campo, porque o formulário longo às vezes é o necessário. Esse ponto é onde ele encontra a divergência abaixo.

O erro comum

O problema mais comum não é faltar regra. É usar a regra no lugar errado. A maioria dos formulários importa o padrão mais severo de outro contexto. Um modal responde ao erro de campo, e um tooltip carrega a dica. Um placeholder fica onde deveria haver rótulo, e uma página de resumo devolve a pessoa ao topo para caçar a caixa quebrada.

O caso do alerta falso de míssil no Havaí (em inglês) faz o mesmo ponto pelo outro lado. O operador escolheu a opção errada e confirmou, o que o artigo chama de “lapso”, a distância entre querer uma ação e executar outra parecida no piloto automático. O projeto carregou a culpa, não a pessoa: pista enganosa, opção mal diferenciada, apresentação problemática e falta de confirmação para ação destrutiva.

Esse caso resume o tema todo. Formulário que culpa a pessoa por falha de desenho vai seguir colhendo o mesmo erro, e redesenho é a solução onde treinamento não é. Prevenção de erro é uma das dez heurísticas por trás desse trabalho, e pesa mais em sistema onde o erro custa caro.

Onde as fontes divergem

Quando validar: uma diretriz pede retorno dentro do campo assim que a pessoa termina e pede retorno instantâneo em campo complexo como senha, enquanto outra regra proíbe validar campo que ainda está sendo digitado. O tipo de campo é a linha prática, e o acervo não declara nenhuma.
O modal: é ruído no erro de campo e interrupção correta no evento do sistema que exige decisão. O mesmo componente ganha vereditos opostos porque o contexto muda.
Campo de data dividido: o artigo de data desaconselha os três menus e, na mesma página, sugere campos separados para público internacional. A tensão fica aberta.
Formato livre contra máscara: o artigo de data pede qualquer formato, e o framework de simplificação sugere máscara que insere o separador enquanto se digita. Mesmo objetivo, mecanismos opostos.
O formulário longo: um artigo trata o formulário que passa de duas telas como sinal de que a tarefa virou aplicação, e outro resolve um formulário longo só com agrupamento visual. Quebrar em fluxo ou agrupar na mesma página, e a escolha depende da tarefa.