Uma pessoa termina um pedido de orçamento, aciona o botão de envio e continua na mesma página. Perto do topo, há uma faixa vermelha que ela só encontra quando volta a rolar. Dentro do formulário, três campos mudaram de cor. Nenhum explica como seguir. Um resumo de erros resolve uma parte importante desse impasse ao identificar que o envio precisa de correções e oferecer caminhos diretos para fazê-las.
Desenhe o percurso inteiro, do envio à nova tentativa
Imagine um formulário de orçamento para material de exposição. Ele pede dados de contato, data de montagem, dimensões da área e um arquivo opcional. A pessoa preencheu quase tudo, mas digitou um endereço eletrônico incompleto, informou uma data anterior à disponibilidade e anexou um arquivo acima do limite. Ao enviar, ela precisa descobrir quantas pendências existem, quais informações foram preservadas e onde agir. O desenho deve contemplar o retorno ao envio depois das correções. Esse retorno faz parte da tarefa.
Comece o fluxo registrando a posição em que a pessoa está quando aciona o botão, o que o servidor devolve e qual região recebe atenção quando a página mostra o resultado. Se o navegador carrega outra página, essa página precisa conservar a etapa e os dados adequados. Se a tela atual se atualiza, a mudança precisa ficar perceptível. Em ambos os casos, projete a sequência usando conteúdo realista e tente concluí-la sem conhecer a ordem dos campos de antemão.
Faça do resumo um índice acionável
Coloque o resumo antes do formulário e use um título como “Revise os dados para enviar o pedido”. Abaixo, liste uma pendência por item, na ordem em que os controles aparecem. “Informe um e-mail completo, como nome@exemplo.com” indica uma correção. “E-mail inválido” deixa a pessoa adivinhar se faltou um caractere, se existe uma restrição de domínio ou se ocorreu um problema com o site. A documentação sobre notificações de formulário do W3C reúne técnicas para combinar retorno geral e retorno perto dos campos.
Vincule cada item ao controle que pode resolver a pendência. Num grupo de data com dia, mês e ano, determine qual é a entrada mais útil para receber foco. Se a mensagem aponta especificamente para o ano, o primeiro campo nem sempre é o melhor destino. Em uma pergunta de escolha única sem resposta, o primeiro controle habilitado do grupo pode ser uma chegada compreensível. Teste a solução com o conteúdo de erro presente e também com a estrutura do formulário após mudanças de seção ou idioma.
Repita a informação no ponto de correção
O resumo orienta o deslocamento. A mensagem local acompanha o momento em que a pessoa altera o campo. A referência do GOV.UK Design System para resumos de erro recomenda usar a mesma mensagem nos dois lugares. Na prática, isso poupa uma tradução mental entre “Verifique o seu cadastro”, no topo, e “E-mail fora do formato esperado”, perto da entrada. Quem chega pelo link reconhece a instrução e sabe por que o foco foi parar ali.
Mantenha rótulo, texto de ajuda e erro distinguíveis. Um rótulo como “Data de montagem” identifica o dado. A ajuda pode explicar o formato esperado. O erro indica a condição que impediu o envio e, quando conhecida, a ação necessária. No código, associe a mensagem ao campo para que a informação acompanhe sua leitura. A equipe também deve avaliar como a mudança é anunciada quando o erro desaparece. O guia sobre UX writing para formulários traz exemplos úteis para ajustar rótulos, instruções e confirmações como partes da mesma conversa.
Preserve o trabalho e explique o que precisa ser refeito
Depois de uma validação malsucedida, as respostas corretas devem continuar disponíveis sempre que isso for possível. Imagine redigitar as medidas de cinco estruturas porque o CEP tinha um dígito a menos. A sensação de perda se agrava quando a página parece intacta até a pessoa descer e descobrir que os campos voltaram em branco. Ao especificar a recuperação, registre quais valores são repostos e quais precisam ser informados novamente por razões técnicas ou de segurança.
Anexos merecem uma regra explícita. Se o arquivo já foi recebido e o sistema ainda pode usá-lo, mantenha o nome e o estado do upload visíveis. Se precisa ser selecionado novamente, diga isso perto do controle e, quando a pendência bloquear o envio, no resumo. Indique o limite aplicável antes da seleção e na mensagem em caso de falha. Valide o percurso de substituição com um arquivo permitido e confira se a interface mostra com clareza qual versão será anexada à nova tentativa.
Cuide do foco em vez de confiar na rolagem
Mover a página até o resumo e mover o foco são ações diferentes. Após um envio com erros, experimente encaminhar o foco ao resumo, de maneira que a pessoa consiga ler a explicação e avançar até seus links. Ao acionar um item, o foco deve seguir para um ponto que permita corrigir o campo. Em um celular com cabeçalho fixo, confirme que a chegada também é visível. O usuário pode ter ampliado a tela, e a altura do cabeçalho pode mudar justamente nesse cenário.
A navegação de retorno também importa. Depois de corrigir a data, a próxima tabulação deve seguir uma ordem que faça sentido naquela seção. Evite depender de um salto automático para a próxima pendência enquanto a pessoa digita. Se a correção altera outro campo, explique o vínculo onde ele se torna relevante. O artigo sobre foco visível em interfaces ajuda a especificar o indicador de foco para os links do resumo e para o destino, inclusive quando os campos usam cores de validação.
Separe correção de campo de falha de serviço
Se o servidor informa que a data escolhida ficou indisponível, há uma ação concreta no formulário. Se o servidor está temporariamente fora do ar, destacar a data e o e-mail como incorretos cria trabalho inútil. Uma mensagem geral pode dizer “O envio não foi concluído. Seus dados estão nesta página. Tente novamente em instantes”, quando a aplicação de fato preserva os dados. Se o sistema ainda não sabe se recebeu o pedido, deixe essa incerteza clara e dê uma forma de verificar antes de repetir a operação.
Desenhe também o caso em que a confirmação nunca chega ao navegador, mas o pedido foi registrado. Dependendo da implementação, uma segunda tentativa pode criar um registro duplicado. Esse cenário precisa de uma resposta técnica e de conteúdo que descreva o estado real. Na revisão com desenvolvimento, combine o que significa “enviado”, de onde vem o número de protocolo e em que momento se pode apresentá-lo. A recuperação fica mais confiável quando a interface e o serviço usam a mesma definição de sucesso.
Teste a correção com situações que puxam o fluxo em direções diferentes
Prepare três envios fictícios. O primeiro deve falhar em um campo perto do início. O segundo deve falhar em campos separados por uma seção extensa. O terceiro deve simular indisponibilidade do serviço, sem entrada incorreta. Peça a alguém para completar cada cenário com teclado e acompanhe a ordem de foco. Depois repita em tela pequena e com leitor de tela. Observe o que a pessoa escuta quando o resumo aparece e o que encontra ao seguir o segundo link.
Inclua um teste em que apenas dois dos três problemas originais são corrigidos. O novo resumo deve representar as pendências da nova tentativa. Verifique se a contagem, quando exibida, corresponde aos itens e se um erro de grupo aparece uma única vez. Confira as mensagens em português em larguras estreitas e com ampliação. Um item de duas linhas precisa continuar parecendo um link, e o contorno de foco deve abranger uma área reconhecível. Registre o que acontece antes e depois de uma tentativa bem-sucedida.
Entregue uma especificação que possa ser conferida
Para cada regra, anote o momento da validação, a mensagem, o destino do link e o que a aplicação preserva. Inclua um exemplo de entrada incorreta e um exemplo aceito, especialmente para campos com dependências. Se o produto tem regras no navegador e no servidor, combine qual fonte decide o resultado final e como o componente apresenta essa decisão. Assim, o protótipo e os testes de implementação podem discutir o mesmo comportamento.
Termine o teste no ponto em que a pessoa espera concluir o trabalho. Depois de corrigir os campos, ela consegue localizar o botão, enviar e identificar a confirmação? Se recebeu um protocolo, consegue guardá-lo e entender o que acontece em seguida? Esse desfecho indica se o resumo serviu à tarefa. O critério editorial de cada mensagem pode ser simples. Ela deve dizer o suficiente para que alguém avance com os dados que já tem e saiba onde buscar o restante.