Projetando o fluxo de compra para um lançamento complexo — ERP + PDV como produto e como bundle
Launch Design
Checkout
Multi-Plan
Cross-Functional
Revenue
Contexto
A Conta Azul lançou o PDV como produto independente e como bundle com o ERP. Um único checkout precisava suportar múltiplos planos, restrições de elegibilidade distintas e jornadas de entrada diferentes.
Problema
Complexidade de planos não tratada no design gera confusão, tickets de suporte e perda de confiança no momento de compra. A interdependência entre preço, regulação, messaging e capacidade operacional tornava o design da experiência um ponto de risco real do lançamento.
Abordagem
Mapeamento de todos os cenários de plano e elegibilidade antes do design. Protótipo de alta fidelidade como ferramenta de alinhamento cross-funcional. Documentação de riscos e framework de métricas para aprendizado pós-lançamento.
Resultado
Lançamento executado sem retrabalho de design pós-lançamento. Framework de métricas entregue como base para aprendizado contínuo.
Atuação
Liderei o design do checkout como Lead Product Designer em um time de três designers (Larissa Amorim Silva e Katlin Bendheim) sob gestão do DM Thiago Roberto Kolodge. Trabalhei com três PMs — José Antônio dos Santos Júnior, Claudinei Martins da Silva e Amanda Carsten — e stakeholders de Marketing, Vendas e Operações (Milene Polo de Melo, Mateus Masiero, Rodrigo Paiva Mendonça).
Meu escopo foi deliberadamente mais amplo que interface: mapeei os cenários de elegibilidade e exceções antes de abrir o Figma; negociei trade-offs entre o que a experiência prometia e o que o MVP conseguia entregar; documentei os riscos assumidos explicitamente; e defini o framework de métricas pós-lançamento. O valor desta atuação está na redução de ambiguidade antes do lançamento — não em um único número de resultado.
Estratégia
Lançamentos com múltiplos planos têm um modo de falha específico: o design resolve a interface, mas não resolve a elegibilidade. O usuário chega ao checkout, não entende qual plano se aplica ao seu caso e abandona — ou pior, assina o plano errado e cancela.
Aqui a tensão era ainda mais direta: os requisitos reais de elegibilidade para o PDV (empresa no Simples Nacional, fora dos estados SC e CE) eram invisíveis na experiência padrão de checkout. Sem tratamento explícito, o produto lançaria com um risco de negócio ativo — usuários assinando planos que não poderiam usar.
A decisão estratégica foi tornar a elegibilidade visível no ponto de decisão, não em rodapé ou modal de suporte. E, onde o MVP optou conscientemente por não bloquear assinaturas inelegíveis — decisão de negócio documentada, não omissão de design —, garantir que os alertas fossem suficientemente claros para informar a escolha sem quebrar a conversão.
Processo
A sequência foi deliberada: cenários antes de interface, exceções antes de happy path.
O ponto de partida foi o mapeamento completo dos dois fluxos de entrada — Trial (usuário experimenta o produto e decide assinar) e Compra Direta (usuário chega do site já com intenção de compra). Cada fluxo trazia pontos de atenção diferentes: no Trial, o desafio era deixar claro qual plano correspondia ao que o usuário já estava usando. No Direto, o risco era intenção de assinar um plano incompatível com o perfil da empresa.
Depois, mapeei os cenários de elegibilidade: quais combinações eram possíveis (só ERP, só PDV, ERP+PDV), quais dependiam de regime tributário (Simples Nacional obrigatório para PDV), quais eram bloqueadas por estado (SC e CE excluídos no MVP), e quais exceções geravam mensagens de alerta em vez de bloqueio (CPF, CNPJ sem retorno de estado ou regime).
Só depois desse mapeamento o design da interface começou. O protótipo foi construído para cobrir todos os cenários — não apenas o caminho ideal. Isso forçou decisões sobre estados de alerta, mensagens de inelegibilidade e o que o usuário podia fazer em cada caso, antes do desenvolvimento.
Dois fluxos de entrada mapeados antes do design
Elegibilidade e exceções como pré-requisito
Enquadramento via CNPJ/CPF como filtro de planos
Protótipo como artefato de alinhamento
Riscos assumidos documentados como entregável
Framework de métricas pré-definido
Diagnóstico
A sequência de descoberta refletiu a prioridade estratégica: primeiro os fluxos, depois os cenários, depois os riscos.
Pergunta: Quem chega ao checkout por qual caminho — e o que cada caminho pressupõe sobre o estado do usuário?
O que foi feito: Mapeamento dos dois fluxos documentados: Trial (usuário em experiência ativa decide assinar) e Compra Direta (usuário chega do site externo com intenção declarada). Para cada fluxo, levantei o contexto de entrada, as expectativas implícitas do usuário e os pontos onde essas expectativas podiam divergir da oferta real.
Achado principal: Os dois fluxos exigiam tratamentos distintos na seleção de planos. No Trial, o risco era ambiguidade sobre a correspondência entre o produto experimentado e o plano disponível para assinatura. No Direto, o risco era intenção de assinar um plano inelegível para o perfil da empresa — sem sinal de alerta no caminho.
Artefato: Mapa de fluxos com pontos de atenção por caminho de entrada, usado como insumo para o design da tela de enquadramento.
Pergunta: Quais combinações de plano são possíveis, quais são inelegíveis, e o que acontece nas bordas?
O que foi feito: Levantamento sistemático das condições de elegibilidade para cada plano: regime tributário (Simples Nacional obrigatório para PDV), restrições geográficas (SC e CE excluídos no MVP), e variáveis de entrada (CPF, CNPJ com e sem retorno de estado/regime). Mapeei também as três combinações possíveis: só ERP, só PDV, ERP+PDV.
Achado principal: O MVP decidiu conscientemente não implementar mecanismos de bloqueio para assinaturas inelegíveis — um risco de negócio assumido explicitamente, não uma omissão. Isso significava que o design precisava de alertas que informassem sem impedir: mensagens visíveis o suficiente para que o usuário entendesse a restrição, sem quebrar a conversão para quem era elegível.
Artefato: Matriz de cenários com combinações possíveis, condições de elegibilidade, exceções e comportamentos esperados da interface em cada caso.
Pergunta: Quais riscos o lançamento estava assumindo — e quais deles eram riscos de design versus riscos de negócio?
O que foi feito: Revisão dos pontos de atenção documentados na spec do MVP: usuários que assinam planos para os quais não têm requisitos; impossibilidade de trocar de plano (fluxos fora do escopo do MVP); gap de alinhamento entre a mensagem do produto e a landing page externa (Product Marketing ainda não havia definido os detalhes). Classifiquei cada risco por origem e por quem precisava endereçá-lo.
Achado principal: Dois riscos residuais ficaram documentados: (1) usuários que assinam PDV sem cumprir os requisitos — risco assumido conscientemente pela área de negócio; (2) inconsistência potencial entre a experiência no produto e a mensagem no site externo — gap de alinhamento com Product Marketing que não estava resolvido na entrega.
Artefato: Documento de riscos com classificação por origem (design, negócio, comunicação) e recomendações de mitigação por responsável.
Solução
Problema: Usuários chegavam ao checkout sem entender qual plano se aplicava ao seu caso — ou com a expectativa errada sobre o que o bundle incluía.
Decisão de design: A seleção de planos foi estruturada para tornar elegibilidade explícita no ponto de decisão: condições de cada opção visíveis antes do clique, com linguagem mapeada ao vocabulário do usuário, não ao vocabulário do produto. A tela de enquadramento usa CNPJ/CPF como entrada para filtrar os planos disponíveis pelo porte da empresa — reduzindo o conjunto de opções antes da escolha, não depois. Para exceções (CPF, CNPJ sem retorno de estado ou regime), mensagens de alerta informam a restrição sem bloquear a assinatura — decisão de negócio documentada, não omissão de design.
Visuais: tela de enquadramento via CNPJ/CPF · estados de alerta de inelegibilidade · seleção de planos com condições visíveis
Problema: Múltiplos planos com variações de preço, funcionalidade e elegibilidade sobrecarregam a decisão de compra e aumentam o tempo até conversão.
Decisão de design: Estrutura de seleção baseada em tarefas e perfis de uso — o usuário escolhe pelo que precisa fazer, não pelo nome do plano. Comparação mínima e suficiente: sem tabelas exaustivas de features, com destaque nos diferenciadores realmente decisivos. A filtragem por porte via enquadramento reduzia o conjunto de opções apresentadas antes da tela de seleção, diminuindo o esforço de comparação no momento de maior tensão de decisão.
Visuais: estrutura de comparação de planos · antes (todos os planos) vs. depois (filtrado por porte)
Problema: Marketing, Vendas, Operações e Engenharia tinham entendimentos diferentes do que o checkout precisava suportar — e nenhum artefato único que os reunisse.
Decisão de design: Protótipo de alta fidelidade cobrindo todos os cenários mapeados, usado em sessões com cada time. Os gaps de entendimento apareceram no protótipo, não no produto final.
Visuais: protótipo cobrindo cenários críticos · fluxo de revisão com cada time
Impacto
O lançamento aconteceu sem retrabalho de design pós-lançamento. O impacto mensurável foi planejado para aparecer depois — e foi estruturado com essa lógica desde o início.
Framework de métricas como entregável
O framework de métricas não foi documentado retrospectivamente. Foi definido antes do lançamento como condição para que o MVP cumprisse seu objetivo real: validar a oferta do plano PDV e do Combo ERP+PDV. As métricas de sucesso (variação de conversão, variação de MRR) e as métricas de acompanhamento (tickets de mudança de plano, dúvidas do time de vendas, ciclo de venda por plano, preenchimento de CPF/CNPJ na etapa de enquadramento) foram estruturadas para distinguir aprendizado de resultado.
Teste de preço em 3 fases habilitado
O Product Marketing estruturou um teste de preço em três fases consecutivas: Fase 1 — validação da oferta Combo vs. ERP isolado; Fase 2 — elasticidade de preço e posicionamento do Combo; Fase 3 — oferta do plano PDV avulso. O design do checkout precisava suportar esse processo sem retrabalho estrutural entre fases — o que foi garantido pela arquitetura modular da seleção de planos.
Padrão de mapeamento reutilizável
A sequência metodológica — fluxos de entrada → cenários de elegibilidade → exceções → interface → protótipo de alinhamento — ficou documentada como padrão aplicável a futuros lançamentos de produto com complexidade similar.
Risco residual documentado
O gap entre a mensagem do produto e a landing page externa (Product Marketing sem detalhes definidos no momento da entrega) foi registrado como risco de comunicação não resolvido. Risco não eliminado, mas visível — e com responsável identificado.
Reflexão
O que este projeto realmente foi
Um projeto de redução de ambiguidade antes de ser um projeto de interface. A interface foi consequência do mapeamento — não o ponto de partida. O checkout funcionou porque os cenários de elegibilidade, os fluxos de entrada e os riscos de negócio foram tratados como problemas de design antes de virar problemas de desenvolvimento.
Influência de nível staff não aparece só em métricas de produto finalizadas. Aparece na capacidade de tornar visível o que estava implícito — e de fazer isso antes do código, quando ainda era barato mudar.
O que permaneceu depois
Um framework de métricas que o time pode usar para aprender com o lançamento ao longo das três fases de teste de preço. Um protótipo que funcionou como documentação do comportamento esperado — referência para desenvolvimento e para onboarding de novos membros do time. Uma matriz de cenários de elegibilidade que pode ser atualizada conforme os requisitos do PDV evoluírem. E um padrão de processo que começa pelos cenários, não pela tela.
O que eu faria diferente
Anteciparia a conversa sobre mecanismo de bloqueio e fluxo de troca de plano. A decisão de não implementar esses mecanismos no MVP foi válida — mas chegou ao design tarde. Tê-la na mesa antes do mapeamento de cenários teria permitido um design dos alertas mais preciso, porque a mensagem de risco para o usuário muda dependendo de se existe ou não uma saída após a assinatura.
Formalizaria mais cedo o alinhamento com Product Marketing sobre a landing page. O gap entre o que o produto comunicava e o que o site externo prometia era um risco de consistência real. Esse alinhamento ficou como risco residual documentado — mas poderia ter sido resolvido antes do lançamento se tivesse entrado na agenda cross-funcional desde o início do projeto.
Case protegido
Este case é protegido por senha. Insira a senha para acessar o processo
completo — ou entre em contato para solicitar acesso.
Vamos trabalhar juntos?
Disponível para full-time · remote · freelancer
Aberto a novos projetos, oportunidades e conversas.