Otimizando a experiência de milhares de novos usuários do ERP para que alcancem o valor real do produto
Growth Design
Activation
User Journey
ERP SaaS
AI-Augmented
Contexto
Conta Azul é a principal plataforma de gestão financeira do Brasil para pequenas e médias empresas — e a complexidade do produto era seu maior risco de ativação.
Problema
Taxa de ativação de 30%, contra meta de 60%. Um desempenho abaixo do mercado com impacto direto em cancelamento e receita.
Abordagem
Diagnóstico estruturado antes de qualquer solução: 9 métodos de pesquisa, redefinição de ativação baseada em dados e 31 iniciativas ao longo de 2 anos.
Resultado
Melhorias expressivas em ativação, receita e descoberta de funcionalidades — e impacto organizacional com mais de 200 oportunidades mapeadas e um novo time criado.
Resultados
+189%NFS-e criadaInversão do rascunho
+500%Conversão de trialsGamificação · base isolada
+40%Vendas criadasOnboarding em escala
+108,5%Cliques nos CTAsVisão geral · primeiros dias
1.392Vendas em 10 diasVia novos pontos
+600%Acesso a Pix compensadoSimplificação de navegação
200+Oportunidades mapeadasNovo time cross criado
31Iniciativas entreguesEm 2 anos de atuação
Atuação
Atuei como Growth Designer com foco em ativação, engajamento e geração de valor ao longo da jornada de produto. A atuação combinou pensamento estratégico, execução orientada por dados e entendimento profundo do usuário para criar experiências que conectam necessidades reais do cliente com os objetivos do negócio. Ao longo do período, conduzi 31 iniciativas com impacto mensurável em ativação, receita, emissão fiscal e descoberta de funcionalidades.
Estratégia
O problema que o negócio chamava de “ativação” era, na prática, quatro camadas sobrepostas: mensuração — cada time media uma coisa diferente, sem definição compartilhada; organização — CS como gargalo de escala, dependência humana que não crescia com a base; produto — caminhos invisíveis, estados vazios sem orientação, primeira experiência sem estrutura; e dados — sem entendimento estruturado do motivo pelo qual usuários cancelavam.
Resolver qualquer um deles isoladamente moveria pouco a métrica. A decisão de tratar o problema como sistema — e não como uma lista de features — foi o que tornou possível um impacto coordenado.
Processo
Minha abordagem é estruturada em torno de um processo de discovery maduro e orientado por evidências. Antes de propor qualquer solução, invisto em entender profundamente o contexto: pesquisas com clientes para mapear dores reais, mapeamentos de produto para conhecer o negócio em profundidade, escuta dos times operacionais para entender fricções internas e a relação entre a entrega do produto e a experiência do cliente.
Utilizo IA como parte do processo de discovery e desenvolvimento — ganhando velocidade na análise de dados, organização de insights e construção das entregas. Cada iniciativa parte de hipóteses claras, fundamentadas em dados qualitativos e quantitativos, com métricas de sucesso definidas antes da execução.
Hipóteses primeiro
Quali + quanti
Métricas antecipadas
Com apoio de IA
Diagnóstico
Toda decisão de design neste case foi construída sobre uma fase estruturada de diagnóstico. A sequência abaixo reflete a ordem real de execução — cada método informou o próximo.
Pergunta: O que cada time entende por “ativação” e o que já foi tentado?
O que foi feito: Entrevistas semiestruturadas com stakeholders de Product, CS, Marketing Lifecycle e Data Science. Três perguntas centrais por perspectiva: o que “ativação” significa para você, o que já sabem sobre por que os usuários não ativam, e o que já foi tentado antes.
Achado principal: Desalinhamento sistêmico — CS, Product, Data e Marketing mediam coisas diferentes. Sem uma definição compartilhada, cada iniciativa otimizava para um objetivo diferente.
Artefato: Mapa de síntese de entrevistas — temas por time, pontos de alinhamento e divergência.
Pergunta: Qual ação do usuário prediz retenção de longo prazo?
O que foi feito: Análise de correlação entre padrões de uso de features e duração da assinatura, em colaboração com PM e Data Science. Cruzamento de quais features eram usadas nos primeiros 7, 14 e 30 dias e quais combinações se correlacionavam com retenção de 6+ meses.
Achado principal: Criar uma venda E emitir uma NFS-e nos primeiros 30 dias correlacionava com aumento de 700%+ na conversão trial→pago. Essa combinação se tornou a definição oficial de ativação.
Artefato: Definição compartilhada de ativação adotada por todos os times. Matriz de correlação de uso de features vs. duração da assinatura.
Pergunta: Como outras plataformas SaaS abordam ativação e onboarding?
O que foi feito: Pesquisa secundária estruturada usando Claude para sintetizar artigos e relatórios de mercado, Perplexity para perguntas específicas de mercado e NotebookLM para organizar e cruzar referências ao longo do projeto.
Achado principal: Documento estruturado cobrindo mecânicas de ativação, padrões de trial design, abordagens de onboarding, boas práticas de estado vazio e estratégias de fluxo de cancelamento.
Artefato: Documento de oportunidades estruturado — referenciado continuamente durante o design das soluções.
Pergunta: Quais padrões de plataformas comparáveis são aplicáveis à Conta Azul?
O que foi feito: Análise de 20+ plataformas SaaS usando Claude para tabelas comparativas por tipo de padrão e Mobbin para coleta de referências visuais reais de telas de onboarding, estados vazios e primeiros acessos.
Achado principal: Dados de exemplo pré-preenchidos eliminam paralisia do produto vazio. Ativação contextual supera checklists iniciais. Onboarding segmentado tem 30–40% mais conclusão que tours lineares.
Artefato: Matriz de benchmarking — plataformas × padrões, com gaps em relação à Conta Azul.
Pergunta: O que realmente acontece nas primeiras interações dos usuários com o produto?
O que foi feito: Observação de sessões de onboarding em grupo e 1:1 com o time de CS, sem intervenção. Entrevistas com usuários em diferentes estágios de ativação. Gravações transcritas automaticamente e sintetizadas via NotebookLM.
Achado principal: Toda sessão começava com as mesmas 5 perguntas — o produto não as respondia sozinho. O contador ou representante de CS atuava consistentemente como sistema humano de navegação. O preenchimento de dados consumia os primeiros 30–45 minutos antes de qualquer ação de valor.
Artefato: Notas de observação mapeadas às etapas da jornada. Corpus de pesquisa consultável ao longo de todo o projeto.
Pergunta: Quais são os temas mais recorrentes de suporte nos primeiros 30 dias?
O que foi feito: Export de dados de tickets do time de CS processado com Claude para agrupamento por tema, recorrência, etapa da jornada e padrão de resolução.
Achado principal: Pré-requisitos de configuração de NFS-e eram o principal driver de contatos nos primeiros 30 dias. Outros temas: falhas de navegação, falta de orientação no onboarding, confusão com cobrança.
Artefato: Visualização de clusters de tickets — temas × frequência × etapa da jornada.
Pergunta: Como os diferentes perfis de entrada do usuário percorrem o produto hoje?
O que foi feito: Sessões de mapeamento cross-funcional cobrindo quatro cenários de entrada: novo trial, compra direta pelo site, fim do trial e ex-clientes retornando.
Achado principal: Novos usuários passavam por 4+ handoffs entre times sem protocolo claro. Um fluxo de checkout mobile estava quebrado após atualização recente de menu — descoberto durante o mapeamento.
Artefato: Mapa de fluxo atual — 4 cenários com pontos de falha destacados por fonte.
Pergunta: Como todos os achados se conectam em uma visão única da jornada completa?
O que foi feito: Blueprint mapeando a jornada ao longo de todo o ciclo de vida — ações do usuário, touchpoints, interações de frontstage, processos de backstage, sistemas de suporte e times responsáveis.
Achado principal: Primeiro artefato em que todos os times viram o quadro completo juntos. Mais de 200 oportunidades priorizadas por frequência, severidade e ownership.
Artefato: Blueprint de serviço — documento vivo atualizado ao longo do projeto.
Pergunta: Os novos fluxos do Appcues conflitam com o onboarding já existente no produto?
O que foi feito: Testes em contas trial para observar cada trigger, sequência e ponto de conflito dos elementos nativos de onboarding já existentes.
Achado principal: Múltiplos triggers disparados simultaneamente — ruído visual e paralisia de decisão. Fluxos nativos contradiziam a linguagem dos novos fluxos. Onboarding ativado para usuários recorrentes.
Artefato: Lista priorizada de conflitos resolvidos antes do rollout.
Solução
Oito iniciativas coordenadas, organizadas por área de impacto. Cada uma foi desenhada para atacar um modo específico de falha identificado no diagnóstico.
Problema: CS era o onboarding. Todo novo usuário dependia de sessão agendada com uma pessoa — e a base crescia mais rápido do que o time conseguia absorver.
Decisão de design: Em vez de replicar digitalmente uma sessão de CS linear, o sistema foi desenhado como 12 fluxos independentes — cada um disparado pelo contexto da ação do usuário, não por uma sequência pré-definida. Segmentação por tipo de negócio (serviços, comércio, varejo) para que a linguagem e as tarefas guiadas fossem relevantes para a realidade de cada perfil.
Visuais: mapa dos 12 fluxos por segmento · telas passo a passo de um fluxo completo · comparação de capacidade de CS antes/depois
A/B · Cluster Serviços · out–nov 2024
+40%Vendas criadas
+37%Notas fiscais criadas
+35%Notas fiscais iniciadas
+20%Vendas iniciadas
+19%Notas fiscais enviadas
Problema: Ajuda contextual aparecia no login — o pior momento possível. Usuários encontravam orientação antes de saber o que precisavam.
Decisão de design: O conteúdo de ajuda foi removido do fluxo de login e reconstruído como banners contextuais disparados no momento em que o usuário entrava em uma área específica pela primeira vez. Cada banner responde a uma pergunta que o usuário teria naquele ponto — não antes, não depois.
Visuais: 3 banners contextuais com pontos de disparo · comparação ajuda no login (antes) vs. banner no momento de necessidade (depois)
+21%Uso total de features
+108,5%Cliques nos CTAsVisão geral · primeiros dias
Problema: Usuários de primeira viagem abriam o produto e não viam nada. Estados vazios comunicavam ausência de dados, não orientação de ação. O botão de ação principal passava despercebido pela hierarquia visual fraca.
Decisão de design: Redesign de todos os estados vazios para serem acionáveis — estrutura fixa: para que esta área serve, qual é a primeira ação, CTA direta. Diferenciação por tipo de estado (vazio real, vazio por filtro, vazio por permissão). Botão +Novo com área de clique maior, maior contraste e posicionamento consistente — expandido em menu contextual que expõe Produto e Serviço diretamente.
Visuais: estados vazios antes/depois em 3 áreas · botão +Novo antes/depois com detalhe do menu contextual
A/B · Menu Split · out–nov 2024
+18,4%Vendas criadas
+20,3%Notas fiscais criadas
+12,1%Nova venda iniciada
+20,2%Nova nota fiscal iniciada
Novos pontos de entrada — dez 2024, 10 dias
1.392Vendas iniciadasExclusivamente pelos novos caminhos
Problema: Emitir uma nota fiscal após uma venda exigia navegar até uma área separada, localizar a venda em uma lista e concluir a emissão de lá. Para quem acabara de criar a primeira venda, esse caminho era completamente invisível.
Decisão de design: Uma CTA adicionada ao momento de confirmação de “salvar venda” — no pico de intenção do usuário. A CTA verifica pré-requisitos antes de disparar: se atendidos, leva direto à tela de emissão pré-preenchida; se não, apresenta o pré-requisito faltante com caminho para resolução.
Visuais: fluxo antes (múltiplos passos) vs. depois (CTA única) · estados de verificação de pré-requisito · tela de emissão pré-preenchida
Inversão do rascunho de NFS · A/B · out–nov 2024
+189%NFS-e criada
+31%Configuração de NFS-e iniciada
+21%NFS-e enviada
CTA direta: em desenvolvimento, Q1 2025.
Problema: O fluxo de emissão de NFS-e bloqueava o usuário com campos desnecessários e pré-requisitos que impediam até mesmo a visualização do próximo passo — criando abandono antes de qualquer tentativa de emissão.
Decisão de design: Antecipação da emissão para vendas avulsas, redução de campos obrigatórios ao mínimo necessário e acesso ao rascunho antes da conclusão de todas as configurações — removendo a lógica de “complete tudo antes de ver qualquer coisa”.
Visuais: mapa do fluxo anterior com pontos de bloqueio vs. fluxo redesenhado · detalhe das etapas removidas
+11%Conversão trials → NF
+16,2%Vendas por contrato
+4,3%NFS-e emitidas
+13,5%NF-e emitidas
Problema: Funcionalidades críticas estavam enterradas em uma estrutura de menu que mostrava tudo para todos, sem hierarquia para usuários de primeira viagem. A descoberta dependia de exploração por tentativa e erro.
Decisão de design: Reestruturação da arquitetura de navegação priorizando funcionalidades de alto valor no primeiro nível de acesso, simplificação da busca global com resultados contextuais e redesign da barra de navegação superior.
Visuais: estrutura de menu antes/depois · busca global com estados de resultado · topbar redesenhada
+600%Acesso a Pix compensado
+233%Acesso a Pix emitido
+100%Acesso a link de pagamento
+41%Acesso a compras
+37%Acesso a relatórios de vendas
Problema: 69% dos usuários em período de teste nunca chegavam à tela de contratação. Mas os que chegavam convertiam em taxas dramaticamente maiores. O produto não tinha nenhum mecanismo para guiar esse caminho.
Decisão de design: Componente de progresso embutido no painel principal — compacto por padrão, expansível sob demanda — com lista curada de tarefas mapeadas aos critérios de ativação. Recompensa tangível (extensão do período de teste) atrelada à conclusão de etapas reais, não a engajamento artificial.
Visuais: componente nos estados recolhido e expandido · lista de tarefas com estados de conclusão · mecânica de recompensa
Base isolada
+500%Conversão de trials para assinatura
+55,71%Trials impactados
+120,34%Engajamento e uso de funcionalidades
Iniciativa pausada estrategicamente por interferência de outro teste no checkout — não por baixo desempenho.
Problema: Antes de criar a primeira venda, o usuário precisava ter clientes cadastrados. Antes de emitir uma nota, precisava ter serviços cadastrados. O preenchimento manual era a parede entre a criação da conta e o valor do produto.
Decisão de design: Fluxo conversacional de importação assistida por IA — o usuário sobe uma planilha, a IA extrai e mapeia os campos automaticamente, o usuário revisa e aprova. Configuração em minutos, não em horas de preenchimento manual.
Visuais: fluxo completo (upload → extração → preview → confirmação) · wireframes conversacional vs. estruturado · tela de revisão
Validação parcial
+44%Interesse na funcionalidade
22%Engajamento ativo
16%Completude do fluxo
Impacto
As métricas por iniciativa estão na seção anterior. Aqui: o que mudou na organização.
Novo time criado
O diagnóstico estruturado gerou visibilidade cross-funcional sobre problemas que nenhum time possuía explicitamente. Mais de 200 oportunidades identificadas deram origem a um time dedicado à qualidade da experiência — responsável por um backlog alimentado integralmente pelos artefatos desta iniciativa, cobrindo áreas do produto que antes não tinham dono.
CS liberado do onboarding
O onboarding padrão migrou de 100% dependente de atendimento humano para autoatendimento — sem aumento de equipe. A capacidade de CS foi realocada para contas complexas, clientes em risco e suporte especializado.
Discovery com IA difundido
A abordagem de pesquisa e síntese assistida por IA foi documentada e passou a ser adaptada por outros designers da equipe — expandindo o impacto do método além do projeto original.
Reflexão
O que este projeto realmente foi
Na superfície, era um projeto de ativação — uma métrica para melhorar, um conjunto de iniciativas para entregar. Na prática, foi um desafio de design de sistemas. O trabalho mais importante aconteceu antes de qualquer tela ser desenhada.
A primeira decisão foi desacelerar: antes de propor soluções, mapear o sistema. Só essa decisão já mudou o escopo do problema. O que o negócio chamava de “um problema de ativação” revelou-se um problema de mensuração, um problema organizacional, um problema de produto e um problema de dados — simultaneamente.
O que permaneceu depois
A medida de uma contribuição em nível staff não é o que foi entregue enquanto você estava lá. É o que a organização está fazendo de forma diferente porque você esteve lá.
Neste case: um novo time. Um novo padrão de mensuração. Uma nova infraestrutura de onboarding. Um modelo de research com IA que outros designers do time começaram a adaptar. As iniciativas são a expressão visível — o sistema que as tornou possíveis é o trabalho real.
O que eu faria diferente
Começaria a parceria com dados na primeira semana, não depois das entrevistas qualitativas. Construiria o blueprint de serviço de forma incremental — como documento vivo — em vez de como artefato final de síntese. E nomearia a restrição de capacidade de CS explicitamente desde o início das conversas com stakeholders: quando uma limitação estrutural é nomeada, ela deixa de ser obstáculo e passa a ser parâmetro de design.
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.