Helping users modify cab bookings without starting over

At MakeMyTrip, I redesigned the post-booking cab modification flow to make modifying a cab booking simpler, clearer, and more transparent, resulting in fewer drop-offs and an increase in the conversion rate.

ROLE

Designer

TIMELINE

March-May 2026

TEAM

Julian

Nony

Saaniya

SKILLS

Interaction Design,

Usability Testing,

Cross-functional Collaboration

INTRODUCTION

The post-booking cab modification experience

MakeMyTrip is one of India’s leading online travel platforms, helping users plan holidays and book flights, hotels, buses, trains, and cabs. As a Product Design Intern, I worked on the post-booking cab modification flow, where users needed to change their pickup time or location after confirming a cab. The existing experience made users repeat parts of the booking journey, reselect cab options, and review changes without clearly understanding what had changed or why the final price had changed. My goal was to make the cab modification experience faster, clearer, and easier to complete.

THE PROBLEM

Modifying a booking is meant to save time, but when it ends up being as long and more confusing than booking a new cab, it defeats the purpose

Say your flight gets delayed and you want to push your pickup time, or your plans change and you need to update the pickup location. Naturally, you’d want to quickly modify your existing booking and move on. But on MakeMyTrip, the current modification flow doesn’t quite meet that expectation.


Small changes, like adjusting the time or location, can trigger a chain of backend updates: pricing changes, different cab types, or even a new provider. The user ends up having to go through so much information, it feels like they’re booking a cab all over again.

VS

Modifying a booking follows the same steps as making a new one

Why it matters

Since modifying a booking feels as time-taking as starting over, many users end up cancelling and rebooking instead. This pattern shows up in our data through a high number of cancellations followed by new bookings, as well as significant drop-off rates in the modification flow.

RESEARCH

Users drop off when trying to make simple changes to their booking

70% of users dropped off between the edit and review steps

10 usersstart modifyingStart7 drop offmidwayDrop-off3 completemodification4 cancelbooking3 abandonentirely3 rebooknew booking

*Data adjusted to comply with company policies

Many users canceled their cab bookings close to travel time, even if it meant paying a cancellation fee. A large chunk of them would then immediately rebook a new cab.

Most users modified their booking in order to change the pickup time or the pickup location

⏱️

58% of modifications, only pickup time was modified

📍

33% of modifications, only pickup location was modified

Conducting usability testing

I conducted usability testing with users to understand this was happening. The goal was to observe how they navigated the modification process and to see where confusion or hesitation occurred. A few key issues emerged consistently:

Redundant steps

"Why do I need to select a cab model again if I simply want to change the pickup time?"

Confusing pricing

"Weird, the price for the listed cabs is higher for some reason. And what 'extra payable' mean?"

Lack of confirmation

"Not sure if the pickup time has been modified. Where do I see the new time before paying?"

Unexpected charges

"I need to pay to modify my booking even though there is no modification charge? I already paid a small amount to confirm my original booking."

IDEATION

There's a catch. Even simple edits trigger complex changes in a multi-vendor system

Uber · BluSmart · QuickRideUser updates pickup time,pickup or drop locationPrice updatesif applicableUser confirms, pays if neededmodification donevsMakeMyTripUser updates pickup time,pickup or drop locationAggregator checks supplyacross multiple providersMultiple updates possiblecab · fare · policy · supplierUser confirms, pays if neededmodification done

MakeMyTrip works as a cab aggregator, unlike competitors like Uber, BluSmart or Quickride which control their own supply, This makes even simple modifications more complex.


Changing a pickup time or location triggers a backend check across providers. In the best case, the same cab is still available and only the price adjusts. But if it isn't, the car type, fuel type, supplier, or trip policy may all change at once — sometimes all together.


On top of this, MMT lets users pay partially or fully at booking, so any fare change from a modification needs to be communicated clearly to avoid confusion at payment.


The goal despite all this: keep the user-facing experience fast, simple, and transparent.

Hypothesis : Users don’t want to re-evaluate their cab choice during modification

Since most modifications involve changes to pickup time or location, asking users to re-select a cab adds unnecessary complexity.

🕐

58%

of modifications are pickup time changes only

📍

33%

of modifications are pickup location changes only

🚗

<5%

modify just to change their cab model

Asking users to re-select a cab during modification ignores a decision they’ve already made—considering boot space, number of passengers, comfort, and selecting a cab accordingly. Since users spend time selecting a cab that fits their needs during booking, they are unlikely to want to re-evaluate all options during modification.

Thus, the modification flow should prioritize speed by offering the closest possible match to the original cab, while clearly highlighting any changes.

Restructuring the flow

Based on this, the flow was redesigned to reduce unnecessary steps and support quick modifications. The flow removes the need to re-select a cab during modification.


After users update their pickup details, the system shows the same cab or the closest possible match based on the original selection. Any changes—such as price, fuel type, or policies—are clearly highlighted before confirmation. Pricing is adjusted based on the user’s original payment method, ensuring transparency in the final amount payable.

Current flow

StartEdit booking detailsPickup, drop · date · timeSelect a cabBrowse available optionsReview bookingUpdated details, policies & fareHas the pricechanged?NoYesIncrease in priceextra amount dueDecrease in pricerefund issuedHow would youlike to pay?Part payFull payPart pay% now, rest to driverFull paynew fare − already paide.g.+₹100 → pay ₹20 more(20% of increase)e.g.₹500 − ₹200 = ₹300due nowBooking modifiedConfirmation sent to userEnd

Redesigned flow

StartChange pickup timeor pickup / drop locationReview pagesame cab / closest match topreviously selected cabSatisfied withshown cab option?NoYesBrowse othercab optionsSelect preferredcab optionReview change incab type and policies (if any)Has the pricechanged?NoYesIncrease in priceextra amount dueDecrease in pricerefund issuedPay extraDifferencerefunded tosource accountModification confirmedConfirmation sent to userEnd

CURRENT

Re-enter booking details

Browse all cabs

Select a cab

Review

Pay if applicable and confirm

REDESIGNED

Edit what needs to change

Closest cab match shown

Browse alternatives only if needed

Review

Pay if applicable and confirm

Users get to confirmation in fewer steps

TESTING

Users need clear, upfront breakdowns to understand price changes

Expandable card: Users wanted the full price breakdown visible upfront, rather than having to tap to expand it

Copy preferences: Users preferred "new price" and "old price" over "price before/after change". "Outstanding amount" was clearer than "total".

Modification charge: Users preferred the modification fee (when applicable) shown as a separate line item rather than nested within the total price after change.

Colour coding: Yellow on the price increase, combined with the other colours on the card, made it feel overwhelming.

Redundancy: "Price difference" appeared twice with the same value, once in the header and once in the breakdown row.

Users just want to see which policies have changed, not compare everything

Original: There was no clear way to identify which policies had changed. Users had to read through everything to figure out what was different.

Variant 1: Showing before and after values inline for each policy made the review page overwhelming to look at. Users didn’t want a full comparison between old and new policies, they just wanted to know what had changed.

Variant 2: Changed policies were prioritised, with unchanged ones collapsed under “Show more,” allowing users to quickly identify what had changed without scanning the full list.


SOLUTION

Edit what you need to for your booking quickly

Users can update only what they need without having to re-enter other details

The review page at a glance

Changes in cab details are clearly called out

Users can quickly identify what changed, with details like cab model or fuel type called out directly

Policies card highlights what changed, making it easy to scan without overwhelming users

Changed policies are shown upfront, while unchanged ones are collapsed, making it easy to identify updates

Clear and upfront price breakdown

The full price breakdown is shown upfront, with simplified copy and charges clearly called out

Browse other cab options if the suggested match doesn’t fit your needs

The closest available match is shown first to keep modifications quick, while still giving users the flexibility to explore other cab options if needed

IMPACT

The redesigned flow made cab modifications faster, clearer, and less repetitive

Reduced drop-offs

By removing unnecessary setps, more users completed modifications instead of abandoning the process

Fewer cancel-and-rebook cases

More users completed pickup time or location changes within the same booking instead of cancelling and booking again

Higher confidence before confirmation

Users could see price, policy, and cab detail changes before confirming the modification, reducing drop-offs at the review page

REFLECTION

⚖️

Balancing transparency with simplicity

I learned that transparency does not mean showing every detail with equal weight. The challenge was to make price, policy, and cab detail changes visible upfront, while structuring the information so users could scan it without feeling overwhelmed.

🤝

Collaborating across product and data teams

Working with product and data teams helped me connect user pain points with actual booking behavior, supply constraints, and business goals. This made the redesign more grounded than relying only on interface-level observations.

🎯

Designing around the primary user intent

I learned to use data to separate the main user intent from edge cases. Since most users were modifying pickup time or location, the core flow could stay quick, while more complex actions like changing the cab model remained available as a secondary path.