Boas Práticas de Design de Formulários: 10 Regras para Web e Mobile

O custo de um formulário ruim

Um formulário ruim é um imposto estratégico sobre cada real que você gastou para trazer alguém até a página. As taxas de conclusão para formulários de cadastro, checkout e onboarding ficam em torno de 12% quando há fricção. Remova a fricção e esse número sobe para mais de 50%.

A diferença quase nunca é copy ou branding. São as dez regras, aplicadas de forma consistente.

Veja ao vivo em notion.so

Formulários de captação de leads estilo Salesforce com 30 campos existem porque alguém mapeou um schema de banco de dados em uma página e chamou de formulário. O usuário não pediu isso. Ele apareceu pelo produto, e sua lógica de qualificação custou o lead.

Regra 1: Uma coluna, uma tarefa por tela

Uma coluna, sempre. Layouts com várias colunas parecem eficientes em um grid do Figma e destroem as taxas de conclusão numa tela real.

O olho lê da esquerda para a direita e espera continuidade. Quando os campos se dividem em duas colunas, o usuário tem que decidir qual caminho seguir, e essa micro-decisão adiciona fricção antes mesmo de ele digitar um único caractere.

O fluxo de cadastro do Notion é uma única coluna centralizada com um campo promovido por vez no mobile. O formulário parece rápido porque pede uma coisa só. Essa é a regra.

Regra 2: A posição do label importa mais do que o estilo do label

Labels ficam acima do campo. Não dentro, não ao lado. Acima, sempre visíveis.

O texto de placeholder usado como label desaparece no momento em que o usuário começa a digitar. Nesse ponto, ele precisa limpar o campo para lembrar o que estava preenchendo. O fluxo de onboarding do Mercury usa labels persistentes acima do campo em cada input para que o contexto nunca se perca durante o preenchimento.

Veja ao vivo em mercury.com

Labels flutuantes, que animam a partir da posição de placeholder ao focar, são um meio-termo aceitável, mas exigem contraste preciso e timing cuidadoso para serem acessíveis. Na dúvida, coloque o label acima e deixe-o lá.

A pesquisa de UX por trás do posicionamento de labels é abordada em profundidade em nosso guia de métodos de pesquisa UX.

Regra 3: A ordem dos campos segue a realidade do usuário, não o schema do banco de dados

A sequência dos seus campos deve corresponder a como uma pessoa pensa sobre a tarefa, não a como os engenheiros estruturaram o modelo de dados.

Um formulário de checkout que pede o endereço de entrega antes de confirmar o carrinho coloca o peso do contexto sobre o usuário. O Stripe Checkout, a referência canônica para UX de formulários de checkout hospedado, sequencia o formulário em três etapas:

1. E-mail (quem é você)
2. Pagamento (como você vai pagar)
3. Endereço (para onde vai)

Essa é a sequência que um ser humano razoável usaria pessoalmente. Quando o banco de dados dirige a ordem dos campos, você obtém formulários que pedem o CEP antes do país, ou o cargo antes do nome da empresa.

Regra 4: Valide inline, nunca no submit

Valide o campo no momento em que o usuário sai dele, não quando ele clica em enviar.

A validação no submit significa que o usuário preenche um formulário com dez campos, clica no botão e recebe uma parede de erros vermelhos. Cada erro é uma tarefa de correção, e cada tarefa de correção arrisca perdê-lo de vez. A validação inline, acionada no blur, apresenta o erro antes de o usuário seguir em frente.

O login do Apple ID valida o formato do e-mail no blur e confirma a disponibilidade da conta antes de o botão de submit ficar ativo. Esse sequenciamento previne duas categorias de erro de uma vez. Os padrões de interação por trás disso são abordados em nosso guia de design de microinterações.

Regra 5: Mobile-first significa teclados mobile

Todo tipo de campo deve invocar o teclado correto. Isso é 80% do design de formulários mobile.

Se um campo pede número de telefone e o teclado de texto padrão aparece, o formulário está quebrado antes de o usuário digitar qualquer coisa. Use inputmode="numeric" em campos numéricos, type="email" para mostrar a tecla @, e inputmode="decimal" para preços. iOS e Android suportam toda a gama de modos de input.

O teclado é o dispositivo de entrada principal no mobile. Especificar o errado transforma um formulário visualmente bem projetado em algo frustrante.

Para a base mais ampla de mobile-first onde esses padrões se encaixam, veja fundamentos de design responsivo para web.

Regra 6: Progresso, microcopy e o problema do formulário longo

Se o formulário exige mais de cinco campos, mostre ao usuário onde ele está no fluxo.

O fluxo de reserva em várias etapas do Airbnb mostra um indicador de progresso com etapas nomeadas ao longo de todo o processo. Usuários que podem ver que estão 60% concluídos têm uma taxa de conclusão significativamente maior do que usuários sem nenhum ponto de referência.

Veja ao vivo em tally.so

O Tally adota uma abordagem diferente para seus formulários incorporáveis: uma pergunta por vez com uma barra de progresso persistente no topo, o que consistentemente supera formulários longos de página única em seus testes de usuário documentados.

O microcopy faz o mesmo trabalho. "Etapa 2 de 4" é mais honesto do que uma barra de progresso simples. "Precisamos disso para verificar sua identidade" é mais útil do que um campo sensível sem label.

Regra 7: Mensagens de erro são instruções, não acusações

Escreva mensagens de erro no imperativo, não como acusação.

"Este campo é obrigatório" é uma acusação. "Insira seu endereço de e-mail para continuar" é uma instrução. O usuário já sabe que algo deu errado. O que ele precisa é da solução.

O melhor copy de erro nomeia a condição exata e a ação exata: "A senha deve ter pelo menos 8 caracteres e incluir um número." O Stripe Checkout faz isso com precisão. A mensagem aparece no blur, nomeia o problema e desaparece no momento em que a condição é resolvida.

Não há estado vermelho persistente. Simplesmente funciona.

Regra 8: Autofill é uma feature, não uma reflexão tardia

O atributo autocomplete informa ao navegador exatamente o que preencher. Use-o em cada campo.

Um formulário de checkout com atributos de autocomplete corretos leva cerca de 12 segundos para ser concluído em um celular com dados salvos. Sem eles, o mesmo formulário leva dois minutos porque o usuário digita tudo manualmente. Essa diferença de 108 segundos é onde vive a maior parte do abandono de checkout mobile, e não custa nada para fechar. O guia de biblioteca de componentes de UI mostra como incorporar esses atributos nos componentes de formulário do seu design system para que nunca estejam ausentes.

Regra 9: O botão de submit decide tudo

O botão de submit é o contrato. Seu label, estado e posição sinalizam se o usuário pode confiar no que acontece a seguir.

Um botão acinzentado sem explicação diz ao usuário que o formulário está quebrado, mas não por quê. Isso é um beco sem saída. Um botão com label "Enviar" não diz nada ao usuário sobre o que ele está concordando.

"Criar minha conta", "Obter meu teste grátis" e "Começar a criar" são todos mais honestos. Desative o botão apenas quando puder explicar o motivo na interface. O Tally usa copy de botão específico para a ação em cada etapa do seu construtor de formulários, e isso contribui diretamente para suas taxas de conclusão acima da média em fluxos B2B incorporados.

Regra 10: Teste com dedões reais, dados reais, latência real

Testar um formulário em um navegador de desktop com wifi rápido não diz nada de útil sobre se ele funciona.

Teste em um dispositivo Android intermediário com uma conexão 4G com dados de comprimento real em cada campo:

• Um nome com um caractere acentuado
• Um endereço com número de apartamento na segunda linha
• Um e-mail com 22 caracteres
• Um primeiro nome com 1 caractere

Casos extremos do mundo real quebram formulários que parecem limpos no Figma. A latência real revela se as chamadas de validação estão bloqueando o input ou rodando de forma assíncrona. Essa distinção é invisível em um simulador de navegador e catastrófica em um celular com dois barrões de sinal.

Precisa de uma auditoria de formulário no seu fluxo de cadastro, checkout ou onboarding? A Brainy faz a auditoria completa das dez regras em telas reais, dados reais e números reais de conversão.

Onde designers ainda lançam os piores formulários

Os piores formulários em produção hoje compartilham três padrões:

• Formulários de captação de leads enterprise: telas de qualificação estilo Salesforce com 30 campos, seletores obrigatórios de "receita anual" e sem validação inline
• Fluxos de onboarding em várias etapas que não salvam o progresso: uma ligação na etapa 7 de 9 manda o usuário de volta para a etapa 1
• Fluxos de checkout construídos antes de o mobile ser primário, nunca reconstruídos: cada campo numérico ainda usa type="text" porque "funciona bem no desktop"

As escolhas de estado de erro nos três casos também tendem a falhar nos requisitos de contraste; padrões de contraste de cor acessíveis corrigem esse ponto de falha específico.

O fio condutor nos três: o formulário foi projetado para o sistema, não para a pessoa que o preenche. A solução é a mesma.

Execute as dez regras. Comece pelo mobile. Deixe o banco de dados resolver seu próprio schema.

---

FAQ

Quantos campos um formulário deve ter?

O mínimo que o resultado exige. O número certo é aquele em que remover mais um quebraria o produto. Cada campo que você adiciona reduz a taxa de conclusão. Comece do zero e adicione apenas o que for obrigatório.

Devo usar formulários em várias etapas ou de página única?

Para mais de cinco campos, várias etapas quase sempre supera página única. O requisito é progresso visível. Sem ele, formulários em várias etapas têm desempenho pior do que os de página única porque o usuário não faz ideia de quanto tempo a jornada dura. Nomeie as etapas e mostre onde estão na sequência.

Qual é a melhor forma de marcar campos obrigatórios?

Marque os campos opcionais, não os obrigatórios. Se a maioria dos campos for obrigatória (o que deveria ser, dada a regra acima), marcar cada campo com um asterisco vermelho é ruído visual.

Marque as exceções. "Opcional" ao lado de um campo é uma informação significativa. Um asterisco ao lado de cada campo não é.

Como lidar com requisitos de senha sem punir o usuário?

Mostre os requisitos antes de o usuário começar a digitar, não depois que ele falhar. Uma pequena checklist que se ativa conforme cada condição é atendida tem desempenho melhor do que uma parede de erros pós-submit. O Apple ID e a maioria dos fluxos de autenticação atuais usam esse padrão. O feedback é ao vivo, positivo e nunca punitivo.

A largura do campo comunica algo?

Sim, e os usuários leem isso. A largura do campo sinaliza o comprimento esperado do input. Um campo curto sinaliza uma resposta curta. Um campo de largura total sinaliza uma resposta mais longa.

Combine a largura do campo com o comprimento esperado do input onde o layout permitir. Um campo de CEP em largura total parece um erro. Uma área de texto para um endereço de rua parece excessiva. Combine o container com o conteúdo esperado.

O que causa o maior abandono de formulários mobile?

Tipo de teclado errado é o número um. Autofill não funcionando é o número dois. Ambos são falhas silenciosas: o formulário parece correto, o usuário simplesmente não consegue completá-lo de forma eficiente.

Corrija ambos com dois atributos por campo. O investimento é de 15 minutos. O retorno é mensurável em conversão de checkout dentro do mesmo sprint.