TL;DR
We redesigned the Host Delivery experience to fix core adoption blockers and make the feature truly valuable for Hosts. Instead of patching legacy logic, we went back to first principles. The goal was to rethink delivery as a flexible, map-first setup with clear pricing, opt-out controls, and context-aware support.
This foundational redesign made Host Delivery usable and scalable. It directly contributed to increased adoption, improved Host sentiment and eventually their Retention.
[Key Highlights]
- Addressed foundational flaws in the legacy delivery model.
- Introduced a map-first experience with custom delivery radius and hotspot opt-ins.
- Empowered Hosts with flexible pricing, pause controls, and contextual education
- Adoption improved from ~40% to ~55%, positively impacting Host trust and retention.
[Final Output]
Here's a semi-interactive prototype (Expand for a better view)
And if you're here for the details, let me take you on a ride:
[Problem statement, Research & Status Quo]
It all started when we were trying to understand why some of our most promising Hosts (specifically D30 4.5+ rated ones) had opted out of Delivery or did not serve a booking even after opting in. We had our hypotheses, but we wanted to go beyond assumptions. So, we spoke to them.
One host told us:"I had an emergency and couldn’t deliver the car, but there was no way to reject just the delivery. I had to cancel the entire booking. That hurt my ratings, dropped my listing’s rank, and I barely got any bookings after that. I couldn’t even cover my EMI that month. So I just gave up and stopped listing my car altogether."
Conclusion: Hosts want to be able to opt out of delivery temporarily without cancelling bookings
Another said:"I had to drive nearly 20 kilometers to deliver the car, and again to pick it up. The delivery fee didn’t even come close to covering my fuel and time. I delisted the car as soon as that booking ended. It just didn’t make sense."
Conclusion: Hosts want to be able to set a comfortable delivery radius.
Delivery, while designed to improve guest convenience, was backfiring for our best Hosts. And the irony? Hosts earn 100% of the delivery fee paid by guests. There was clearly a design and structural mismatch that we had to fix.
Here's how the old screen looked:
I teamed up with Sukrit (PM), and we went deep. We discovered that the feature had been originally designed to treat Airports differently (now covered under "Hotspots") since some of them involved operational nuances like tolls and usually longer distances.
This separation made sense in the past, but we asked ourselves: What if other locations like railway stations or bus stops start seeing high traction in the future? Are we going to keep adding special-case categories? Clearly, the construct wasn’t scalable.
[Brainstorming & Ideation]
We went back to first principles. We asked ourselves, what does delivery actually mean to a Host?
- It’s a promise to bring the car to a convenient location for the guest (and pick it back up) in exchange for a fee.
- To be fair, Hosts need control. Control over where they’re willing to deliver and when they can’t.
We knew we had to redesign this entire experience from the ground up. The idea that clicked after a thorough brainstorming session was to go the map-first route and then follow it up with a chronological section-view with all the delivery settings and preferences.
We mapped out a user flow to make things clearer:
[Iterations & UI Exploration]
With the IA laid out, I got straight into structuring the page. Skimmed through Mobbin for inspiration and sketched some wireframes on the whiteboard.
[Solutions]
We wanted to let Hosts:
- Opt into delivery
- Set a radius they’re comfortable with
- See everything visually, because trust grows with clarity
This way, a Host could say: "I’m not okay delivering outside 5km, unless it’s to the airport."
Hosts could still choose to "Deliver anywhere in the city" if they wanted complete flexibility. That ensured backward compatibility and a smooth transition for existing Hosts.
We also redesigned the pricing structure. Inspired by cab fare models, we introduced a semi-variable fee with a base distance and a per-km charge beyond that. Hosts could pick from 3 preset rates, giving them pricing control without overwhelming them. Also, Hotspots had an additional incentive added to them to keep them more lucrative for hosts.
We carried forward a couple of legacy preference settings (with their own updates) that Hosts cared about:
- No night-time delivery (with adjustable time windows)
- Minimum booking duration required for delivery (e.g. only for 8+ hour bookings)
And because life happens, we added a Pause Delivery feature so Hosts could temporarily opt out of delivery without disabling their listing. This option was deliberately placed lower in the UI to subtly discourage overuse, not to hamper supply.
Visually, we built the screen with contextual info-boxes and examples to reduce friction. We also added an education tour for Hosts trying out the new experience for the first time.
[Tradeoff & Compromises]
Now, let’s talk about the tech constraints.
Hosts can list their car from multiple locations (home, office, etc.), and delivery preferences are tied to each location. So we had to introduce a "Choose Listing Location" step before letting Hosts configure delivery. Ideally, I would’ve loved a smarter setup where the delivery radius auto-adjusts based on the car’s real-time location, but that wasn’t possible within current tech limitations.
- Couldn't include distance indicators for hotspots (API cost concerns)
- The opt-in checkbox inside the hotspot detail overlays caused implementation delays, so we simplified the interaction
[What could have been better?]
If I had more time, I’d improve the syncing between the map and hotspot list, especially flagging when a hotspot lies outside the current radius (maybe with a little warning icon or label).
[Outcomes & Metrics]
- Delivery opt-in rose from ~40% to ~55%
- Host cancellations due to delivery issues reduced significantly
- Host NPS improved, especially among power users
All said and done, this project was a great learning for me. Working with Sukrit, Rohil (UI Engineer), and Ashish (Backend) made it even better.
It’s hard to describe the joy of fixing something that once frustrated your best users. This one definitely hit home :)
Thanks for reading till the end!
Interested in knowing more? Let’s connect over a short call!