Multidrop: abandono do onboarding caiu pela metade

A Multidrop investia pesado em marketing e anúncios para atrair criadores de infoprodutos. Os usuários chegavam, criavam conta e travavam antes da primeira ação ligada à receita: criar o primeiro produto e o link de venda, ou se afiliar a um produto para começar a promover.

Sem essa primeira ação, o cadastro não chegava a gerar receita. Parte das pessoas vindas dos anúncios abandonava o fluxo nessa etapa.

O produto estava tecnicamente pronto havia anos. O gargalo era experiência. Reestruturei a arquitetura de persona, reescrevi o onboarding depois de uma primeira tentativa que falhou e usei os motivos de reembolso para entender problemas do produto.

Escopo: atuei como Lead Product Designer e, na prática, como head de produto: cuidava de design e produto e treinava um product designer júnior.

Autoridade de decisão: propus a arquitetura de produto, defini a priorização com o squad e conduzi experimentos de validação. Nas decisões estruturais, levei evidência ao CEO antes da implementação.

Período: set 2024 a ago 2025.

O que eu medi: o abandono do onboarding caiu de 50% para 25% depois do redesign de ativação, no funil que montei no Mixpanel.

O que a empresa alcançou: no primeiro ano após o redesign de ativação, a base passou de 0 para 100 clientes pagantes, e as vendas somaram €14 milhões. Esses números também dependem de marketing, vendas e engenharia, por isso não os atribuo só ao design.

Como achei o gargalo: montei no Mixpanel o funil do cadastro até a primeira ação ligada à receita. Antes do redesign, 50% dos novos cadastros abandonavam o onboarding antes dessa ação.

Cruzei esse dado com sessões gravadas no Hotjar. O padrão se repetia: o usuário caía num dashboard vazio, clicava duas ou três vezes sem resultado e saía. Ele também via as métricas da outra persona e não entendia por onde começar.

Conversei com usuários que abandonaram e organizei os relatos por tema. Faltava um próximo passo coerente com o objetivo de cada pessoa.

O produto servia duas personas completamente distintas. O Produtor quer criar produtos, configurar checkout, gerenciar afiliados e analisar faturamento. O Afiliado quer encontrar produtos para promover, acompanhar comissões e ver o próprio desempenho. O dashboard tratava os dois como o mesmo usuário e mostrava métricas erradas para cada lado. As duas personas enfrentavam dificuldades para chegar à primeira ação de receita.

O CEO queria dois produtos separados. Defendi um único produto com dois contextos para preservar componentes compartilhados e evitar fragmentar a base.

A tela abaixo reconstrói, sobre o produto atual, o dashboard único que o usuário novo encontrava: métricas das duas personas no mesmo lugar e nenhum próximo passo.

Havia alternativas diferentes para a arquitetura.

Alternativa A (pedida pelo CEO): dois produtos separados. Dobra o custo de código, fragmenta a base e fragmenta a marca.

Alternativa B: manter o produto único como estava. Continua com 50% de abandono.

Alternativa C (minha proposta): um produto com dois contextos. Componentes compartilhados, toggle explícito entre Produtor e Afiliado, navegação e métricas calibradas por contexto.

Como defendi a proposta: montei no Figma uma análise de reuso com variantes componentizadas. Não eram dois aplicativos independentes, mas um produto com contextos diferentes.

A engenharia resistiu no início: "é como manter dois apps." Apresentei a arquitetura de componentes compartilhados com alternância de contexto e um protótipo navegável com variantes. O lead de front-end aprovou depois de revisar.

Para o Produtor: foco em faturamento bruto, origem da receita (direta ou por afiliados), evolução no tempo e tabela de vendas por produto e afiliado.

Para o Afiliado: foco em comissões totais, saldo pendente, próximo pagamento, cliques e conversões.

Esta é a decisão estrutural do case. A proposta preservou a base compartilhada e abriu caminho para o redesign do onboarding.

Decidida a arquitetura dual persona, a pergunta seguinte era prática: onde colocar o toggle que alterna o contexto.

Primeira iteração: dropdown nas configurações. Nos testes de descoberta, o controle ficou escondido e os usuários operavam no contexto errado.

Segunda iteração: toggle visível no cabeçalho, com uma etiqueta explícita para a troca de contexto. A mudança tornou o controle encontrável nos testes.

Parece detalhe pequeno. Não é. O toggle é a porta do produto: onde o seletor de contexto fica determina se o usuário consegue operar e, por consequência, se fica ou abandona. É o mesmo princípio que decide onde ficam o seletor de conta, de cliente ou de visão em qualquer dashboard operacional complexo.

A primeira tentativa de onboarding foi um tour guiado com tooltips. As sessões gravadas mostraram que o formato ensinava funções, mas não respondia ao que o usuário deveria fazer primeiro.

Falhou porque ensinava features sem resolver a ansiedade real: "o que eu faço primeiro". Usuário novo não quer tutorial. Quer saber se vale a pena investir tempo no produto.

A iteração que funcionou: transformar o próprio dashboard no tutorial. O widget "Primeiros Passos" funciona como uma lista de conquistas desbloqueáveis, com um anel de progresso que começa em 0%. Cada passo salva o estado no servidor, então conexão instável não apaga o progresso.

O mesmo sistema passou a apresentar tarefas calibradas pelo contexto do usuário.

Medição: comparei no Mixpanel o abandono do onboarding antes e depois do redesign de ativação, numa janela de 30 dias (n=3,1 mil novos cadastros). O abandono caiu de 50% para 25%, 25 pontos percentuais a menos.

A maioria dos sistemas trata reembolso como compliance: formulário genérico com "Outro" como escape, feito para evitar chargeback e nada mais.

Propus tratar reembolso como dado de produto, não só como categoria legal, com motivos específicos do domínio.

O histórico mostrava que a categoria genérica "Outro" não explicava por que as pessoas pediam reembolso. O formulário anterior aparece abaixo como reconstrução sobre o produto atual.

Separei "Não reconheço essa compra" do reembolso: esse motivo vai para investigação antifraude, não para devolução. Os outros motivos dizem o que deu errado (acesso, entrega, escopo, falta de resposta do produtor ou falha técnica).

Depois do redesign, cada reembolso passou a alimentar um painel de qualidade, por produto e por motivo, e a funcionar como pesquisa de saída.

Dois pilares paralelos sustentaram as decisões acima.

Design system do zero. Tokens de cor, espaçamento, tipografia e grid, com governança compartilhada entre design e engenharia.

Isso foi precondição da arquitetura dual persona. Sem o sistema, o produto compartilhado teria se fragmentado.

IA no fluxo de design. Usei Cursor e Claude Code para testar hipóteses em protótipo antes do refinamento final.