Multidrop - Plataforma de Ventas con Doble Perfil

Alcance: Fui el único product designer en una SaaS B2B2C de 35 personas (ingeniería brasileña y gestión europea). Actué como Lead Product Designer + Product Manager interino, reportando directamente al CTO.

Autoridad de decisión: Propuse la arquitectura del producto, definí la priorización de funcionalidades con el squad y lideré experimentos de validación. En decisiones estructurales, como la arquitectura del dashboard dual-persona, alineaba con el CEO antes de implementar, pero llevé la evidencia que terminó convenciéndolo.

Timeline: 12 meses (sep 2024 - ago 2025), trabajando en ciclos de 2-3 semanas con lanzamientos continuos.

Resultado estructural: Transformé un 50% de abandono en un modelo de producto viable para más de 100 clientes productivos. El cambio de 'un producto con dos usuarios en conflicto' a 'un producto con dos contextos integrados' se convirtió en el caso de mercado que Multidrop todavía usa para reclutamiento.

Multidrop tenía un 50% de abandono en el onboarding. Lo descubrí cruzando datos de Mixpanel con grabaciones de Hotjar y 8 entrevistas de salida. El Hotjar reveló un patrón: los usuarios llegaban al paso de selección de tipo de empresa y se detenían. El dato más revelador vino de las entrevistas: no entendían si el producto era para ellos. El producto tiene dos personas: repartidor autónomo y empresa logistica, con flujos, precios y funcionalidades radicalmente diferentes. La pantalla inicial no lo dejaba claro.

La primera versión del toggle era un menú desplegable en la configuración. En las pruebas, 4 de 6 usuarios no lo encontraron: cambiaban entre cuentas sin entender que el modo cambiaba toda la interfaz. Propuse un toggle en el encabezado, visible en todas las pantallas. Resistencia interna: "va a confundir." Contraargumento: la invisibilidad ya estaba confundiendo. Nueva prueba: 6 de 6 lo encontraron. Construimos ~70% de los componentes compartidos entre las dos personas, con reducción del alcance técnico y consistencia visual.

Primer intento: tour guiado con tooltips (estándar del sector). Hotjar mostró que el 80% cerraba en el paso 2. Razón: los usuarios querían explorar, no ser guiados. Segundo intento: progress ring, con tareas de activación mostradas como lista circular. Resultado: el abandono bajó del 50% al 25% (3.1k usuarios, 30 días). Lo que funcionó: autonomía. Los usuarios completaban las tareas en el orden que tenía sentido para ellos, no para nosotros.

La pantalla de registro dividida era una decisión que defendí contra marketing, que quería un formulario único para "no perder conversiones." Mi argumento: el producto tiene propuestas de valor fundamentalmente diferentes para cada persona. Mostrar las dos lado a lado en el primer contacto no aumentaría la tasa de registro: aumentaría la claridad. Producción confirmó: el nuevo registro redujo el abandono en el paso de selección de persona en un 35%.

La mayoría de los sistemas tratan los reembolsos como cumplimiento: un formulario genérico para evitar contracargos. Propuse algo diferente: motivos de reembolso como dato de producto. Primera versión: motivos genéricos. El 60% de los usuarios cayó en "Otro" (n=420), dato inutilizable. Segunda versión: motivos específicos del dominio logístico. "Otro" bajó al 12% (n=890). Este dato comenzó a alimentar directamente el backlog de producto.

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.