530 cliques.

É o número de vezes que eu teria que apertar a setinha < de um date picker pra chegar na minha data de nascimento.

530 vezes. Mês a mês. Janeiro de 2026, dezembro de 2025, novembro de 2025... até janeiro de 1982. Num calendariozinho de 280 pixels de largura. Com uma setinha de 12 pixels. No celular. Com o dedo. 530 vezes.

E alguém achou que isso era uma boa ideia.

Eu sei quando eu nasci.

Minha data de nascimento não é algo que eu preciso "procurar" num calendário. Eu não preciso ver que dia da semana foi. Eu não preciso de contexto visual. Eu não preciso navegar entre meses.

Eu sei a data. É uma string de 8 dígitos que eu digito em documentos desde a adolescência.

06/01/1982.

Me dá 3 campos de texto. Dia. Mês. Ano. Eu digito em 2 segundos. Pronto. Acabou. Próximo campo.

Mas não. Você me dá um calendário. Que abre em março de 2026. E eu tenho que clicar 530 vezes pra chegar em janeiro de 1982.

Quantos cliques são os seus?

Sinta a dor.

Cansou? Desistiu? Pois é. Seus usuários também.

"Tá, mas o meu abre um seletor de mês e ano."

O date picker mais comum em 2026. Você clica no nome do mês, abre uma lista com os 12 meses. Seleciona. Clica no ano, abre outra lista com 100+ anos. Scrolla. Seleciona. Depois encontra o dia num grid de números pequenos e clica.

Testa.

Vamos contar: um clique pra abrir o date picker. Um clique no mês. Scroll. Seleciona. Um clique no ano. Scroll por 100+ opções. Seleciona. Scan visual num grid. Clica no dia.

9 interações. Pra digitar algo que você sabe de cor desde os 12 anos.

"Tá, mas o meu tem dropdown nativo."

O último refúgio. Três dropdowns nativos do HTML: mês, dia, ano. Sem calendário, sem grid, sem modal. Só scroll.

Testa.

Vamos contar: um clique pra abrir o dropdown de mês. Scroll por 12 opções. Seleciona. Um clique pra abrir o dropdown de dia. Scroll por 31 opções. Seleciona. Um clique pra abrir o dropdown de ano. Scroll por 100+ opções. Seleciona.

6 interações e 3 scrolls. No celular, com o dedo, numa roletinha de 44 pixels de altura.

Ou você podia ter dado 3 campos de texto e o usuário digitava em 2 segundos.

A solução é constrangedoramente simples.

Você não precisa de uma biblioteca. Não precisa de um componente de 400KB. Não precisa de um calendário bonito.

Precisa de 3 inputs.

<input type="text" placeholder="DD" maxlength="2">
<input type="text" placeholder="MM" maxlength="2">
<input type="text" placeholder="AAAA" maxlength="4">

Pronto. É isso. 3 campos. Labels claros. inputmode="numeric" pra abrir o teclado numérico no celular. Validação simples no submit.

O Gov.uk faz assim. A Smashing Magazine recomenda isso. O Nielsen Norman Group recomenda isso. Não é opinião. É pesquisa de usabilidade.

"Mas e se a pessoa digitar errado?"

Valida. Como você já faz com CPF, telefone, e-mail e tudo mais. A diferença é que com 3 campos de texto o erro mais comum é um dígito trocado — que o usuário corrige em 1 segundo. Com um date picker, o erro mais comum é desistir do cadastro.

"Mas o date picker previne datas inválidas."

Previne e cria 530 cliques de atrito. Troca um problema raro (data inválida) por um problema universal (UX horrível). É como trancar a porta da frente e obrigar todo mundo a entrar pela janela porque uma vez alguém entrou na casa errada.

"Mas o calendário mostra o dia da semana."

Você sabe em que dia da semana você nasceu? Não? Então por que seu formulário mostra isso?

O muro da vergonha.

Conserta seus formulários.

Não usa date picker pra data de nascimento. É uma data conhecida. Deixa o usuário digitar.

3 campos. Dia. Mês. Ano. Labels claros. Teclado numérico no celular.

É um problema resolvido. É pesquisa de usabilidade publicada. É recomendação do Gov.uk, do Nielsen Norman Group, da Smashing Magazine.

Não existe literalmente nenhum motivo pra usar um calendário de date picker pra data de nascimento além da inércia coletiva de um milhão de devs copiando o mesmo componente de uma biblioteca sem nunca testar com um ser humano real.

Para de scrollar. Deixa eu digitar.