Nov 2025 - Mar 2026
Designing a Marketplace
Intervention for Failed Ride Matching
How I helped transform a controversial business hypothesis
into a strategic marketplace experiment.
Role
Lead Product Designer
Timeline
6 Months
Executive Summary
Finding a ride during peak hours isn't always a supply problem. Often, it's a decision-making problem. Customers don't know how much more they're willing to pay, while captains don't know whether asking for a higher fare is worth the risk. The result is a marketplace where both sides hesitate, leading to failed matches despite having enough demand and supply.
To address this, the business proposed Reverse Bid—a feature that allowed captains to suggest the fare they were willing to accept after a customer requested a ride. It was an ambitious idea that challenged the traditional one-way pricing model.
While I had reservations about introducing another decision into an already time-sensitive journey, I believed the hypothesis deserved to be tested. Rather than debating whether Reverse Bid was the right solution, I focused on designing an experiment that could validate the business assumption and uncover how customers and captains would actually behave.
The experiment ultimately challenged many of our initial beliefs. More importantly, it shifted the conversation from building a feature to designing a smarter marketplace intervention.
My role
I led the UX strategy, product design, user research, experimentation, and stakeholder alignment, working closely with Product, Marketplace, Data Science, and Engineering teams from hypothesis to rollout.
Product Strategy
Reframed the problem
Created the product strategy
Designed phased rollout
Research
Field study
18 Drivers
6 Days
Experimentaion
Aligned Product
Engineering
Business
Stakeholder Alignment
Orders Home
Driver Preferences
Design System
The Marketplace Wasn't Broken
At first glance, the problem looked simple—customers couldn't get rides during peak hours. The obvious assumption was that we needed more captains on the road.
But when we analysed marketplace data, a different pattern emerged. Supply and demand already existed. The real issue was that both sides were making decisions with limited information.
Customers didn't know how much extra they needed to pay to get matched quickly, while captains couldn't tell whether a customer would actually accept a higher fare. As a result, customers retried across multiple apps, and captains waited for trips they considered more worthwhile.
The business believed Reverse Bid could bridge this gap by allowing captains to communicate the fare they were willing to accept. It was a compelling hypothesis, but I felt the bigger challenge wasn't pricing—it was whether people would naturally adopt this new behaviour inside an already time-sensitive booking flow. Instead of asking "How do we design Reverse Bid?",
I reframed the question:
How do we validate whether two-way pricing
actually improves the marketplace?
actually improves the marketplace?
That shift became the foundation of the project.
Key takeaway: We weren't solving a pricing problem. We were validating a behavioural hypothesis.
Sometimes Your Job Isn't to Be Right
When the idea of Reverse Bid was proposed, my first reaction was mixed. The business rationale was clear—if captains could communicate the fare they were willing to accept, we might recover ride requests that would otherwise expire. It sounded logical from a marketplace perspective.
However, I wasn't convinced that adding another decision into an already time-sensitive booking flow would automatically improve the experience. Customers were already trying to book a ride as quickly as possible, and asking them to negotiate on price introduced a completely new behaviour.
Instead of challenging the idea, I shifted the conversation. My role wasn't to prove whether Reverse Bid was right or wrong—it was to help the team reduce uncertainty. We aligned on treating Reverse Bid as a marketplace experiment, where success wasn't measured by shipping a feature, but by understanding how customers and captains behaved in a real-world environment.
That shift changed how I approached the project. Rather than optimizing screens, I focused on identifying the assumptions we needed to validate before investing further.
Key takeaway: My goal wasn't to defend an opinion. It was to help the team make a better product decision.
"Design should reduce uncertainty before it reduces friction."
Designing the Experiment
With the problem framed as an experiment, the next step was identifying what we actually needed to learn. Reverse Bid wasn't testing a single feature—it was testing multiple marketplace assumptions at once.
We worked backwards from the business hypothesis and broke it into a few critical questions. Would customers be willing to pay more for a faster ride? Would captains actively participate if given pricing control? And most importantly, would two-way pricing lead to more successful matches?
These questions shaped both the experience and the metrics we tracked. Every interaction in the journey was designed to validate a behavioural assumption, not simply complete a booking flow. Rather than launching widely, we rolled out the experiment in controlled phases so we could observe real behaviour, iterate quickly, and minimise marketplace risk.
Key takeaway: We weren't measuring feature adoption—we were measuring whether the marketplace behaved differently.
The Experiment Changed the Question
The experiment answered our original questions—but it also uncovered a more important one.
Our initial assumption was that giving captains pricing control would naturally lead to better ride fulfilment. If both sides could negotiate, the marketplace should become more efficient.
Instead, the data told a different story.
Captains were willing to place bids, but customers rarely accepted them. Even when fares were reasonable, many customers chose to retry the booking flow instead of negotiating. On the other side, captains quickly learned that placing bids didn't always lead to confirmed rides, reducing their motivation to participate over time.
The issue wasn't the bidding experience itself. It was the behaviour the feature introduced. Both customers and captains were making rational decisions, but those decisions weren't aligned with each other.
At that moment, Reverse Bid stopped being a pricing problem. It became a trust and decision-making problem.
Key takeaway: We didn't fail to design a better feature. We uncovered a deeper marketplace behaviour.
Looking Beyond the Feature
Instead of asking "How do we improve Reverse Bid?", we stepped back and asked a broader question:
When does negotiation actually
help the marketplace?
help the marketplace?
That shift completely changed our approach.
The data showed that Reverse Bid wasn't equally valuable across every ride request. It performed best in situations where customers had already experienced repeated dispatch failures and were actively looking for alternatives. In those moments, the willingness to negotiate was significantly higher because the cost of waiting had already increased.
This insight challenged one of our biggest assumptions. Reverse Bid didn't need to be a default booking experience. It worked better as a recovery mechanism, triggered only when the marketplace needed additional flexibility.
By narrowing its role, we reduced unnecessary friction for most users while preserving the feature for the situations where it delivered the greatest value.
Key takeaway: The right solution wasn't to improve bidding. It was to improve when bidding happened.
We Redesigned the Marketplace Logic
The biggest shift in V2 wasn't a new screen—it was a new marketplace strategy.
Instead of exposing Reverse Bid to every failed request, we redesigned it as a contextual recovery layer. The experience would only appear when the marketplace had enough signals to indicate that traditional dispatch was unlikely to succeed.
This reduced unnecessary decisions for the majority of customers while preserving flexibility for the minority of requests that genuinely needed it.
We also moved away from treating every customer and captain the same. Rather than designing a single experience for everyone, we started designing for specific marketplace conditions.
This transformed Reverse Bid from a feature that interrupted the booking journey into one that quietly supported it.
Key takeaway: Good marketplace design isn't about giving users more choices—it's about presenting the right choice at the right moment.
Four Strategic Shifts
The redesign wasn't driven by interface improvements. It came from four strategic decisions that aligned the experience more closely with marketplace behaviour.
1
From Default Flow → Recovery Flow
Instead of asking every customer to negotiate, Reverse Bid became a fallback mechanism after standard dispatch had already failed.
Result: Reduced friction for successful bookings while preserving flexibility for difficult ones.
2
From Everyone → The Right Cohort
Not every customer wanted to negotiate, and not every captain wanted to bid.
By triggering Reverse Bid only for scenarios where willingness was naturally higher, we improved the quality of participation on both sides of the marketplace.
3
From Feature Metrics → Marketplace Metrics
Success was no longer measured by the number of bids placed. Instead, we focused on metrics that reflected marketplace health:
Successful ride fulfilment
Customer acceptance rate
Captain participation
Time to match
Booking recovery rate
The feature became a means to improve the marketplace—not an end in itself.
4
From Transaction Design → Behaviour Design
Perhaps the biggest learning was recognising that marketplaces are driven by behaviour, not interfaces.
The challenge wasn't helping customers negotiate more easily. It was creating enough confidence for both sides to make a decision.
That subtle shift influenced every design decision that followed.
Key takeaway: We stopped designing a transaction and started designing trust.
"The most impactful design decision wasn't changing
the interface—it was changing the marketplace logic behind it."
the interface—it was changing the marketplace logic behind it."
Design
Reverse Bid didn't become the marketplace solution we initially imagined. But that didn't make the project unsuccessful.
It gave us something far more valuable: clarity.
Instead of scaling a feature based on assumptions, we uncovered the behavioural conditions required for it to succeed. Those learnings reshaped how we thought about fulfilment, pricing, and recovery experiences across the marketplace.
The project reinforced an important principle for our team: marketplace problems rarely have universal solutions. Success comes from understanding when and where an intervention creates value, rather than exposing it to every user.
In many ways, the biggest outcome wasn't the feature we designed—it was the confidence to make a better product decision.
Key takeaway: Sometimes the most valuable outcome of an experiment is knowing what not to scale.
A dedicated Orders Home
I introduced the bottom navigation so orders had their own mental space — separate from the home screen's noise. When nothing's coming in, the screen reads "Searching for orders…" instead of showing a blank empty state. A small detail, but it builds patience instead of anxiety.
Orders Home
New Order Card
Beyond the Feature
Reverse Bid didn't become the marketplace solution we initially imagined. But that didn't make the project unsuccessful.
It gave us something far more valuable: clarity.
Instead of scaling a feature based on assumptions, we uncovered the behavioural conditions required for it to succeed. Those learnings reshaped how we thought about fulfilment, pricing, and recovery experiences across the marketplace.
The project reinforced an important principle for our team: marketplace problems rarely have universal solutions. Success comes from understanding when and where an intervention creates value, rather than exposing it to every user.
In many ways, the biggest outcome wasn't the feature we designed—it was the confidence to make a better product decision.
Key takeaway: Sometimes the most valuable outcome of an experiment is knowing what not to scale.
Impact
Although Reverse Bid remained an experiment, it produced insights that influenced both product strategy and future marketplace thinking.
Product Impact
✓ Validated the behavioural assumptions behind two-way pricing.
✓ Identified the conditions where negotiated pricing was most effective.
✓ Prevented a broad rollout of a feature that introduced unnecessary friction.
Business Impact
✓ Reduced uncertainty before investing further engineering effort.
✓ Enabled product and marketplace teams to prioritise targeted interventions instead of universal solutions.
✓ Created a stronger evidence base for future fulfilment initiatives.
Design Impact
✓ Established experimentation as a design tool—not just a validation step.
✓ Strengthened collaboration between Design, Product, Marketplace, and Data Science through shared success metrics.
✓ Shifted conversations from "How do we improve this feature?" to "What behaviour are we trying to influence?"
Metric
Before
After
Improvement
Order acceptance (post-login)
12.5 mins
7 mins
8%
Idle time per shift
23%
11%
-27%
Filter / Go To Area adoption
340/month
89/month
3.4x
Reflection
This project changed how I think about designing for marketplaces.
Early in my career, I measured success by the quality of the interface. Over time, I've realised that many product challenges have little to do with the screen itself. The interface is often just the visible outcome of a much larger system involving incentives, timing, trust, and human behaviour.
Reverse Bid reinforced that lesson. Designing the experience was only part of the work. The more meaningful contribution came from framing the right questions, validating assumptions, and helping the team make evidence-based decisions.
Today, when approaching ambiguous problems, I spend less time asking "What should we build?" and more time asking:
"What do we need to learn before we build?"
Because the best product decisions aren't driven by confidence—they're driven by evidence.
"Great design doesn't always ship a feature. Sometimes it gives the team the confidence to choose a better direction."
View projects from Flipkart
Designing a video app
One of my first UX project where I majorly worked on the widgets and user interface
Reducing the bounce rate
An analysis of how I mitigated the bounce rate by creating a fully new user experience
Reducing the returns rate
A project that provided significant insights into user perceptions of refurbished items