O que o sistema promete
O formulário deve obter contexto para uma resposta útil sem exigir uma especificação. Comece pela próxima decisão da equipe: se a demanda se encaixa, quem a analisa e qual dúvida conversar. Todo campo obrigatório deve atender a uma dessas decisões.
Comparar opções práticas
Nome, endereço de resposta e descrição simples podem bastar. Tipo de projeto ou faixa de orçamento ajudam quando as opções são claras e aceitam incerteza. Não exija telefone só por constar em um modelo interno. A orientação W3C trata rótulos, instruções e feedback como partes funcionais.
Testar a jornada completa
Imagine uma fundadora com ideia inicial e sem prazo. Ofereça uma opção honesta, sem forçar uma data inventada. Se o e-mail for inválido, indique o campo, explique a correção e preserve a descrição. Depois do envio, diferencie solicitação salva e falha de transmissão. Ninguém deve adivinhar se clicar novamente cria duplicidade.
Tornar a recuperação visível
Não use placeholder como único rótulo nem cor como único aviso de erro. Mostre erros perto dos campos e resumo acessível quando necessário. Teste teclado, zoom, traduções longas e conexão lenta. Sucesso precisa representar recebimento durável e um próximo passo verdadeiro, sem inventar prazo de resposta.
Revisar o formulário como conversa e transação
Anote por que cada campo é necessário agora, quem lê e o que ocorre se a pessoa não sabe. Se orçamento orienta o contato, use faixas reais da equipe e opção indefinida. Não obrigue tamanho, arquitetura ou prazo inventados para validar. Contexto opcional pode vir depois da resposta, com propósito mais claro.
Teste correções com formulário preenchido: descrição longa, e-mail errado e envio. A mensagem explica, preserva dados válidos e facilita chegar ao campo. Mova foco ao resumo com cuidado e anuncie sem interromper a digitação repetidamente. Repita com leitor de tela e texto ampliado; proximidade visual não basta para associar erro e entrada.
Confira o servidor. Resposta perdida após salvar difere de pedido não recebido. Repetições devem chegar ao mesmo registro e confirmar recebimento durável. Entrada na fila não significa notificação entregue. Explique o próximo passo e como pedir ajuda. Use dados fictícios e destino local; examine solicitação salva, notificação e confirmação.
Evidências de aceite do formulário
| Situação | Experiência esperada |
|---|---|
| Resposta desconhecida | Opção indefinida ou campo opcional permite responder sem inventar. |
| Campo inválido | Erro identifica o campo, explica correção e preserva o restante. |
| Conexão cai após salvar | Repetição segura encontra a mesma solicitação sem duplicidade. |
| Notificação atrasada | O recebimento permanece; não há falsa entrega nem exigência de reenviar tudo. |
Exemplos para revisão
Quais respostas mudam a próxima ação? Alguém não técnico responde tudo que é obrigatório? Há repetição segura após queda de rede? Revise um envio comum e um malsucedido como jornadas completas, não apenas a tela vazia.