Delivery Hero · 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

ScopeDelivery Hero brands · scaled across 19 markets

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

A grid of Delivery Hero app screens — order summary, restaurant browse, food categories, item detail, cart, and a delivery map — laid out across stylized iPhone frames on a white background.

Context

Delivery Hero is 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.

Four bold black circles with white numbers on a white background — >500 thousand restaurant partners, 791 mlns orders processed in Q3 2021, 50 markets on four continents, 12 brands onboard. — The scale "Location" had to work at — Delivery Hero in 2021.

World map with two pink pins — a '7' over Northern Europe (Finland, Norway, Sweden) and a '12' over Southeast Asia (Thailand, Pakistan, Singapore, Malaysia, Taiwan, Bangladesh, Hong Kong, Philippines, Romania, Cambodia, Laos, Myanmar, Slovakia, Hungary, Germany, Japan). — Delivery Hero's footprint — 7 markets in Northern Europe, 12 across APAC and Eastern Europe.

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.

How to find someone in Germany — Google Maps screenshot of Fischerinsel 14, Berlin pinned with the exact street address, beside a photo of the building's doorbell panel showing labelled name tags (Nieberle Forster, Rappl Kratzlmeier, Schafbauer, Wolff, Aicher Aßheuer). — Berlin — geocoding alone gets you to the doorbell.

How to find someone in Pakistan — three stacked Google Maps screenshots of Karachi addresses (Sania Heaven, Frontier Colony 1) sitting inside large neighbourhood outlines with hand-drawn building shapes and few labelled streets. — Karachi — geocoding gets you to the neighbourhood, not the door.

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 hovering at ~31% of orders dropping >150m from the pin, Pakistan ~28%, Philippines ~15% — versus <5% across Northern Europe

Heatmap table titled '% Near Dropoff - Wow' showing weekly drop-off rates by country across weeks 36–41 of 2018. Bangladesh (~31%) and Pakistan (~28%) are deepest red, Philippines (~15%) is mid-red; Northern European markets (Romania, Italy, Netherlands, Austria) sit in green near 3–7%. — Drop-off accuracy by market — APAC dominates the red.

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 the app 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.

iPhone showing the V2 'Refine location' screen — a Karachi street map with a single pink pin centered on Ridan House of Mandi, an Apply CTA at the bottom. — V2 — the pin gets a small bounce on placement; the map becomes the source of truth.

Note to rider — what users actually wanted to say

We kept the free-text "note to rider" field, but only after auditing what people were writing in it. The signal was clear: the field wasn't being misused as an address — it was carrying genuinely useful, geocoder-invisible context. Killing it to force address structure would have made deliveries worse, not better.

A loose cluster of seven hand-set quotes in navy — Don't ring the bell, Call my number when here, House number 2, Second entrance, Food should be hot and spicy, Add extra mayo, House next to the mosque. — Real "note to rider" entries — half logistics, half hospitality, all useful.

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. I flew out, sat with the local managers, did delivery shifts with riders, shadowed customer support, visited partner restaurants, and ordered as a regular customer for a week.

A photo of the designer wearing a pink Delivery Hero rider backpack in the Karachi office lobby, smiling beside a 'Delivery fee? Nahi ab hai delivery free!' standee. — Riding deliveries in Karachi — the only way to see the funnel from the inside.

The trip surfaced the actual reason the A/B underperformed: address data degrades as it flows down the funnel. The structured pin a customer sets at checkout doesn't stay structured. It gets reformatted by the restaurant's order system, re-typed onto a packing slip, eyeballed by the rider, and finally re-explained over the phone to customer support. By the time it lands at someone who can act on it, the precision is gone.

An iceberg above water labelled 'Client app' with three larger sections submerged below — Restaurant app, Rider app, and Customer support app — illustrating that the consumer-facing surface is only a small visible part of the address-data pipeline. — The client app is the visible tip. Address data degrades all the way down.

Two photos — left: a rider's Android phone showing an order with an all-caps free-text instruction 'EVERYTHING SHOULD BE SPICY' and a long address blob; right: a laptop screen of a restaurant's order-management portal printing a packing slip without structured address fields. — Some big chains (KFC) ran their own order systems — they never received the structured address at all.

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.

A loose collage of eight 'Delivery details' phone screens from Hong Kong, Espoo, Chiang Mai, Taichung City, Oslo, Singapore, Toronto and Östersund — each map pin sits above a localized form with country-specific fields (Room/Floor/Block, Entrance, Floor, Apartment, Intercom, etc.). — Address details rolled out across Delivery Hero markets — localized per geography.

Impact

Cut into the 13k+/month "vendor doesn't deliver" cancellations and the €78k/month revenue leak.

All three secondary KPIs improved on monitoring — overall CVR, mCVR in checkout, and rider drop-off accuracy.

Drop-off accuracy moved off the 15%+ APAC baseline that anchored the case.

Map-based picker rolled out across Delivery Hero brands · 19 markets.

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