foodpanda · Location

Rebuilding delivery-address selection from text-only autofill into a map-based picker — validated by riding along with couriers in Pakistan and scaled across the platform.

RoleSenior Product Designer · Design lead for location

Timeline2018 – 2020

PlatformiOS · Android · Web · mWeb

Scopefoodpanda & sister brands · scaled across 19 markets

TeamProduct, Engineering, Research, Local market POs, Riders & Customer Support (field)

Context

foodpanda sits inside Delivery Hero — a marketplace at platform scale: 500k+ restaurant partners, 791M orders processed in Q3 2021, 12 brands, 50 markets across four continents. "Location" is the entry point to all of it: pick the wrong address and the whole funnel breaks downstream.

Challenge

The address experience had three jobs to do at once — and was failing all three:

Conversion. Help users find restaurants nearby their actual delivery location
Cancellations. Validate, before checkout, that the chosen restaurant actually delivers to the entered address
Accuracy. Let riders understand where to deliver — not just what the auto-fill said

Delivery details in checkout were displayed only in text, auto-filled from Google geocoding. That's fine for Berlin or Helsinki, where an address is a postcode + street + number. It breaks in Karachi, Dhaka, Manila — where the operative unit is a landmark, a courier's local knowledge, or a multi-step description ("house next to the mosque", "second entrance"). The text-only flow couldn't carry that information.

What it cost

13k+ orders cancelled monthly (0.36%) for the reason "vendor doesn't deliver to selected address" — roughly €78k of revenue lost every month
Drop-off accuracy especially poor in APAC — Bangladesh, Pakistan, the Philippines — with over 15% of orders dropping more than 150m from the intended pin

My role

Design lead for the topic of location. I owned the address experience end-to-end across iOS, Android, web, and mWeb — from problem framing and competitive benchmarking, through prototyping and user testing, into field research, A/B testing, and platform-wide rollout.

Reframed the leadership ask from "address picker fix" to "location is a system problem"
Designed V1 and V2 of the map-based picker — including the subtle map and pin motion that re-anchors the screen's visual hierarchy on the map as the source of truth
Ran moderated user testing on prototypes — caught real-world failure modes (users tempted to type instead of confirming on map; "Home / Work / Other" labels making no sense without a "Label as" header)
Ran a full field research trip in Pakistan after the first A/B failed — shadowed local managers, delivered food with riders, sat with customer support, talked with restaurant owners, used foodpanda as a customer
Translated insights back into design — including the data-flow problem (Client → Restaurant → Rider → Support) and the audio-first preference that shaped the rider-chat feature
Drove rollout to web and mWeb for cross-surface consistency, and aligned the picker with the new checkout flow

Key design moments

From text autofill to map as source of truth

The redesign moved the map from a passive preview to the primary element of the screen. Subtle map animation and a small pin animation on placement signal — without copy — that the map is what the system trusts. Free-text "note to rider" remained, because in Pakistan that field carries genuinely useful information ("call my number when here", "second entrance"). The redesign respects that without elevating it above the pin.

Honest about a failed A/B

The first prototype shipped as an A/B test in Pakistan and showed no significant improvement. That's a result, not a defeat — and it's what triggered the field trip. Sometimes the most honest design move is admitting the hypothesis was incomplete.

Field research as the only honest approach

You cannot design address UX for Karachi from a desk in Berlin. The field trip surfaced the actual reason the A/B underperformed: address data degrades as it moves down the funnel. Client → Restaurant → Rider → Customer Support. Some big chains (KFC) used their own order-management systems and weren't even receiving address data in the expected format. No amount of front-end polish was going to fix that on its own.

Audio over text for rider communication

Riders and customers preferred voice. That insight shaped how we built the rider-chat feature — a small example of how a UI decision lives downstream of a research finding rather than upstream of one.

Scaling — and consistency with the new checkout

V2 rolled out across markets and was extended to web and mWeb so the address data captured was consistent regardless of surface. Pin icons, copy, and map access points were aligned with the new checkout flow rather than treated as a separate vertical.

Impact

Order cancellations for "vendor doesn't deliver" came down.

mCVR for address submitted in checkout went up.

Rider drop-off accuracy improved across markets.

Map-based picker scaled across foodpanda & sister brands.

What I took away

The user-facing interface is a small slice of the actual business ecosystem; if the data degrades downstream of the screen, the screen can't save you
The fastest way to deeply understand a market is to put yourself inside it — ride along, deliver food, sit with support
Doing efficient field research is itself a craft

Systems Thinking Field & User Research Multi-market Product Design Maps & Geocoding UX A/B testing Cross-surface consistency Cross-functional alignment