The surprising amount of product thinking behind 'Delivering in 10 minutes'

A surprising amount of thought goes into showing: ‘Delivering in 10 minutes’ on your quick-commerce app.

Orange Health Labs collects your blood sample in minutes now.

More importantly, unlike food delivery apps, we actually reach you in 15 minutes. Our on-time arrival continues to be at 99%+.

I had the fortune of being a part of the team that made this happen. My role was to define the customer-facing experience for booking an ‘Instant’ sample collection.

Here’s what it looks like, on the app:

You’ve probably seen this widget so many times and never thought about it beyond a second.

Today, let’s do that.

This post is about the surprising amount of Product, Engineering and Design thinking that goes into making this simple widget work. And there is quite a lot of it.

WHAT to show: the ETA

At first glance, you’d think.. What’s the big deal about it?

All you have to do is -> As soon as the user lands, show them the ETA for a collection.

But that’s not enough, is it?

No.

Because to show the ETA for the user’s location, first, you must ask for the user’s location.

On web -> This is a pop-up native to the browser

On app -> This is a pop-up native to the OS

Now, depending on the response, you have two scenarios:

Either the location is granted

Or

The location is not granted

If the location is not granted, you have to choose what to show there.

Do you market the “quick” aspect of your commerce and try to nudge the user for a delivery?

Or do you stay put, and just show a default, non-location-related state?

If the location is granted though, then..

Well then you have two more states

Either the location is serviceable

Or

The location is unserviceable

If the location is unserviceable, you have to show an unserviceable state, and decide whether the user is blocked until they change their location, or the user sees a big red indicator, but continues to browse your catalog for now.

If the location is serviceable though, then..

Well then you have two more states again!

Either the location currently has “quick” serviceability,

or

It doesn’t

If the location doesn’t have “quick” serviceability, you must now show an explanation - maybe it’s raining, maybe it’s night time, maybe you’re shut down due to a protest..

If the location does have quick serviceability, then..

You guessed it.. You have two states

Don’t worry, these will be the last ones.

Right?

If the serviceability ETA is a nice-sounding one, say 15 minutes, then you may show that 15 minutes.

But if it’s something horrible, like say 73 minutes, then is it even quick anymore? Maybe just say something like 60+ minutes? Or maybe just say ‘Delivery in minutes..’ with fading text to give that sense of speed, even if it’s not there.

PS: I don’t have a screenshot for this.

So, is that it then? That’s all there is to it?

No. ETA is just one of the information points this widget gives. The second is location.

WHAT to show: the location

Okay, so now we have to explain that too.

First, let’s understand what we mean by location.

We show a title. Ex: Home, Office, Koramangala, Bangalore, etc.

We show a description. Ex: 1st cross, 27th Main.. and so on..

Thankfully, the case-tree of location isn’t so bad.

It starts again, at the location permission.

The moment you have a user’s location permission, you have..

.

.

.

You guessed it.. Two cases

Either the location is nearby an existing saved location on the user’s account

Or

It’s a new location

The word nearby here is a personal judgement of the developer.

If the user is nearby, you can default to the saved location and show that.

Since it’s a saved location, you will get a title too.

If the user is not near any saved locations, it’s a new location and you must show that there.

However, now you have to identify the title to show and also show a bit of the description.

The title has to be something which shows the user the general area they are in.

For example: Koramangala, Moti Mahal

Or even something specific

Like: Raj Bhavan, Iron Pillar

Thankfully, Google already sends you a GPS coordinate’s location back in a format that makes it easy to pick the title text.

And so, depending on where you land on the intersection of the ETA tree and the location tree, that’s what your output will be.

And that’s the end of the story.

Or is it?

Because so far, we’ve only covered WHAT to show.

We never spoke about HOW to show it.

HOW to show it

Now you might think..

WHAT DO YOU MEAN BY HOW, AAKRIT?

It’s a time and a location. Just put that up there, huh?

What’s the big catch?

Ahh.. if only you were correct.

If only..

First, you don’t know if the user will even notice the location widget. It’s so commonly present in apps now that most users just ignore it.

Why is that a bad thing?

Because on the off chance that the location detected is wrong (maybe the user’s location wasn’t detected properly, maybe they opened the app at work but came back and opened at home), then the order gets placed at a location that’s wrong.

I don’t know how often you’ve placed an order for the wrong location on Swiggy. But I have. I’m ashamed to admit it, but I’ve done this more than once. More than a few times, actually.

In such moments, you never blame anyone but yourself, for not being careful.

But you’re wrong.

It’s the PM’s fault. The design is supposed to be seamless, but not so seamless that you make an error and it doesn’t ever nudge you.

That’s why we have splash screens.

Splash screens?

Yeah, those animations that come up when you open an app.

Between the time that you click on an app’s icon on your phone and the time when the home screen is in front of you, you’ll notice a small animation.

That’s the splash screen.

That’s where you put the location, so the user knows what location they’re browsing for.

It’s such a simple but ingenious idea. Your attention really is at the peak there. And the location is also such an inherently easy-to-internalize piece of information that showing it there just sets context for the user, without putting the user through any cognitive load at all.

I bet before I pointed this out just now, you never did really even realize that the splash screen was doing something at all.

Go ahead, open your Swiggy app right now. And you’ll realize how much heavy lifting that screen does.

But this was just the first of the cases you need to handle when you think of HOW to show the widget.

The next googly is in transitions.

Imagine a user that lands on the homepage, with a 10-minute serviceability location. Then goes on to change their location to a different one, where the serviceability is different.

How do you communicate this change to the user?

If the new serviceability is poorer. Say 75+ minutes. Then how do you communicate this, without losing the customer’s interest in the purchase?

The answer is to show an animation..

If the user is transitioning between states, show an animation marketing the ‘quick’ collection / delivery every time the user lands in a quick delivery state.

And whenever a user moves out of it, just show the location and no TAT at all.

And finally, you must handle the question: how old is the ETA?

Your delivery riders are constantly on the move.

So the same potato that was 15 minutes away for a customer is now 20 minutes away..

How do you keep delivering this latest ETA? How often? Where? And how do you do it without losing the customer’s interest?

The general rule is to poll the ETA on every page reload and have the ETA updated on the website, depending on the right case.

And then, finally, you can consider that your work is quite done.

That you’ve launched a new quick-commerce widget.

Congrats.

Except no, that’s when the really hard problem starts.

Keeping the promise

You’ve promised the ETA to the user. Now actually deliver on that promise.

In a city like Bangalore, it’s hard to reach on time. Not just once in a while. 99% of the time.

I don’t know how to make that happen. Thankfully, Orange Health has smarter folks than me on this.

Hemanth Ramineni solved this for us.

Reach out to him for an explanation of that. He has some really amazing schematics, charts and a crazy scheduling algorithm that he’s hoarding.

PS: Even within my scope, that is, within the purchase flow of an Instant collection order, a lot more happens. There’s the slot screen, where you balance between fixed slots (2pm, 2:30pm, etc.) vs the ‘Instant’ ETA of 15 minutes. There’s also the hurdle of tracking this whole thing. What was offered, what was selected, what was delivered.

But all of that is for some other day.

PPS: I’m eternally grateful to the PMs at Swiggy, Zepto, Blinkit and Zomato who worked out these cases and paved the way with pre-made solutions.