Um formulário pode parecer simples quando todas as respostas são válidas. Sua qualidade fica mais evidente quando alguém digita um endereço errado, perde a conexão ou envia uma informação que o servidor não aceita. Esses momentos fazem parte do uso normal e precisam aparecer no arquivo de design junto com o envio bem-sucedido.
Pense em um formulário de entrega. O cliente preencheu nome, número do apartamento e uma observação. A consulta de CEP falha. Se a interface apaga os campos ou exige um endereço sugerido sem explicar a diferença, o cliente precisa proteger seu trabalho do próprio produto. Um design melhor ajuda a corrigir o problema específico e preserva o restante.
Defina o que pode ser verificado e quando
Liste as regras de validação e quem é responsável por cada uma. Um campo obrigatório vazio pode ser identificado localmente. Saber se uma conta já existe normalmente depende do servidor. A disponibilidade de entrega pode depender de vários campos juntos. Essa diferença determina quando uma mensagem pode ser verdadeira.
Evite tratar um campo incompleto como erro enquanto a pessoa ainda digita. Quando o feedback antecipado ajudar, escolha um momento deliberado, como sair do campo ou enviar a etapa. Se a verificação for assíncrona, diferencie verificando, válido e inválido. Um indicador de carregamento que depois vira uma borda vermelha também precisa de uma explicação.
Escreva instruções que permitam agir
“Valor inválido” comunica um julgamento sem explicar a correção. “Digite o CEP com oito números” apresenta um próximo passo concreto, desde que essa regra corresponda ao país selecionado. Os exemplos devem representar entradas aceitas, e a formatação não deve apagar caracteres importantes.
As orientações do W3C sobre notificações em formulários descrevem formas de identificar erros e disponibilizar feedback para tecnologias assistivas. Use essas orientações ao revisar a associação entre campos e mensagens e os resumos de erros. O produto ainda precisa fornecer a explicação específica: o que falhou, como corrigir e se a entrada original foi preservada.
Preserve o trabalho quando o envio falhar
Separe falha de validação de falha no recebimento da solicitação. Quando uma solicitação expira, o produto pode não saber se o servidor a recebeu. Em ações como fazer um pedido, o comportamento de tentar novamente precisa ser combinado com a implementação para que outro clique não crie outro pedido sem querer.
Em uma atualização comum de perfil, mantenha os valores digitados visíveis e ofereça uma nova tentativa. Se a sessão expirou, explique a necessidade de entrar novamente e decida quais dados do rascunho podem permanecer com segurança. Não prometa que uma informação foi salva antes de o produto ter evidência disso.
Revise todo o ciclo de correção
Ao reunir referências no Refcat, vá além do campo vermelho. Acompanhe o envio, o resumo de erros, a entrada corrigida e a confirmação final. Confira se a pessoa retorna ao lugar certo e se a confirmação identifica a ação concluída.
Antes de entregar o formulário, percorra quatro casos: um valor ausente, uma rejeição do servidor, uma falha de rede e uma nova tentativa bem-sucedida. Inclua nomes longos realistas, formatos diferentes de endereço e navegação pelo teclado. A entrega deve explicar como se recuperar de cada caso, além de mostrar variações visuais de erro.