Conta Azul · 2024

Transformando o cadastro de trial em um fluxo em etapas para melhorar qualidade de dados e reduzir atrito inicial

  • Onboarding
  • Form Architecture
  • Data Quality
  • Segmentation
  • UX Strategy
Contexto
O formulário de cadastro de trial coletava informações de segmentação necessárias para personalização e eficiência comercial — mas o formato de formulário único, sem contexto, produzia dados de baixa qualidade e alta sobrecarga cognitiva.
Problema
Formulário longo e sem propósito explícito em cada campo gerava dois problemas simultâneos: usuários que desistiam antes de concluir o cadastro e usuários que concluíam mas preenchiam dados imprecisos — comprometendo a segmentação downstream.
Abordagem
Redesign como fluxo em etapas com contexto explícito por campo — cada etapa com propósito declarado e perguntas organizadas por relevância, não por conveniência de coleta.
Resultado
Melhora na qualidade dos dados de segmentação coletados e redução de sobrecarga cognitiva no cadastro. Case posicionado em torno de qualidade de input e impacto downstream.

Fui o Product Designer responsável pelo redesign do fluxo de cadastro de trial, em colaboração com PM José Antônio dos Santos Júnior e DM Thiago Roberto Kolodge. A iniciativa nasceu dentro do projeto de Data Science “Segmentos Multicamadas” — cujo objetivo era coletar dados de perfil de empresa e usuário para alimentar tomadas de decisão, estratégias e otimização de processos em toda a organização.

O escopo do trabalho incluiu duas frentes que raramente são tratadas juntas: entender o impacto downstream dos dados coletados no cadastro (como a qualidade do preenchimento afetava segmentação, SDR e personalização de produto) e garantir continuidade visual entre o ambiente de cadastro no site e o onboarding no ambiente interno do All Connected — para que o usuário não “sentisse” a transição entre os dois contextos.

A tensão central deste projeto era real e não trivial: o time de Data Science precisava de dados de segmentação suficientemente ricos para alimentar o modelo de “Segmentos Multicamadas” — mas o formulário existente, com até 11 campos em formato modal, estava produzindo dados tecnicamente válidos e semanticamente inúteis. A versão A em teste apresentava um modal longo sem contexto sobre o motivo de cada pergunta — “contexto poluído”. O resultado era preenchimento automático: o usuário escolhia a primeira opção disponível para concluir o cadastro e seguir em frente.

A decisão estratégica não foi apenas redesenhar a interface — foi mudar o formato arquitetural. De modal para fluxo com URL própria. Essa mudança não é cosmética: um modal é um bloqueio imposto pelo produto; uma página com URL própria é uma etapa com identidade e propósito. O usuário transita por ela, não a descarta.

O segundo deslocamento foi reconhecer que qualidade de dado de segmentação é um problema de design de formulário, não de validação técnica. Quando o usuário não entende por que está sendo perguntado, responde para avançar — não para informar. O “contrato explícito” — cada etapa declarando seu propósito antes de coletar — foi a hipótese de design que orientou toda a estrutura da versão B.

O ponto de partida foi a versão A em teste — o modal de cadastro com até 11 campos. Os dados de conversão disponíveis revelavam o custo real do formato: apenas uma fração dos usuários que iniciavam o cadastro chegava a criar uma conta trial ativa. A distância entre quem iniciava e quem finalizava cada etapa do funil tornava evidente que o atrito não era só de interface, mas de propósito: o usuário não via motivo para preencher com precisão.

O segundo eixo de análise foi o impacto downstream. Quais campos eram efetivamente usados pelo time de Data Science para alimentar o modelo de Segmentos Multicamadas? Quais alimentavam a qualificação de SDR? Quais informavam a personalização de produto? Essa análise determinou quais campos permaneceriam no fluxo, em qual ordem e com qual contexto — e quais seriam removidos ou tornados opcionais.

A validação foi estruturada como experimento A/B com P-value estatístico. Além das métricas de conversão já coletadas na versão A, foi incluído tempo de conclusão da tarefa como métrica de usabilidade — permitindo avaliar não só se os usuários completavam o cadastro, mas com que fluidez.

  • Formato

    Antes: formulário único em modal. Depois: fluxo em etapas com URL própria — cada etapa com identidade e propósito.

  • Contexto por campo

    Antes: ausente — campos sem explicação do propósito. Depois: explícito em cada etapa, parte da interface, não rodapé.

  • Carga cognitiva

    Antes: alta — tudo de uma vez em modal. Depois: progressiva — uma decisão por vez, com contexto suficiente para responder com precisão.

  • Qualidade de dados

    Antes: imprecisão por preenchimento automático — dado tecnicamente válido, semanticamente inútil. Depois: dados coletados com propósito declarado — base para segmentação e personalização.

  • Impacto downstream

    Antes: segmentação comprometida por dados imprecisos. Depois: base para personalização de produto, qualificação de SDR e eficiência comercial.

O que este projeto realmente foi

Uma iniciativa de Data Science que só funcionaria se o design do formulário funcionasse primeiro. O modelo de Segmentos Multicamadas dependia de dados de perfil e motivação do usuário — mas esses dados só seriam precisos se o usuário entendesse por que estava sendo perguntado. Qualidade de dado de segmentação é um problema de UX, não de validação técnica. Esse foi o insight central que orientou todas as decisões do projeto.

O que permaneceu depois

Um princípio de design para coleta de dados aplicável a qualquer ponto do produto onde informação é coletada do usuário — onboarding, configuração, personalização, atualizações de perfil. A regra é simples: se o usuário não entende por que está sendo perguntado, a resposta não vale. O “contrato explícito” — propósito declarado antes da coleta — é o mecanismo que transforma preenchimento automático em dado semântico.

O que eu faria diferente

Resolver as questões abertas — canais de venda e distinção contador/BPO — antes de desenhar as etapas. Ambiguidade de conteúdo no meio do projeto é mais cara do que alinhamento antecipado: quando a dúvida aparece após o design estar estruturado, o custo de revisão é maior e o risco de lançar com escopo incompleto aumenta. Também mapearia mais cedo a descontinuidade visual com o All Connected — a etapa 4 como “ambiente diferente” era uma ruptura previsível que poderia ter entrado no escopo original em vez de ficar como débito para iteração futura.

Vamos trabalhar juntos?

Disponível para full-time · remote · freelancer

Aberto a novos projetos, oportunidades e conversas.