O Erro de UX que Fazia Nossos Usuários Clicarem no Botão Errado 300 Vezes por Dia

Era uma terça-feira de março de 2026 quando o responsável pelo produto do "Organiza", nosso aplicativo de gestão de tarefas domésticas, chegou na minha mesa com o gráfico de suporte na mão. O número de tickets de usuários reclamando de "tarefas sumidas do nada" tinha saltado de uma média de 5 por semana para 42 em apenas três dias. O pior não era o volume de reclamações, mas o padrão: usuários excluíam itens da lista de compras ou pagamentos de contas e, minutos depois, entravam em pânico porque o registro tinha ido para o lixo sem confirmação.

Investigando os logs de backend, descobrimos algo que fez meu estômago revirar: cerca de 300 exclusões estavam sendo desfeitas manualmente pelo usuário todos os dias através do recurso "Restaurar". Isso significava 300 toques acidentais. O designer sênior tinha posicionado o ícone de lixeira bem ao lado do botão de "Concluído". A lógica era baseada no "Happy Path": o usuário termina a tarefa e, se não precisar mais dela, a exclui rapidamente. O problema é que esse fluxo ideal ignorava completamente a biomecânica do polegar no trânsito de São Paulo.

O mito da "ação rápida" no mobile

A equipe de design original defendia aquele layout com unhas e dentes. Argumentavam que, para o Usuário Power, ter a lixeira a 8 milímetros do checkbox otimizava o tempo. Eles estavam certos em teoria, mas completamente errados na prática do mundo real. Ninguém usa um app de finanças ou tarefas sentado numa cadeira ergonômica com o dedo mindinho precisionado.

A maioria das interações acontece enquanto o usuário segura o guidom da bicicleta, o volante do carro no farol vermelho (infelizmente) ou equilibra uma sacola do mercado. Nesse cenário, a precisão cai drasticamente. O polegar não toca um único pixel; ele cobre uma área ovalada. O erro de UX clássico aqui foi tratar o toque como um clique de mouse de 1x1 pixel, ignorando que o conceito de 'Thumb Zone' dita como nosso dedo naturalmente ocupa áreas maiores.

Quando analisamos os mapas de calor da interface, a área sobreposta entre o alvo do "Concluído" e o da "Lixeira" era um campo minado. O usuário queria marcar a conta de luz como paga, mas a carnuda do dedo escorregava dois milímetros para a esquerda. Pronto: conta excluída. O aplicativo nem pedia confirmação para "destrutivos rápidos". Era um tiro no pé projetado com boa intenção.

A anatomia do erro acidental

A Lei de Fitts não é apenas sobre o tamanho do botão; é fundamentalmente sobre a distância. Se você tem dois botões que executam ações opostas — uma construtiva (salvar/concluir) e uma destrutiva (excluir/apagar) — e coloca eles colados, você está matando a usabilidade. O tamanho do alvo (touch target) naquele layout era de 44dp, o que respeita as guidelines do iOS e Material Design. O erro estava na falta de espaçamento negativo entre eles.

Eu precisei mostrar isso na marra. Peguei um protótipo no Figma e criei uma simulação rápida para mostrar aos stakeholders como como prototipar uma transição de navegação fluida no Figma para imitar o iOS, mas focado na área de toque. Ao invés de apenas mostrar o layout estático, criei um "dedo" semi-transparente sobrepondo a tela. Ao mover o dedo simulado em direção ao botão de "Concluído", ficou visualmente óbvio que a probabilidade de tocar na lixeira era de quase 40%.

O número de 300 cliques diários não era apenas um incômodo; custava dinheiro. Cada ticket de suporte para "recuperar tarefa excluída" custava cerca de R$ 4,50 em tempo de operador. Estávamos queimando R$ 1.350,00 por mês — R$ 16.200,00 por ano — só para consertar o erro de um ícone que estava "felizmente" posicionado.

A solução: separar o perigo da ação

A correção proposta foi brutal na sua simplicidade, mas polêmica na reunião de produto. Não mudamos o tamanho dos ícones. Mudamos a topografia da tela. Mantivemos o botão de "Concluído" na Thumb Zone primária (fácil acesso) e banimos a lixeira para a parte superior da tela, longe do polegar natural. Além disso, movemos a ação de exclusão para um menu secundário ("...") ou para o modo de edição, o que exige um segundo passo cognitivo.

A equipe de produto reclamou da "descoberta" da funcionalidade. "Se o usuário não vê a lixeira, ele não sabe que pode excluir". Baita falácia. O usuário não precisa lembrar que pode excluir a todo segundo; ele só precisa dessa funcionalidade quando decide fazê-lo. A exclusão é uma ação de baixa frequência e alto risco, enquanto concluir é de alta frequência e baixo risco. Colocá-las no mesmo nível de hierarquia visual é um desastre esperando para acontecer.

Implementamos um teste A/B para provar o ponto.

• Grupo A (Controle): Mantinha o layout original, com lixeira e checkbox lado a lado, separados por 8dp.
• Grupo B (Variante): Lixeira removida da lista principal, ação acessada apenas tocando no card da tarefa para abrir detalhes, onde ficava um botão vermelho de exclusão no topo da tela (forra da zona do polegar).

O resultado do teste A/B surpreendeu até os céticos

Rodamos o teste por 14 dias com 10% da base de usuários. A diferença foi estatisticamente significativa já no terceiro dia. No Grupo A, mantivemos a média de 300 "restaurações" diárias. No Grupo B, as restaurações caíram para 9 por dia — uma redução de 97%.

Mas o dado que me deixou mais orgulhosa não foi a redução do erro, mas o aumento na taxa de conclusão de tarefas. O Grupo B concluiu 12% mais tarefas diárias que o Grupo A. A hipótese é que, ao remover o medo de "errar a mão e apagar tudo", os usuários se sentiram mais seguros para interagir com o app em movimento. A ansiedade de ter que ser preciso diminuiu a fricção cognitiva.

A decisão foi unânime: lançamos a mudança para 100% da base na semana seguinte. O layout original, que parecia tão limpo e eficiente no mockup do Figma, era na verdade um obstáculo para a vida real.

Aprendizados sobre densidade de interface

O caso do ícone "feliz" ensinou à equipe que espaço em branco não é estética; é funcionalidade. Quando você projeta para mobile, cada milímetro entre botões de ações conflitantes é uma barreira de segurança. Não tenha medo de esconder ações perigosas. O usuário prefere ter que procurar o botão "deletar" uma vez no mês do que viver com medo de tocar na tela diariamente.

Da próxima vez que você for justificar o espaçamento na sua tela, não diga que é para "respirar visualmente". Diga que é para evitar que o polegar do usuário destrua o trabalho dele. Use dados reais: calcule o custo de suporte ou a taxa de erro atual. Neste caso, salvar o usuário de si mesmo custou apenas uma rearranjo de pixels, mas economizou milhares de reais e muita dor de cabeça.

A regra de ouro que saiu daqui para 2026 é: se a ação é irreversível, ela deve ser fisicamente difícil de alcançar. O design deve proteger o usuário, mesmo contra seus próprios dedos.