Driver: The Last Mile of Delivery, Until Handover

Groceries in minutes sounds simple until you follow a courier into the last 50 meters. Astro is an Indonesian quick-commerce service that delivers via “dark stores” and motorbike couriers, and the moment where the promise breaks is almost never the ride it’s the arrival and the handover. The driver is moving, outdoors, in a hurry, often one-handed on a motorbike with sun glare on the screen. That’s the reality this project designs for.

In this case study I redesigned the arrival-and-handover experience in the Astro Driver App, focusing on the journey of Awareness → Assurance → Delivery → Return to Hub. The business goals were concrete: improve delivery time, reduce wrong-address deliveries, and reduce customer complaints. This is an end-to-end walkthrough discovery, research, synthesis, two design bets, wireframes, high-fidelity flows, and an honest account of what design couldn’t solve in five days.

Two prompts framed the work the same moment (arrival → handover) seen through two different lenses:

Scenario 1 The “Last 50 Meters.”

A customer has been waiting a long time. The driver has the address but still can’t pinpoint the exact spot: the pin is slightly off, the gate isn’t obvious, the building is hard to find, or the address text is ambiguous. How do we get the driver from “I’ve arrived in the area” to the customer’s door?

Scenario 2 The “Silent Handover.”

The customer doesn’t want a phone call busy, in a meeting, or not home and wants the order left somewhere. How do we design the handover without a phone call as the primary action?

The Indonesia-specific reality shaped every decision: dense kampung alleys, unnamed streets, inconsistent house numbering, gated complexes, security posts (satpam), one-way lanes, and GPS drift in narrow lanes with a driver who’s rushing, incentivized by speed, and juggling the next order.

Core challenge:

How might we help drivers complete the arrival and handover accurately pinpointing the exact spot when the pin is off, and completing a safe handover when the customer is unreachable without leaning on a phone call or a call to CS?

Discover What the field said

The pin can’t be trusted, contact is fragile, and CS quietly holds it all together.

Maturity callout: The sources disagreed on contact two said broken, Apri said “fine so far.” I didn’t average it away: contact is inconsistent, and WA (the old fallback) is gone. Note: unilateral cancellation and chat/phone routing are system/policy issues acknowledged, not solved in the arrival UI.

The insights held from three angles:

Every insight mapped back to a stated Astro objective: wrong-address ← pin can’t be trusted; complaints ← fragile contact + drop-instruction-ignored; delivery time ← the 200m notification (customer ready on arrival).

Define Two design bets

Scenario 1 HMW:

Help the driver find the exact spot when the pin is off by replicating what they already do manually (landmarks, house-number sequencing, asking around) without calling CS.

Scenario 2 HMW:

Ensure the customer’s drop instruction reaches the driver clearly and actionably on arrival, let the driver assess safety and capture photo proof, so the handover completes without a phone call and without a unilateral cancellation. (This one attacks the correct root the instruction never arrives rather than the symptom of a “missing drop feature.”)

I killed the strongest idea for the right reason. The tempting option was to overlay landmarks inside an in-app map. I rejected it on three field constraints: the Astro Driver App has no in-app map (“Buka Maps” hands off to Google Maps confirmed by driver Hermawan); building one adds cost and time; and the Driver App must stay light because many drivers use low-end phones a heavy map burdens the very people it serves.

The approach Scenario 1: crowdsourced landmarks, kept light

Two sources fill the same gap and cover each other. Customers add a photo + text at calm, high-motivation moments (address setup, post-failure, tracking, checkout nudge for risky addresses). Drivers correct or add after delivery, which persists for the next driver so a new address the customer skipped is covered by the first driver’s fix.

The driver experience is awareness without interruption the driver decides when to look:

1. 200m → tappable early-warning banner in the destination card; orange to stay legible in daylight
2. 50m → escalates (close now, don’t overshoot)
3. Tap → pop-up with photo + text
4. Two one-tap actions: “tidak sesuai” (opens correction) · “sudah sesuai” (optional, not a gate)
5. Mark now, fill later: flag in the rush, add detail after delivery

Three sub-flows, one loop: Sources (customer + driver) → Awareness (banner → view) → Accuracy (confirm / correct), with driver corrections feeding back to sources. One loop, not three features the system gets better the more it’s used.

The approach Scenario 2: permission and judgment must pair

The problem isn’t a missing “drop” feature the instruction never reaches the driver. Customers already write “titip ke satpam / depan pintu,” but drivers miss it, call, or cancel. The real problem has three layers: the instruction must arrive, the driver must judge safety, and the handover needs proof.

Permission without judgment drops parcels in unsafe spots; judgment without permission makes the driver liable. They must pair.

The handover screen one form, an adaptive banner. The same “Pengecekan Paket” screen serves both branches; nothing new to learn. Photo stays the existing “Foto Paket” step (Langkah 2), unchanged. The banner is two-state and it acts, not just informs:

1. Ada izin: shows the customer’s instruction read-only → guides driver to photo + a tap-select “Diserahkan ke:” ([Penerima] [Satpam] [Depan pintu] [Loker], no typing; satpam/locker shown only where they exist)
2. Tak ada izin: blocks the drop “Selesai Antar” is gated, and the primary action becomes “Hubungi CS,” so the driver can’t leave a parcel unauthorises

Rationale: a banner alone can be ignored, so in the no-permission state, completion is gated not just warned. Escalation reuses “Bantuan CS,” already in the header. The 10-minute wait is an escalation trigger, not a liability transfer to the customer.

High-fidelity flows (walkthrough)

Scenario 1 Last 50 Meters:

1. Landmark awareness: Reusing the 200m auto-reminder, the driver is notified a landmark exists; a second nudge fires at 50m. The driver can view photo + note while riding and search on.
2. Validated negative case: Driver marks “Belum Sesuai”; a light, non-blocking alert lets them update the landmark during package check.
3. Validated positive case: Driver marks “Sudah Sesuai”; the system notes this helps the next driver, and the task completes with no interruption.
4. Mismatch / missing landmark: During the package photo (Task 2), the driver can turn that photo into a landmark with a short note labeled “Dari Driver” improving accuracy for everyone.

Scenario 2 Silent Handover:

1. Driver meets customer: Confirms “Sudah Bertemu” → package check → photo → done.
2. Doesn’t meet, note available: System surfaces “Ada Catatan Penerima” → driver follows the note through the photo step → confirms handover location → done.
3. Doesn’t meet, customer silent: Warning + a 10-minute max wait with a “Waktu Tunggu” countdown; a semi-automated CS report is available at any time.
4. Cancelled by CS → return to hub: If CS also can’t reach the customer, the order is cancelled per SOP; driver returns to hub for return/refund.
5. Permission granted via CS: If the customer grants permission through CS, the driver is notified and completes the drop.

Summary of the work:

1. Problem: at arrival & handover, drivers often can’t pinpoint the exact spot (inaccurate pin) and customers are often unreachable (WA now banned).
2. Validation: confirmed across three sources driver interviews, customer reviews, self-experiment not assumption.
3. Key decision: rejected the in-app map (too heavy, doesn’t fit field reality) in favor of crowdsourced landmarks that get more accurate the more they’re used.
4. Solution: an adaptive banner on the same screen it appears when there’s extra context (landmark / drop instruction) and stays out of the way when there isn’t.
5. Design principle: reuse what already exists (200m notification, Foto Paket, Bantuan CS) instead of adding new features.

What I learned:

1. Reframing needs a sparring partner. Discussion caught things I’d miss solo a driver name mismatch, a sub-flow promised in the narrative but never given a UI. I used AI as a sounding board, but decisions and data ownership stayed with me.
2. Terminology consistency matters. UX terms like gating, cold-start, and escalation need clear, consistent Indonesian equivalents if the designer is unsure, stakeholders will be more so.
3. Microcopy isn’t finished. The flow structure holds, but tone and wording aren’t yet tuned to real driver conditions (rushing, motorbike, glare, rain). That needs a dedicated pass before final.
4. Validation is still retrospective. Everything so far is interviews, reviews, and self-experiment no prospective testing with real drivers in the field, and key assumptions (like the repeat-address ratio behind cold-start) still need actual Astro data.

Honest limits (stated plainly):

1. Cold-start: no landmark yet = no banner; the driver falls back to old coping. Accepted for MVP it strengthens as data grows, on the assumption that repeat addresses dominate.
2. Google Maps seam: navigation stays a separate app; the landmark stays re-openable after return. Street View helps only where it exists (kampung/gangs often have none).
3. SLA timer: it keeps running in the silent-handover branch (a business rule, not pausable). Design can add a “waiting for customer” status label, but it can’t stop the clock resolving SLA pressure caused by the customer needs a policy decision outside the arrival UI.