Multidrop - Dual-Persona Sales Platform

Scope: I was the sole product designer in a 35-person B2B2C SaaS (Brazilian engineering, European management). I served as Lead Product Designer + interim Product Manager, reporting directly to the CTO.

Decision authority: Proposed product architecture, defined feature prioritization with the squad, and led validation experiments. For structural decisions (like the dual-persona dashboard architecture), I discussed with the CEO before implementation, but presented the evidence that convinced him.

Timeline: 12 months (Sep 2024 - Aug 2025), working in 2-3 week cycles with continuous releases.

Structural outcome: Transformed 50% abandonment into a viable product model for 100+ productive clients. The shift from 'one product with two conflicting users' to 'one product with two integrated contexts' became the market case that Multidrop still uses for recruitment today.

Multidrop had 50% abandonment in onboarding. I discovered this by cross-referencing Mixpanel data with Hotjar session recordings: new users landed on empty dashboards, clicked 2-3 times with no result, and left. I interviewed 8 users who abandoned to understand why: the problem ran deeper than UI.

The product served two completely different personas. The Creator wants to build products, set up checkout, manage affiliates, and analyze revenue. The Affiliate wants to find products to promote, track commissions, and view performance. The dashboard treated both as the same user.

The CEO wanted two separate products. I convinced him that would double maintenance costs and fragment the user base. The alternative: one product with two contexts. It took 3 weeks of prototyping and 2 rounds of testing with 12 users to prove the persona toggle worked.

The first version of the toggle was a dropdown in settings. In testing, 4 of 6 users couldn't find it. The second iteration: a toggle visible in the header, hit 100% discovery in the same tests.

The toggle completely changes: sidebar navigation, dashboard metrics, KPI cards, and available flows.

For the Creator: gross revenue, revenue source (direct vs. affiliate), trends over time, sales by product and affiliate.

For the Affiliate: total commissions, pending balance, next payout, clicks and conversions.

The engineering team resisted: 'it's like maintaining two apps.' I showed that 70% of components were shared. The frontend lead approved after reviewing the Figma prototype.

First attempt: a guided tour with tooltips (industry standard). Hotjar showed 80% of users closed it at the second tooltip. The tour taught features instead of answering 'what do I do first?'

The iteration that worked: turning the dashboard into a visible progress space. The 'Getting Started' widget with a progress ring (starting at 0%) isn't a tutorial; it's a list of unlockable wins. Each step saves server-side, so unstable connections don't lose progress.

For the Creator: 4 steps. For the Affiliate: 3 steps. Same system, tuned per persona.

Measurement: Compared onboarding completion 30 days before and after deploy (Mixpanel, new signups only). Abandonment dropped from 50% to 25%, validated with Multidrop's data team.

The split-screen signup was a decision I defended against marketing, who wanted a simple form 'like everyone else.' For a European startup competing with Hotmart and Eduzz, the visual needed to say 'we're different' before the user read a word. Left: clean form, Google OAuth first. Right: dark, fluid, premium imagery.

The role selection screen (Creator vs. Affiliate) right after signup is where the system first splits. Radio cards with icons and plain-language descriptions, tested with 5 users who'd never used info-product platforms.

Most systems treat refunds as compliance: a generic form to avoid chargebacks. I proposed to the PM that the 6 refund reasons ('Can't access yet,' 'Quality below expectations'...) be treated as product data, not just legal categories.

For the buyer: 3-step flow: find purchase by email, see details with deadline, select categorized reason.

For the Creator/Multidrop: each reason feeds a quality dashboard. 'Can't access yet' repeated 15 times for one product? Broken onboarding signal.

The PM wanted generic Stripe reasons. I showed that generic 'Other' accounted for 60% of selections, useless data. With domain-specific reasons, 'Other' dropped to 12%.

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.