Lei de Postel: o formulário que entende o cliente vende

O telefone estava certo, o cliente sabe o próprio número de cor, e mesmo assim o site respondeu "formato inválido". Essa recusa acontece no formulário, a última etapa antes da conversão. A Lei de Postel, uma regra escrita para a internet em 1980, explica como parar de perder essa venda.

O mesmo telefone, três jeitos de digitar. O formulário rígido exige um formato exato e recusa os outros dois, mesmo com todos os números certos. O tolerante entende os três e guarda um só, no padrão do sistema.

Os mesmos dados, digitados de vários jeitos: veja quem entende

Cada linha das tabelas abaixo é um dado digitado de um jeito que muita gente usa. Na coluna do meio, a resposta de um validador rígido, como o de muitos sites. Na da direita, a de um validador que segue a Lei de Postel.

Celular com DDD (o validador rígido exige exatamente "(11) 98765-4321")

CPF (o validador rígido exige exatamente "000.000.000-00")

CEP (o validador rígido exige exatamente "00000-000")

Repare no CPF terminado em 26: o validador rígido aceita, porque o desenho está certo, e o de Postel recusa, porque o dígito verificador não confere.

Os números de exemplo são fictícios. O CPF é validado pelos dígitos verificadores, como faz a Receita.

Uma regra de rede que virou regra de formulário

Jon Postel foi um dos arquitetos da internet. Cientista da computação da Universidade do Sul da Califórnia, editou a série de documentos que define os protocolos da rede, as RFCs, de 1969 até morrer, e comandou a IANA, o órgão que distribui endereços e domínios. Morreu em 16 de outubro de 1998, aos 55 anos, depois de uma cirurgia no coração.

Em janeiro de 1980, na especificação do protocolo IP, a RFC 760, ele escreveu a frase que virou princípio:

O raciocínio era prático. A internet ia ligar computadores de fabricantes diferentes, com programas escritos por equipes diferentes. Se cada um recusasse qualquer mensagem levemente fora do padrão, nada conversaria com nada. Então cada sistema deveria enviar dados perfeitamente dentro da norma e aceitar dados imperfeitos, desde que desse para entender o que se queria dizer.

O princípio da robustez. No site, quem envia é você: mensagens, confirmações e dados exibidos sempre no formato certo. Quem recebe também é você: o que o cliente digita entra por um funil largo.

Traduzido para UX, a regra fica assim: seja rigoroso no que o site mostra e generoso no que o site aceita. O cliente não tem obrigação de saber o formato que o seu banco de dados prefere. Esse problema é do sistema.

Por que recusar um dado certo custa tão caro

Para o cliente, uma mensagem de "formato inválido" num dado que ele sabe de cor soa como acusação. Ele digitou o próprio telefone. Ele sabe que está certo. A conclusão dele é "este site não funciona".

E o erro chega no pior momento possível: no formulário, que é a última etapa antes da conversão. O cliente já escolheu, já decidiu, já se convenceu. Só falta entregar os dados. Cada recusa desnecessária ali é uma venda que estava pronta e escapou.

Às vezes o dado está errado de verdade. Mesmo aí, Postel ajuda: o site formata o que foi digitado, mostra ao cliente e explica exatamente o que falta, no lugar de devolver um "inválido" genérico.

Quem foi generoso e quem pagou por ser rígido

O ponto certo fica no meio. Rigidez no formato perde clientes. Permissividade no conteúdo gera pedido com telefone que não existe, boleto para CPF errado e entrega no endereço errado.

O que o brasileiro digita, e o seu site precisa entender

• Celular com ou sem parênteses, com ou sem hífen, com +55 na frente e até com o zero e o código de operadora de quem aprendeu a discar longa distância.
• CPF e CNPJ com pontos, sem pontos, copiado de um PDF com espaços no meio.
• CEP com ou sem hífen, e às vezes com um ponto: 01.310-100.
• Valores com vírgula decimal e ponto de milhar, "R$ 1.234,56", e não no padrão americano.
• Datas no formato dia, mês e ano, com barra, hífen ou ponto, e com ano de dois ou quatro dígitos.
• Nomes com acento, cedilha, apóstrofo e quatro sobrenomes.
• E-mails colados com um espaço no fim ou com letra maiúscula no começo, porque o teclado do celular corrigiu.

Nenhum desses é erro do cliente. São jeitos legítimos de escrever o mesmo dado. O site que trata isso como erro está, literalmente, recusando dinheiro.

Como aplicar a Lei de Postel em cinco passos

• Limpe antes de validar. Remova espaços nas pontas, pontos, hífens, parênteses e barras. Valide só o que sobrou.
• Normalize e mostre. Depois de entender, reformate no padrão oficial e exiba para o cliente: ele confere de bate-pronto.
• Valide o significado, não o desenho. CPF tem dígito verificador. CEP pode ser consultado. Celular tem nove dígitos depois do DDD. Isso importa. Parêntese não importa.
• Explique o erro real. "Faltou um dígito", "esse CEP não existe", "confira o dígito final do CPF". Nunca só "inválido".
• Nunca apague o que foi digitado. Se der erro, mantenha o conteúdo no campo e destaque o problema.

Checklist: seu formulário entende o cliente?

Abra o seu formulário mais importante e tente preencher cada campo de três jeitos diferentes.

Aceitação

• Telefone aceita qualquer pontuação e +55
• CPF e CNPJ aceitos com ou sem pontuação
• CEP aceito com ou sem hífen
• Cartão aceita espaços
• Nomes com acento, apóstrofo e nomes longos aceitos

Normalização

• Espaços extras no início e no fim são removidos
• E-mail convertido para minúsculas
• Dado reformatado e exibido para conferência
• Colar texto no campo funciona sem quebrar a máscara
• Valores aceitam vírgula decimal

Erros

• CPF validado pelo dígito verificador
• Mensagens dizem exatamente o que está errado
• O erro aparece junto do campo, não no topo da página
• Nenhum campo é apagado quando há erro
• Erro só aparece depois que o cliente sai do campo

Os erros mais caros, em ordem de frequência

• Máscara que trava a digitação e impede colar o CPF ou o telefone copiado de outro lugar.
• "Formato inválido" sem dizer qual é o formato válido, deixando o cliente adivinhar.
• Checkout que limpa o formulário inteiro quando um único campo dá erro.
• Campo de nome com limite de 30 caracteres num país em que nome completo com quatro sobrenomes é comum.
• Erro em destaque aparecendo enquanto o cliente ainda está digitando, acusando de errado um dado que ele nem terminou.

Jon Postel escreveu a regra para máquinas conversarem com máquinas. Ela funciona ainda melhor entre máquinas e pessoas, porque pessoas não leem a especificação antes de digitar. O formulário que entende o cliente vende. O que exige que o cliente entenda o formulário perde a venda e ainda faz o cliente se sentir burro.

Este artigo faz parte da série Leis de UX. O anterior trata da Lei de Miller.

Fontes

• Jon Postel (ed.), RFC 760, "DoD Standard Internet Protocol" (1980), seção 3.2
• RFC 2555, "30 Years of RFCs" (1999)
• Vint Cerf, RFC 2468, "I Remember IANA" (1998)
• Internet Hall of Fame, Jon Postel
• USC Viterbi School of Engineering, sobre o legado de Jon Postel no ISI (2007)
• Thomson e Schinazi, RFC 9413, "Maintaining Robust Protocols" (2023)
• Baymard Institute, formatação de espaços no campo de cartão
• Henri Sivonen, perguntas e respostas sobre o fim do grupo XHTML 2
• Network World, XHTML 2 abandonado em favor do HTML5 (2009)
• WHATWG, HTML Living Standard: parsing e tratamento de erros
• Ajuda do Gmail, "Dots don't matter in Gmail addresses"
• Christopher Null, "Hello, I'm Mr. Null. My Name Makes Me Invisible to Computers", Wired (2015)