O cânone dos formulários: todo campo é uma pergunta

Um formulário é o momento em que a interface para de apresentar e começa a perguntar. Todo campo é uma pergunta feita a alguém que gostaria de estar fazendo outra coisa, o que significa que todo campo desnecessário é uma imposição e todo campo confuso é uma pequena traição. O ofício dos formulários se reduz a um cânone que cabe na cabeça: pergunte menos, em uma coluna só, com rótulos visíveis; aceite as respostas do jeito que as pessoas naturalmente as dão; dispare a validação quando a pessoa termina um pensamento, e não no meio da digitação; escreva erros que digam como corrigir o problema; e nunca, em hipótese alguma, jogue fora o que o usuário digitou. Quase todo atrito de formulário que se vê por aí é a violação de uma dessas linhas. {.answer-block}

TL;DR

• Um formulário é uma conversa, então pergunte como uma pessoa perguntaria: o menor número possível de perguntas, em uma coluna ordenada, agrupadas por assunto — e cada campo precisa se justificar diante do custo de perguntar.
• O layout já está resolvido: coluna única, rótulos acima do campo, largura do campo sugerindo o tamanho da resposta. Formulários de várias colunas e truques de rótulo flutuante trocam compreensão real por elegância imaginária.
• Aceite as respostas do jeito que as pessoas dão. Corte o espaço perdido, aceite o telefone em qualquer formato, mantenha o campo inteiro em vez de dividi-lo em três caixas — normalizar é trabalho do software, não do usuário.
• Valide ao sair do campo, não a cada tecla, e escreva erros que ensinem: o que deu errado, como corrigir, ao lado do campo em questão.
• O que o usuário digitou é sagrado. Um envio que falha e limpa o formulário, ou um botão desabilitado que não explica o motivo, transforma um participante disposto em um ex-participante.

Por que todo campo é uma pergunta

Trate o formulário como a transcrição de uma entrevista e a qualidade dele fica evidente. Um entrevistador competente pediria seu número de fax por hábito? Exigiria sua data de nascimento antes de explicar por quê? Interromperia você no meio do e-mail para anunciar que ele é inválido? Esqueceria tudo o que você disse porque o seu CEP tinha um espaço? Cada um desses gestos tem um equivalente em formulários que estão no ar, e os usuários os sentem exatamente como sentiriam o entrevistador: como grosseria.

Esse enquadramento também produz a primeira e mais importante regra, anterior a qualquer layout ou estilo: todo campo precisa justificar sua existência diante do custo de perguntar. Cada pergunta a mais aumenta o abandono; cada resposta coletada é um dado que você passa a armazenar, proteger e pelo qual passa a responder. O movimento mais forte no design de formulários é a exclusão — o campo que você remove supera qualquer polimento que pudesse aplicar nele. O comprovante canônico é o da Expedia: remover um único campo opcional, “Company”, do formulário de reserva valeu, segundo os relatos, cerca de 12 milhões de dólares por ano — os clientes vinham escrevendo ali o nome do próprio banco e depois falhavam na verificação de endereço. Um campo, honestamente interrogado, venceu qualquer redesenho. “Opcional” não é justificativa; é uma imposição menor, mas ainda assim uma imposição. Pergunte o que é necessário para concluir a transação, marque como opcional o raro campo opcional e empurre todo o resto para depois, quando a relação já tiver merecido. (A corrente oposta prefere colocar asterisco em todo campo obrigatório; quando quase tudo é obrigatório, os asteriscos viram papel de parede.)

As regras de layout

O layout de formulário é um dos poucos cantos do design em que as evidências estão praticamente resolvidas, o que faz de qualquer desvio uma escolha contra o usuário:

Uma coluna. Um formulário é uma sequência de perguntas, e a coluna única deixa essa sequência sem ambiguidade: responda, desça, termine. Layouts de várias colunas forçam uma decisão de ordem de leitura em cada linha — para o lado ou para baixo? — e as pessoas resolvem isso de maneira inconsistente, pulando campos que nunca viram. Na comparação de eye tracking mais conhecida, os mesmos campos em coluna única foram concluídos cerca de quinze segundos mais rápido do que divididos em duas. As exceções são composições genuínas, que se leem como uma resposta só: cidade / estado / CEP na mesma linha, uma data em três partes. Isso é uma pergunta vestindo três campos, não três perguntas.

Rótulos acima do campo, sempre visíveis. Rótulos ao lado do campo criam um trajeto irregular para o olho; rótulos dentro do campo (o placeholder fazendo as vezes de rótulo) somem no instante em que a pessoa começa a digitar, que é justamente quando ela precisa deles — na metade de um formulário longo, cada campo preenchido vira uma caixa-surpresa do “o que era isso mesmo?”. Os rótulos flutuantes, aquele meio-termo animado, sobrevivem ao foco, mas encolhem ao tamanho de legenda e fazem campos vazios parecerem preenchidos: uma versão mais gentil da mesma troca, ainda paga em compreensão. Placeholder serve para dica de formato (“[email protected]”), nunca para a pergunta em si.

A largura do campo é informação. Um campo de CEP tão largo quanto um campo de endereço mente sobre o formato da resposta. Dimensionar os campos conforme o conteúdo esperado — curto para CEP, longo para endereço — é o mesmo ofício do espaçamento que codifica agrupamento: geometria comunicando em silêncio.

Agrupe por assunto e deixe o espaço fazer o agrupamento. Contato, entrega, pagamento — blocos de perguntas relacionadas com costuras claras entre eles, e essas costuras feitas de espaço em branco, não de caixas ou linhas. Um formulário que se lê como três pequenos assuntos é psicologicamente menor do que os mesmos campos empilhados em uma laje indiferenciada.

As regras de entrada

O tema do design de entrada cabe em uma frase: normalizar é trabalho do software. Qualquer que seja o peso da formatação, quem carrega é a máquina, porque é ela quem se importa.

• Aceite respostas desleixadas. Corte os espaços em branco — o espaço no fim de um e-mail preenchido automaticamente já derrubou mais logins do que deveria. Aceite telefones com hífen, ponto, espaço, parênteses ou nada disso. Aceite o número do cartão com ou sem intervalos. Se dá para interpretar, interprete; recusar 555 867 5309 porque você queria 5558675309 é obrigar o usuário a rodar na mão o seu código de formatação de string.
• Nunca divida o que o usuário enxerga como uma coisa só. Telefone em três caixas, data em três menus suspensos, código de verificação em seis células de um caractere com salto de foco feito à mão — cada um deles quebra uma resposta mental em um quebra-cabeça de navegação e costuma estragar o colar, o método de entrada mais eficiente que o usuário tem. (A exceção das composições, vinda das regras de layout, continua valendo: uma data em três partes digitadas está de bom tamanho — o pecado é o cerimonial do menu suspenso e o foco roubado, não a adjacência. E, para códigos, a resposta duradoura é um campo único com autocomplete="one-time-code".)
• Chame o teclado certo. Em dispositivos de toque, type="email", inputmode="numeric" e companhia são a diferença entre digitar um endereço em um teclado feito para isso e caçar o @ por camadas de símbolos. Isso custa um atributo.
• Deixe o navegador ajudar. Tokens de autocomplete corretos transformam um checkout de doze campos em dois toques para quem já é cliente. Desligar o preenchimento automático em campos de endereço e pagamento — em geral superstição herdada de uma revisão de segurança que nunca aconteceu — descarta o maior ganho de velocidade disponível para um formulário.
• Encontre o dedo onde ele pousa. Campos, seus botões e qualquer outra coisa tocável respeitam a área mínima de toque da plataforma — 44 pt no iOS, 48 dp no Android. Um campo compacto e elegante que o polegar não acerta com segurança é um formulário de desktop fantasiado de celular.

As regras de teclado e preenchimento automático custam, juntas, alguns atributos:

<input type="tel" autocomplete="tel">              <!-- phone keypad, autofilled -->
<input inputmode="numeric" autocomplete="one-time-code">  <!-- digit pad, code autofills -->

As regras de validação

O momento da validação é onde os formulários mais costumam ser hostis, e a regra é simples: responda quando a pessoa terminar um pensamento. Disparar a cada tecla é gritar “e-mail inválido!” para alguém que digitou quatro caracteres — criticar frases antes que elas terminem. A escola oposta valida apenas no envio, e tem um defensor de peso: o design system do GOV.UK faz exatamente isso, combinando o envio com um resumo de erros no topo da página, porque um resumo pode ser anunciado a leitores de tela e dá a quem usa teclado um único ponto de partida para os reparos. É uma posição coerente, calibrada para serviços em que a acessibilidade é a restrição determinante. Para a maioria dos formulários de produto, ainda assim fico com a validação ao sair do campo: a pessoa conclui o campo, segue adiante e recebe o retorno na costura entre dois pensamentos, enquanto o pensamento ainda está quente. (Um refinamento: um campo que já estava inválido pode revalidar a cada tecla, para que o estado vermelho suma no instante em que a correção chega, em vez de ficar um campo inteiro atrasado.)

Escrever o erro passa pelo mesmo teste de conversa. Um erro não é um veredicto; é uma instrução de reparo. “Entrada inválida” não passa — inválida como? “Falta o @ neste endereço de e-mail” passa. (E a instrução precisa ser verdadeira em relação à regra real: números de cartão legitimamente têm de 12 a 19 dígitos, então “deve ter 16 dígitos” não é mensagem de erro, é um defeito de validação que rejeita todo portador de Amex.) Coloque a mensagem junto ao campo a que ela se refere, em texto — só a cor exclui quem não distingue cores, e o texto é o único canal que um leitor que não renderiza nada enxerga — e amarre-a ao campo de forma programática (aria-describedby), para que a tecnologia assistiva anuncie o erro junto com o campo em vez de deixá-lo perdido na tela. Mantenha o tom factual: o trabalho do formulário é levar a pessoa até o fim, não julgar culpa. A regra inteira em um par:

<!-- before: a verdict, visually nearby, programmatically stranded -->
<label for="email">Email</label>
<input id="email" type="email">
<span class="error">Invalid input</span>

<!-- after: a repair instruction, announced with its field -->
<label for="email">Email</label>
<input id="email" type="email"
       aria-invalid="true" aria-describedby="email-err">
<span id="email-err">This email address is missing its @</span>

Duas regras estruturais fecham o conjunto. Nunca desabilite o botão de envio como estratégia de validação — um botão morto e sem explicação é um enigma, e o próximo movimento do usuário é ir embora; deixe enviar e então mostre exatamente o que precisa de atenção. (Desabilitar durante um envio em andamento, para evitar cobrança dupla, é outra coisa: isso é estado, não julgamento.) E a lei mais profunda do cânone: um envio que falha preserva cada tecla do trabalho da pessoa. Um formulário que se limpa no erro pegou minutos de esforço alheio e queimou tudo diante de quem os investiu. Nenhum refinamento visual se recupera disso.

O cânone como checklist

A forma prática de tudo isso, aplicada a qualquer formulário antes de ele ir ao ar:

Em um design system, essas regras endurecem nos próprios componentes de formulário — um campo de texto que já vem com o slot de rótulo acima, o slot de erro abaixo e o momento de validação embutido —, de modo que o cânone vale por padrão e desviar dele dá trabalho. É o mesmo argumento de sistematização dos tokens de movimento: codifique a decisão uma vez ou rediscuta-a em cada funcionalidade.

Perguntas frequentes

Um formulário deve ter uma ou duas colunas?

Uma. A coluna única deixa a ordem das respostas sem ambiguidade e é mensuravelmente mais rápida de preencher; layouts de várias colunas provocam campos pulados porque as pessoas resolvem a ordem de leitura de formas diferentes. A exceção é a resposta composta — cidade / estado / CEP —, que é uma pergunta expressa em campos adjacentes.

Quando a validação do formulário deve disparar?

Ao sair do campo — quando o usuário o deixa — e não a cada tecla; na maioria dos formulários de produto, também não guardada para o envio. A validação por tecla critica respostas inacabadas; a validação só no envio entrega todas as falhas de uma vez, embora o resumo de erros no envio do GOV.UK seja a escolha certa onde o anúncio por leitor de tela é a restrição determinante. Um campo já marcado como inválido pode ser reavaliado a cada tecla, para que o erro suma assim que for corrigido.

Posso usar o texto de placeholder como rótulo do campo?

Não. O placeholder no papel de rótulo desaparece quando a pessoa começa a digitar, exatamente quando ela precisa lembrar a pergunta, e transforma cada campo preenchido em dado sem identificação na hora da conferência. Mantenha um rótulo visível acima do campo e reserve o placeholder para exemplos de formato.

O botão de envio deve ficar desabilitado até o formulário estar válido?

Não. Um envio desabilitado sem explicação é um beco sem saída que o usuário tem de diagnosticar sozinho. Mantenha-o ativo e, no envio, exponha cada campo pendente com um erro específico e instrutivo ao lado — preservando tudo o que já foi digitado.