Multidrop - Plataforma de Vendas com Dupla Persona

Escopo: Fui o único product designer em uma SaaS B2B2C de 35 pessoas (engenharia brasileira, gestão europeia). Atuei como Lead Product Designer + Product Manager interino, reportando diretamente ao CTO.

Autoridade de decisão: Propus a arquitetura do produto, defini a priorização de features com o squad e conduzi experimentos de validação. Em decisões estruturais (como a arquitetura do dashboard dual-persona), eu alinhava com o CEO antes da implementação, mas levei as evidências que o convenceram.

Timeline: 12 meses (set 2024 - ago 2025), trabalhando em ciclos de 2-3 semanas com entregas contínuas.

Resultado estrutural: Transformei 50% de abandono em um modelo de produto viável para 100+ clientes produtivos. A mudança de 'um produto com dois usuários conflitantes' para 'um produto com dois contextos integrados' virou o case de mercado que a Multidrop ainda usa em recrutamento.

O Multidrop tinha 50% de abandono no onboarding. Descobri isso cruzando dados do Mixpanel com gravações do Hotjar e 8 entrevistas de saída. O Hotjar revelou um padrão: usuários chegavam ao passo de seleção de tipo de empresa e paravam. Mas o dado mais revelador veio das entrevistas: eles não entendiam se o produto era para eles. O produto tem duas personas: entregador autônomo e empresa logística, com fluxos, preços e funcionalidades radicalmente diferentes. A tela inicial não deixava isso claro.

A primeira versão do toggle era um dropdown nas configurações. Nos testes, 4 de 6 usuários não o encontraram: alternavam entre contas sem entender que o modo mudava a interface inteira. Propus um toggle no header, visível em todas as telas. Resistência interna: "vai confundir." Contra-argumento: invisibilidade já estava confundindo. Novo teste: 6 de 6 encontraram. Construímos ~70% dos componentes compartilhados entre as duas personas, com redução de escopo técnico e consistência visual.

Primeira tentativa: tour guiado com tooltips (padrão do setor). O Hotjar mostrou 80% fechando no passo 2. Motivo: usuários queriam explorar, não ser guiados. Segunda tentativa: progress ring, com tarefas de ativação exibidas como checklist circular. Resultado: abandono caiu de 50% para 25% (3.1k usuários, 30 dias). O que funcionou: autonomia. Usuários completavam tarefas na ordem que fazia sentido para eles, não para nós.

A tela de cadastro dividida era uma decisão que defendi contra o marketing, que queria um formulário único para "não perder conversões." Meu argumento: o produto tem propostas de valor fundamentalmente diferentes para cada persona. Mostrar as duas lado a lado no primeiro toque não aumentaria a taxa de cadastro: aumentaria a clareza. Produção confirmou: o novo cadastro reduziu o abandono no passo de seleção de persona em 35%.

A maioria dos sistemas trata reembolsos como compliance: um formulário genérico para evitar chargebacks. Eu propus algo diferente: motivos de reembolso como dado de produto. Primeira versão: motivos genéricos. 60% dos usuários caíam em "Outro" (n=420), dado inutilizável. Segunda versão: motivos específicos do domínio logístico. "Outro" caiu para 12% (n=890). Esse dado passou a alimentar diretamente o backlog de produto.

Dois pilares paralelos que sustentaram todas as decisões acima.

Design system do zero. Tokens de cor, espaçamento, tipografia, e grid. Quatro breakpoints: Mobile, Tablet, Desktop, Ultrawide. Governança explícita: designer aprovava componente novo, engenharia aprovava token novo. Documentação no Figma com correspondência 1:1 no código.

Isso foi precondição da arquitetura dual persona. Sem DS, reusar 70% dos componentes entre Produtor e Afiliado seria impossível sem virar dois apps de verdade.

AI no fluxo interno de design. Pioneirei uso de Cursor, Claude Code, e AI agents para prototipar e validar hipóteses antes de mandar para design final. Tempo de protótipo caiu de 2 dias para 3 horas em fluxos novos. Essa experiência prática é a base do livro que escrevo hoje, "Design na Era da IA".

O princípio que levo para qualquer contexto, incluindo design systems corporativos maduros: DS não é entrega, é precondição. Tokens centralizados, governança clara, e AI como acelerador de validação são o que permitem squads entregarem em paralelo sem comer consistência.