Deliveroo only makes money when an order gets delivered. The M+ segment, restaurants using their own drivers, had no fallback when their fleet failed. No rider network to switch to. Just cancelled orders, lost revenue, and partners one bad Friday away from questioning whether the platform was worth it.
M+ partners were a majority of merchant volume, restaurants that had opted into running their own delivery operations for more control. But that control came with a cost. When their fleet failed, there was no fallback.
The design constraint made it harder. Any solution had to work in a commercial kitchen, mid-service, on a tablet, in under 10 seconds.
I embedded with restaurant operations teams mid-service, not in meeting rooms, but in actual kitchens during dinner rush.
The insight that reframed everything came from a manager in Birmingham: "Your app assumes I'm sitting at a desk thinking about logistics. I'm actually running between a burning stove and an angry customer."
Partners didn't want automation. They wanted confidence that the switch would work. The fear wasn't the action, it was the uncertainty after. That synthesis shaped the solution.
My first design was over-engineered. A rule-based system: if driver availability drops below X, automatically switch to Deliveroo. The prototype tested badly. Restaurant managers looked at me like I'd handed them a spacecraft manual.
The breakthrough came from a manager in Manchester: "Just give me a big button that says Help and make the rest disappear."
That's what I built. One toggle. A confirmation modal that set expectations before the switch, what changes and how to undo it. Prep time configuration so partners could control timing, because research showed that was their single biggest anxiety. Unified order tracking regardless of which fleet was active, so switching fleets didn't mean switching mental models.
I scoped to on-the-fly switching first, the highest-frequency failure scenario: driver no-show mid-service. Scheduled switching, cross-site fleet management, and predictive demand signals were explicitly deferred. Not cut, documented and sequenced for Phase 2.
Fleet Switching kept surfacing the same feedback: "This is great, but why can't the rest of Deliveroo work this simply?"
I mapped every partner-facing touchpoint across the platform. There were 12 separate interfaces for managing restaurant operations. Some partners had never discovered half of them. The fragmentation wasn't just a UX problem. Product teams building into Hub had no shared model of who they were designing for, which meant every new feature made it slightly worse.
I ran a lifecycle mapping workshop with PM, research, and engineering. We mapped seven milestones from onboarded to customer champion. For each one: what is the partner trying to do, what does Deliveroo need, and where is Hub helping or getting in the way? That map became the shared language for the entire initiative.
The lifecycle mapping surfaced a finding that shaped the entire approach: partners weren't just at different stages. They were in fundamentally different modes.
New partners needed a task-led interface. Setup checklist front and centre. No analytics they don't have data for yet. One goal: get them live and confident.
Active partners needed performance and growth signals. Order trends, ratings, live activity. Context-aware tips sourced from account managers and platform data. The interface shifts from telling them what to do to helping them improve.
High performers needed intelligence, not hand-holding. Market trend signals, competitive positioning, expansion prompts. The most information-dense state. They had the context to use it.
Hub adapts to the partner. Not the other way round.
Hub was shared infrastructure. Any redesign owned by a single team would eventually become another layer of fragmentation.
The solution had to work at two levels. A UX layer: what gets surfaced, in what order, based on where a partner is in their lifecycle. And a governance layer: a modular framework that gave other product teams designated ownership of sections in Hub, with explicit rules about content type, context, and sequencing.
The governance piece is what made the UX work sustainable. Without it, teams would have continued building into Hub however felt right to them. With it, the design system had teeth.
Fleet Switching: 30% reduction in order cancellations due to driver shortages. 25% improvement in on-time delivery rates. 15% increase in order fulfilment for M+ partners during peak hours.
Hub: 40% improvement in turnaround time for Hub product teams. 15% improvement in active partner performance metrics. 10% improvement in early engagement and retention in the first 30 days.
The 40% turnaround improvement is the one I'm most proud of. It tells you this wasn't just a UX project. It changed how a large organisation built product.
Both projects ask the same question: how do you build a product for users who are fundamentally different without creating something fundamentally fragmented?
Fleet Switching answers it at the feature level: hide complexity until someone needs it, then give full control. Hub answers it at the system level: build infrastructure that adapts by context, not one-size-fits-all logic.
On instrumentation: I had the macro numbers after Fleet Switching launched. Fulfilment rates improved, cancellations dropped. But I didn't have clear signal on how partners were actually using the toggle. Were they switching proactively at the start of a shift, or reactively when a driver didn't show? That distinction matters enormously for how a feature evolves. I now push earlier in every project to define not just success metrics, but the specific behavioural signals needed after launch. Outcome data tells you if it worked. Behaviour data tells you what to do next.
