Cadastro de empresa B2B: redesign com A/B
Redesenhei o cadastro de empresa como microfrontend e o promovi depois que o teste A/B superou o fluxo em produção em conversão.
Caminho rejeitado: Trocar todo mundo de uma vez com feature flag, sem dividir tráfego
Visão geral
Com produto e backend, reconstruí um fluxo de cadastro de empresa com muita fricção como microfrontend no design system Storybook existente. Rodamos contra o fluxo em produção com Unleash antes de promover. Objetivo: menos passos, mesmos dados, sem quebrar o funil.
Problema
O fluxo legado de cadastro tinha passos extras que faziam as empresas desistir antes de concluir o perfil. O monolito também era difícil de manter e estava desalinhado dos padrões de componentes dos produtos B2B mais novos.
Restrições
- Tinha que rodar em paralelo ao fluxo em produção durante o teste A/B, sem uma troca abrupta.
- O fluxo novo tinha que superar o antigo em conversão antes de promovermos.
- O design system Storybook compartilhado era a fonte de verdade da UI. Sem biblioteca de componentes paralela.
Arquitetura
Reconstruí o cadastro como microfrontend independente e removi passos desnecessários. A UI veio do sistema Storybook compartilhado. Unleash dividiu o tráfego entre antigo e novo. Quando a conversão favoreceu a versão nova, ela virou o padrão.
Decisões principais
Teste A/B via Unleash em vez de troca direta
Cadastro é caminho crítico de conversão. Tráfego real decidiu qual design venceu.
- Trocar todo mundo de uma vez com feature flag, sem dividir tráfego (rejeitado: sem prova de conversão)
- Só redesenhar o CSS do formulário no monolito, aos poucos (rejeitado: não reduziu passos nem desacoplou o deploy)
Microfrontend mais design system compartilhado
Independente do monolito para iterar mais rápido. Reutilizar componentes Storybook manteve o foco no fluxo e na lógica, não em reconstruir UI.
- Reconstruir dentro do monolito (rejeitado: iteração mais lenta, mais risco se quebrar)
- Biblioteca de UI nova só para este fluxo (rejeitado: tokens duplicados e divergência)
Tailwind para velocidade de estilo dentro do sistema existente
Tailwind já era o padrão do design system. A iteração de layout ficou dentro desse sistema, sem inventar abordagem CSS paralela.
- CSS modules escritos à mão (mais lento contra um sistema Tailwind existente)
Stack
- React
- TypeScript
- Astro
- Tailwind CSS
- Storybook
- Unleash (A/B Testing)
- Jest
- React Testing Library
Impacto
O teste A/B favoreceu o funil mais curto; promovemos depois que a conversão superou o legado. Testes unitários cobriram os passos do funil porque este caminho fica no cadastro inicial.
Aprendizados
- Teste A/B em funil de várias etapas é confuso porque a conversão atrasa. Por isso tráfego real importa mais do que achismo.
- Um design system documentado tira a UI como gargalo e libera tempo para o fluxo em si, não para reinventar UI.
- Remover passos que considerávamos obrigatórios foi o maior ganho de experiência.