It just feels like yesterday when I first stepped into the Swiggy world as an intern. This was in 2019 when I was just a kid in college excited to meet new people and design cool stuff. Time flies quickly and now we’re here in 2021. I recently completed 10 months as a product designer here, and this got me reflecting on some amazing projects I could be a part of.

Designing a tipping experience being one of them. This little project is special in a way being my first ever project as a professional designer after college.

So without further ado, let’s get started!

With just a few taps on your smartphone, you can get all your favorite meals delivered to your doorstep. While this feels like a magical experience, most of us don’t know how a fleet of hunger saviors brave the forces of traffic, heat, and weather to deliver every order on time!

Tipping is one way for the consumers to thank the delivery partners for their hard work. When it was first introduced on Swiggy, as a user you would be asked to add a tip right before placing the order. It made sense logically since all the order modifications used to happen during the checkout.

So what was the problem?

When my manager Saptarshi Prakash asked me to take the baton on this project, I was wondering the same thing.

Let me take you a little back in time, around the summers of 2020.

It was the peak of covid-19 in India. People were very concerned about what they touched and ate. While many of us could work from our homes, our delivery partners were still out there, risking their lives to earn a living and provide convenience to those trapped in their homes.

After the official lockdown lifted, we observed something shocking — a steep decline in the percentage of tipped orders! As a result, the delivery partners’ income from tipping was significantly reduced.

We wanted to know what was going wrong. And how could we help our delivery partners in those uncertain times?

Understanding tipping behavior

We asked users about their tipping preferences. What motivated them to tip and what was stopping them from doing the same.

Frequent tippers usually had a high awareness of the effort put in by delivery partners and did so naturally out of empathy.

Those who rarely tipped didn’t feel the need to add an additional tip when they’re already paying a delivery fee. Although a considerable chunk of these users preferred tipping through cash instead.

Those who used to tip but stopped tipping mainly due to reduced empathy towards the blue-collar workforce with the removal of lockdown. This was the main reason for a decline in tipped orders in the past few months.

Designing the Experience

For our post-order hypothesis, the metric for order satisfaction was the delivery ratings. So we thought why not integrate tipping in the existing rating flow.

I started with a multistep approach — first complete the delivery feedback and then proceed to tip. Something like this:

This approach sets the expectation in the first step there’s something more to come. But what happens if a user isn’t satisfied with the delivery? What do we show if the rating is just one or two stars?

Okay, how about a bottom-sheet? It’s always a safe approach to perform secondary interactions on the screen. And we could show the tipping widget only for highly rated deliveries.

This looked like it would work. But not yet!

I started showing around the prototypes to the folks at Swiggy — who not only work here but most are avid Swiggy users themselves. I realized that people generally focus on the task at hand (in this case rating the order), and having a tipping detour made the journey complicated.

There is just too much going on with the ratings! — was the opinion

Okay, what are we trying to solve here? I thought. Our goal is to cater to the motivations of satisfied consumers. So why not allow them to decide how happy they are (by rating above 3 stars) and then nudge them to tip.

Alright, this looked good 🙌

There was one problem though. This required the engineering team to build the slide-to-pay module from scratch. This was easily a two-week effort. As a designer, I was a little stubborn about delivering the best possible UX, but we couldn’t afford to delay the project so much. Why? because…

Product development is a continuous process. Shipping fast meant validating our assumptions early, learning more about the users and getting better the next time. 🚀

Finally, we went ahead with the longer payment route — the one that already existed for order payments during checkout.

There was one thing left though, what to do about pre-order tipping? The cart is already in a very complex state… should we remove it? Since empathy isn’t the driving factor for pre-order tips, can we do something better?

We thought of a couple of ideas here —showing messages in the context of special cases of rain, surge, long-distance. And personal stories about the lives of our hardworking partners.

Did everything work out as we thought? Not really. There was one problem we observed in the post-order funnel. A significant chunk of users who selected an amount dropped before completing the payment.

Why was this happening? Maybe people hesitated to pay another amount just after getting their meal — perhaps we need a way to tip previous orders whenever someone wants to. Or maybe the long payment tradeoff didn’t work for relatively smaller amounts — the effort required was too much leading to users abandoning the tipping flow. 🤔

We’ll get on jamming these problems and probably come up with something better in future releases. Nevertheless, before concluding, I just wanna mention the best takeaway from this one:

When working in design teams, there are people who worked before you, and there will be people after you. At your current stage, how can you best be involved and active in making change for things you believe in.

Design is like a relay race!