Jéssica Bortolan

02 de setembro de 2026

Publicado em 02 de setembro de 2026

Seis heurísticas, um formulário mais simples

Seis heurísticas, um formulário mais simples

O formulário de dados do simulador da Aires tinha atrito em dois pontos: no cadastro inicial, os campos apareciam em formato de lista compacta, difícil de preencher num público pouco familiarizado com tecnologia e na etapa de contratação, a navegação entre preencher, revisar e editar campos era imprevisível, voltar ou fechar uma etapa podia reiniciar o fluxo inteiro ou fechar o formulário sem aviso, sem chance de o usuário reconsiderar. Avaliei o fluxo mobile inteiro sob a lente das dez heurísticas de usabilidade de Nielsen e redesenhei cada ponto de atrito.

Versão atualizada

Versão atualizada

Contexto

No simulador da Aires, existem dois momentos em que o usuário precisa preencher seus próprios dados. O primeiro acontece antes de qualquer decisão: para simular um empréstimo, é preciso informar dados básicos, ainda sem compromisso nenhum. O segundo vem depois, na contratação, aqui o usuário já decidiu que quer aquele empréstimo, e o preenchimento é mais longo porque é ele que vira o contrato de fato.

São dois momentos com temperaturas emocionais bem diferentes. No primeiro, o atrito precisa ser mínimo, porque o usuário ainda está decidindo se quer continuar. No segundo, ele já quer, mas isso não significa que o formulário pode ser difícil, só que a régua de paciência é um pouco mais generosa. Em nenhum dos dois casos um formulário confuso é aceitável, principalmente considerando que o público majoritário da Aires não é um público nativo em tecnologia.

Foi analisando esse fluxo, tela por tela, que os problemas apareceram.

No simulador da Aires, existem dois momentos em que o usuário precisa preencher seus próprios dados. O primeiro acontece antes de qualquer decisão: para simular um empréstimo, é preciso informar dados básicos, ainda sem compromisso nenhum. O segundo vem depois, na contratação, aqui o usuário já decidiu que quer aquele empréstimo, e o preenchimento é mais longo porque é ele que vira o contrato de fato.

São dois momentos com temperaturas emocionais bem diferentes. No primeiro, o atrito precisa ser mínimo, porque o usuário ainda está decidindo se quer continuar. No segundo, ele já quer, mas isso não significa que o formulário pode ser difícil, só que a régua de paciência é um pouco mais generosa. Em nenhum dos dois casos um formulário confuso é aceitável, principalmente considerando que o público majoritário da Aires não é um público nativo em tecnologia.

Foi analisando esse fluxo, tela por tela, que os problemas apareceram.

Ponto a ponto: problema, heurística e decisão
Visibilidade do status do sistema.

Em nenhum momento do preenchimento da contratação o usuário sabia quanto ainda faltava, nem em qual seção estava, nem quantos campos restavam ali. A heurística é direta: o sistema deve manter o usuário informado sobre o que está acontecendo, com feedback adequado e em tempo razoável.

A solução foi uma barra de progresso segmentada no topo, indicando em qual das sete seções do fluxo o usuário está, combinada com um contador dentro de cada seção mostrando quantos campos faltam ali, progresso macro e micro, sempre visível.

Reconhecimento em vez de memória.

No formulário inicial, o pouco espaço de tela levou a organizar os campos em seções, e uma delas acabou em formato de lista compacta, com inputs pequenos e amontoados, de leitura difícil para quem não preenche formulários digitais no automático. A heurística diz que o usuário nunca deveria precisar reter informação de uma tela pra usar na próxima, tudo relevante deve estar visível. A decisão foi reduzir a densidade em vez de tentar caber mais informação na tela: cada etapa passou a mostrar um campo, ou um par diretamente relacionado, como número da agência e dígito, por vez, sempre com espaço de sobra ao redor.

Versão antiga

Versão antiga

Versão atualizada

Versão atualizada

Controle e liberdade do usuário.

Na etapa de contratação, editar um campo a partir da revisão jogava o usuário de volta ao preenchimento, se ele salvasse, voltava pra revisão, mas se clicasse em "voltar" em vez de salvar, o sistema reiniciava o fluxo inteiro, obrigando a repetir etapas já feitas. A heurística exige uma saída clara de uma ação indesejada, sem processos mais longos do que o necessário. A solução foi criar um modo de edição separado do fluxo original: ao clicar em "editar", o usuário entra numa tela própria, com suas próprias ações de cancelar e salvar, e ao sair volta direto pra revisão, nunca para o início.

Prevenção de erros.

Clicar no "x" no canto da tela, o gesto mais natural pra quem só quer fechar uma etapa, fechava o formulário por completo e devolvia o usuário direto pro simulador, com tudo perdido, sem nenhuma chance de reconsiderar. A heurística prioriza evitar que o erro aconteça, em vez de só lidar com ele depois. A decisão foi um modal de confirmação que aparece sempre que o usuário tenta fechar o formulário, com duas ações claras: continuar preenchendo, ou sair mesmo assim.

Consistência e padrões.

O footer com as ações principais não era fixo, em telas mais longas, ele desaparecia com o scroll, quebrando o padrão de onde o usuário esperava encontrar os botões de ação. A solução foi tornar o footer fixo e consistente em todas as etapas do fluxo, sempre na mesma posição, com as mesmas ações.

Estética e design minimalista.

Dois headers ocupavam espaço logo no topo da tela, espaço que, no mobile, já era escasso. A heurística defende que a interface não deve competir com informação irrelevante pela atenção do usuário. A decisão foi simples: os dois headers viraram um só, liberando espaço vertical logo de início.

Versão antiga

Versão antiga

Versão atualizada

Versão atualizada

Resultado

Cada decisão nesse redesenho tem uma heurística nomeada por trás, não um número de conversão ou de abandono, mas uma base de usabilidade consolidada e testável por qualquer pessoa que revisitar o fluxo. A estrutura final ficou mais previsível: o usuário sempre sabe quanto falta, não perde o que já preencheu por engano, e tem a chance de reconsiderar antes de abandonar o processo.

Esse projeto me mostrou que boa parte do atrito em formulários longos não vem da quantidade de campos, e sim da imprevisibilidade da navegação, a confiança no sistema cai justo no momento em que ele se comporta de um jeito inesperado.

Cada decisão nesse redesenho tem uma heurística nomeada por trás, não um número de conversão ou de abandono, mas uma base de usabilidade consolidada e testável por qualquer pessoa que revisitar o fluxo. A estrutura final ficou mais previsível: o usuário sempre sabe quanto falta, não perde o que já preencheu por engano, e tem a chance de reconsiderar antes de abandonar o processo.

Esse projeto me mostrou que boa parte do atrito em formulários longos não vem da quantidade de campos, e sim da imprevisibilidade da navegação, a confiança no sistema cai justo no momento em que ele se comporta de um jeito inesperado.

Próximos passos

Como esse redesenho partiu de avaliação heurística e não de dado, o próximo passo agora seria acompanhar métricas que confirmem (ou não) o impacto de cada decisão na prática. Eu definiria os seguintes indicadores:

  1. Taxa de conclusão do formulário por seção, pra identificar se ainda existe algum ponto de abandono mesmo depois do redesenho.

  2. Taxa de uso do modal de saída: quantos usuários que tentam fechar o formulário optam por "continuar preenchendo" versus "sair mesmo". Para validar se a prevenção de erro está realmente segurando o usuário no fluxo.

  3. Tempo médio de preenchimento, total e por seção, comparado ao fluxo anterior. Spoiler: esperado é que suba um pouco (menos campos por tela também significa mais telas), então vale acompanhar junto da taxa de conclusão pra não interpretar esse número sozinho.

  4. Frequência de uso do modo de edição a partir da revisão, pra confirmar se o novo fluxo de edição está sendo usado como esperado e se reduz o reinício do preenchimento do zero.

  5. Volume de chamados de suporte relacionados a dificuldade no preenchimento, comparando antes e depois, um indicador indireto, mas relevante pro público menos familiarizado com tecnologia que é a base de usuários da Aires.

Como esse redesenho partiu de avaliação heurística e não de dado, o próximo passo agora seria acompanhar métricas que confirmem (ou não) o impacto de cada decisão na prática. Eu definiria os seguintes indicadores:

  1. Taxa de conclusão do formulário por seção, pra identificar se ainda existe algum ponto de abandono mesmo depois do redesenho.

  2. Taxa de uso do modal de saída: quantos usuários que tentam fechar o formulário optam por "continuar preenchendo" versus "sair mesmo". Para validar se a prevenção de erro está realmente segurando o usuário no fluxo.

  3. Tempo médio de preenchimento, total e por seção, comparado ao fluxo anterior. Spoiler: esperado é que suba um pouco (menos campos por tela também significa mais telas), então vale acompanhar junto da taxa de conclusão pra não interpretar esse número sozinho.

  4. Frequência de uso do modo de edição a partir da revisão, pra confirmar se o novo fluxo de edição está sendo usado como esperado e se reduz o reinício do preenchimento do zero.

  5. Volume de chamados de suporte relacionados a dificuldade no preenchimento, comparando antes e depois, um indicador indireto, mas relevante pro público menos familiarizado com tecnologia que é a base de usuários da Aires.

*Os dados usados nos testes de preenchimento do formulário e os valores de simulação são fictícios, não são valores reais.

*Os dados usados nos testes de preenchimento do formulário e os valores de simulação são fictícios, não são valores reais.

O redesenho do formulário é um projeto real, desenvolvido durante minha atuação profissional como UI/UX Designer na Aires Digital.

O redesenho do formulário é um projeto real, desenvolvido durante minha atuação profissional como UI/UX Designer na Aires Digital.

Jéssica Bortolan

02 de setembro de 2026

Publicado em 02 de setembro de 2026

Create a free website with Framer, the website builder loved by startups, designers and agencies.