Multi-model courier onboarding

Took over Wolt's multi-model courier onboarding mid-flight as part of the DoorDash platform consolidation. Restructured web entry as a model-routing layer across four legal engagement models in nine countries, after concrete PM feedback that the original approach was misrouting users.

  • Logistics
  • Platform
Wolt courier onboarding — case study

Context

Wolt operates courier networks across 9+ countries with four distinct engagement models: independent contractors, fleet operators, direct employees, and temp agency workers (Sweden). The company is consolidating its platform with DoorDash, which required unifying the courier onboarding experience across all models and markets. I picked this up from the previous designer mid-flight, inheriting both the work and the critical feedback that came with it.

Challenge

The existing onboarding reused mobile app designs on web. Employment benefits were leaking into IC flows. Users were not being routed to the correct funnel from the entry point. This was not just a UX problem — it was a compliance problem. A screen appropriate for an independent contractor can create legal exposure if shown to someone under an employment model in the same country. The PM's feedback was direct: the core problem hadn't been solved.

My role

I took over design ownership and absorbed the PM's feedback without trying to defend the prior work. Restructuring was the right move — protecting a broken foundation would have delayed the real fix. I shaped a model-aware acquisition flow with a shared spine and model-specific branches, working directly with the PM and regional onboarding leads.

What I changed

  • Rebuilt web entry as a model-routing layer. Each engagement type routes to the correct funnel from the first screen. IC flows no longer show employment benefits. Employment flows no longer use IC-language. The routing logic is explicit, not implicit in conditional show/hide.
  • Kept a single shared spine. The steps common to all models — identity verification, vehicle type, document upload — are handled once. Model-specific steps branch off cleanly. This approach reduces maintenance as the DoorDash platform consolidation extends the flow.
  • Separated branding and copy per engagement model while keeping one visual system. An IC flow and an employment flow look like Wolt but carry different content, different data-handling logic, and different compliance language.
  • Cut full web/app unification from scope. Designed web entry as a model-routing layer first. The full unification can follow once the routing logic is proven in production.

Outcome

Handed off with each engagement model in a defined funnel, ready for integration into the DoorDash platform consolidation. No post-launch conversion metrics were instrumented during my engagement. The directional outcome: each user type is now correctly routed from entry, compliance-sensitive content is model-specific, and the flow can be extended without restructuring the entry layer.

Have a product flow that feels harder to explain than it should?

Send me your product, MVP, deck, or prototype. I'll tell you where I'd start.