Nov 2025 - Mar 2026
Creating a Driver-Led Order
Ecosystem to Boost Acceptance
Order acceptance rate
8%
Adoption of filters
3.4x
27%
Average idle minutes
Rapido Captain is the earner-side app used by our driver fleet to go on duty, receive orders, navigate, and communicate with riders. It is not a companion app — for most drivers it is the job. Every screen sits directly between a driver's time and their daily income, which means design decisions here are compensation decisions.
The Auto category is the highest-volume, lowest-margin part of the marketplace. Drivers are predominantly low-digital-literacy, cost-sensitive, and frequently multi-apping across Rapido, Uber, and Ola. That combination sets the constraint that shaped this entire project: anything we ship has to be legible in under two seconds and must not give a driver a reason to open a competitor's app.
What was I solving and what was my role?
📉 The signal: drivers were online but not earning
Two numbers from marketplace data told the story:
15 mins
Avgerage
Idle time per session
18%
Post login
Order acceptance rate
Drivers were paying the full cost of being on duty — fuel, wear, attention, opportunity — and converting almost none of it. This wasn't a supply problem or a demand problem. Supply was present and demand was present; the matching layer between them was failing.
I chose to frame it that way deliberately. "Low acceptance" reads as a driver-compliance problem and invites incentive-led solutions. "Broken matching" reads as a product problem and puts it in our scope. That reframe is what made this a design-led project rather than a growth-led one.
💸 Why it mattered: one imbalance, three costs
Earnings lost
Drivers spent a real chunk of their online time idle or rejecting orders that didn't fit, which slowly eroded their trust in the platform as a dependable income source.
Lower fulfillment
Every rejection meant a reassignment, a longer rider wait, and a less efficient marketplace overall.
Driver retention
When drivers feel out of control, they disengage — go offline earlier, or multi-app to Uber and Ola. Long-term supply stability takes the hit.
I used this three-cost frame in every leadership conversation on the project. It let me argue for a structural fix rather than a tactical one, because it showed a single root cause producing costs in three different teams' metrics.
🧭 Navigating the ambiguity
I inherited the problem with no clear cause and three competing explanations:
1. The root cause wasn't obvious. Acceptance data told us drivers said no. It could not tell us why.
2. System vs. driver tension. The allocation engine optimised for global marketplace efficiency. Drivers optimised for their own shift economics. Nobody had confirmed those two objectives were actually in conflict — or that they had to be.
Low digital literacy. Any solution requiring configuration, reading, or learning risked being adopted by exactly the wrong tail of the fleet — the already-savvy drivers who needed it least.
The question I anchored the team on: why were drivers saying no? Not how do we make them say yes — that framing presumes the answer and leads straight to incentives.
Everything pointed to one question
Why were drivers saying no?
🎯 What I owned
I led the design strategy as a lead designer:
Strategy
Reframed the problem from a compliance issue to a marketplace-matching issue. Authored the product strategy and the phased rollout plan that engineering and business signed off on.
Research planning
Designed and ran a six-day mixed-methods study — in-office interviews followed by field visits — with ~18 auto drivers across Bangalore and Chennai.
Cross-functional leadership
Held alignment with Product, Engineering, and Business through active pushback on cost, marketplace risk, and confidence level. Negotiated scope into two phases so that disagreement became a sequencing question rather than a go/no-go one.
Mentorship and decision-making
Directed the designer on execution — order card system, filter setup flow, service manager — while holding the risk and trade-off calls myself. My rule for the project: I own the decisions that are hard to reverse; they own the decisions that are easy to iterate.
What I owned vs. what I delegated. I held the decisions that were hard to reverse — the single-stream architecture over tabs, the contained Services pill, and the scope and sequencing of the phased rollout. Execution of the order-card variants, the filter setup flow, and the Service Manager screens sat with a designer on my team, built against specs I wrote.
Setting out to solve
🚶 What we learned on the ground
Six days, ~18 auto drivers, Bangalore and Chennai. In-office sessions to understand mental models and comprehension, then field visits to observe actual behaviour on duty.
The core behavioural loop we found:
Go online → random orders arrive → react
Drivers had no plan because the product offered no way to have one. Rejection was not laziness or gaming — it was the only control mechanism available to them. Declining an order was how a driver expressed a preference the system had never asked about.
A comprehension exercise made the literacy constraint concrete: when asked to write down what they saw on the order screen, drivers reliably retrieved fare and pickup distance and reliably missed everything else. Any new signal we introduced had to be iconic and pre-linguistic, not textual.
6 Days
Research
"I didn't even know Go To Area existed. If I had, I'd use it every night when I want to head home."
Full-time auto driver
6 yrs on the platform
18
Drivers
"This app is my monthly income. I only take trips above ₹200 — I want to earn more per ride, not just more rides."
Full-time auto driver
3 yrs on the platform
"I drive part-time. I want short orders, and I want to stay near my area."
Part-time driver
1 yr on the platform
💡 The insight that reframed the project
Drivers were not rejecting orders randomly — they were optimising for predictability, control, and earnings efficiency.
This is the sentence the whole project turns on. It relocates the problem from driver behaviour to product design, and it makes the solution direction almost self-evident.
🧪 Hypothesis
If drivers are given control over the types of orders they receive, acceptance will rise — because the orders will finally match their intent
I wrote it as a falsifiable statement with a named mechanism, not an aspiration. It gave the team a clear disconfirming condition: if drivers set preferences and acceptance stayed flat, the insight was wrong and we should stop. Making the kill condition explicit up front is what made the phased pitch credible later.
🎯 The condition that would have proven this wrong
If drivers set their preferences and acceptance still didn't move, it would have meant the reframe itself was wrong — that rejection wasn't about intent-mismatch at all, and the real driver was something upstream: pricing, trust in the platform, or the matching algorithm itself. That result would have sent us back to research, not back to the drawing board on this design.
The solution
🛠️ Product thinking & ideation
Before committing to a direction, I simulated several marketplace scenarios to test how different preference models might affect supply–demand matching. This let me pressure-test the business risk cheaply — in a spreadsheet-and-simulation environment rather than in a live experiment — and walk into stakeholder conversations with an informed view on fragmentation rather than a defensive one.
Three models went into evaluation:
🤖 AI-assisted Prototype
A
Orders screen with preference filters
Highest signal-to-effort; preference expressed at the moment of relevance
B
Preferences captured during onboarding
Poor fit — asks for a decision before the driver has context, and is invisible thereafter
C
Preferences editable from the home screen
Discoverable but detached from the order-taking moment; repeats the Go To Area failure
A won on one criterion above the rest: it places the control where the decision happens. That is also precisely the diagnosis of why Go To Area failed, which made the argument internally consistent.
🗣️ Stakeholder pushback
Introducing driver-controlled preferences into a live marketplace was not an easy sell. Three real objections:
"Will this reduce overall fulfillment?" Will they take regular orders?
Product Lead
Driver Product Team
"Will supply become fragmented across preferences?"
Manager - Business
Business Team
"This is an expensive build. What's your confidence level?"
Engineering Lead
Engineering Team
I treated all three as legitimate. They were. A preference layer over a live allocation engine genuinely can fragment supply, and I did not have the data to prove it wouldn't.
🛡️ De-risking the build
Rather than defend a single big design, I reframed the work as a phased experiment — a way to learn cheaply before betting big. That reframe unlocked alignment, because it converted three objections into one shared question: does driver-expressed preference actually move acceptance?
Phase 1
Validate behavior
Designs to create:
Orders screen with filters
Filter setup flow
Resurface the Go To Area feature
Order card redesign
Bottom Navigation
Phase 2
Scale the system
Designs to create:
New services and features
Pickup-clarity improvements
Service manager
Order-card system at scale
Minimized bottom navigation
Phase 1 answered the Product Lead's fulfillment question with live data, capped the Engineering Lead's cost exposure, and gave the Business Manager a monitored, reversible rollout instead of a bet. The design work I cut from Phase 1 was not work I thought was unnecessary — it was work whose value depended on Phase 1 being right.
⭐ The core idea
One home surface for order-taking. Preferences expressed as filters at the top, in the same visual field as the orders themselves. A bottom navigation that makes the app's structure explicit instead of implied.
The strategic intent behind the structure: build a single mental model for drivers — reduce randomness, increase predictability. The filter is the visible feature; the mental model is the actual product.
⭐ Core idea
Introduce an Orders Home with
Preference Filters + Bottom Navigation
Designs & decisions: Phase 1
🎚️ A dedicated Orders Home with filters
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
Setting up filter
⚖️ Tabs vs. no tabs — a risk-based call
The obvious information architecture was tabs: one per order type. Cleaner, more scalable, and what most reviewers expected.
Tabs
V/S
No Tabs
🪃 Why I proposed "no tabs"?
I proposed no tabs. A tabbed experience teaches drivers that each order type is a separate inventory they can inspect and dismiss. The likely consequence: a driver checks their preferred tab, sees it empty, and goes to Uber or Ola for the rest. Good IA that increases multi-apping is bad product.
This was the decision I was least able to prove and most willing to own. I framed it explicitly as a retention risk rather than a usability preference, which moved the conversation from taste to consequence and got the team behind it.
Cognitive switching
Two tabs mean two lists to track and a constant toggle between them.
Multi-apping
A half-empty "Preferred" tab leaves drivers waiting — and a waiting driver opens Uber or Ola.
No interaction
In one stream, preferred orders rise to the top on their own — no tab to open, no switch to remember.
📜 The trade off: The principle it produced
Orders First — always show orders,
and stack the preferred order on top
Never an empty surface. Preference changes ranking, never availability. This became a durable design principle for the Captain app beyond this project, and it is the artefact from this work I am most pleased with — it outlives the specific screens and gives future decisions a default.
Preferred order stacked on top always
Identification icon
A thematic card and icon to identify the preferred order that was set by the driver
🧪 Experiment roll out
We took the design live in two cities — Bangalore and Hyderabad — across different Auto clusters before scaling to other metros and Tier-2 cities. Go To Area adoption climbed and idle time dropped.
41%
Filter adoption
-4 mins
Idle time per shift
8%
Order acceptance
Phase 1 was scoped to be cheaply reversible on purpose. If filter adoption had stayed near Go To Area's 12%, or if acceptance hadn't moved, the plan was to roll the filters back in the two pilot cities, keep the research, and re-test the onboarding-led model (Concept B) instead — not to push forward into Phase 2 and hope it fixed itself.
Designs & decisions: Phase 2
➕ Adding new services and features
The model extended naturally across categories — Bike Taxi, Auto, Cabs — and into new earning levers:
Services
Auto Boost
Auto Line
Meter Auto
Features
Short Orders
Long Orders
Stay in Area
⚙️ A service manager inside the order filters
I proposed bringing service management into the order-taking surface. If services determine what orders you see, managing them belongs next to the orders — not in a distant settings area, which is the Go To Area mistake in a new costume.
Service Manager
New Service Nudge
🔀 A second ambiguity call: exposed services vs. contained
As Phase 2 services multiplied (Auto Boost, Auto Line, Meter Auto), the filter row faced a scaling problem. Two options:
Exposed services — every service as its own dismissible pill in the row. Immediately visible, but the row overflows, horizontal scroll hides options, and the visual hierarchy collapses as we add more.
Contained inside a pill — a single "Services" pill with a count badge, holding services behind it; core filters (Go To, Short Order, Long Order, Stay in Area) stay exposed.
Exposed services
V/S
Contained inside a pill
I chose contained. It protects the row's legibility as the service catalogue grows, keeps the primary filters at a stable location the driver can build muscle memory around, and gives us a clear place to introduce new services without redesigning the surface each time. The trade-off is one extra tap to reach a service — acceptable, because service selection is a lower-frequency act than order filtering.
To offset the discoverability cost: when a new service launches, the filter opens automatically without interaction, guiding drivers to something they would otherwise never find behind a pill. Contained by default, exposed at the moment it matters.
🔖 Birth of the new order cards — designing a system, not a screen
This is where I spent most of my mentoring time my designer on my team — Malatesh Aihole. He composed each new card by picking a variant and state instead of starting from a blank frame. The card variants and states shown above were built out by them from the base component and spec I defined. The new order card wasn't a screen we shipped; it was a kit the whole app could build on.
Impact
🚀 Impact & results
We took the design live in two cities — Bangalore and Hyderabad again — across different Auto clusters before scaling to other metros and Tier-2 cities. City-level phasing let us separate genuine behavioural signal from local demand quirks, and gave the business a reversible position at every step.
Metric
Before
After
Improvement
Order acceptance (post-login)
12.5 mins
7 mins
8%
Idle time per shift
23%
11%
−27% (−4 min)
Filter / Go To Area adoption
340/month
89/month
3.4x
The number that mattered most for the reframe was adoption. 12% → 41% on substantially the same underlying capability is the cleanest available evidence that the original idea was never the problem — the surface was. And critically, fulfillment did not fragment. The Product Lead's objection was answered by data rather than by argument, which is the outcome the phased approach was designed to produce.
🪞Reflection
What I'd do again. Reframing the pitch from a design to an experiment. It cost me scope in the short term and won me the mandate — and the second phase — in the long term. Disagreement about a decision is far easier to resolve when you can convert it into disagreement about sequencing.
What I'd do differently. I ran the field research myself for good reasons, but it left the team dependent on me to relay the driver's perspective in every subsequent decision. I would put at least one designer and one engineer in the field next time, so conviction is distributed rather than concentrated in the person presenting.
The open question. Preference expression works when demand is plentiful. Under thin supply-demand conditions, a driver's stated preference and the marketplace's need will genuinely diverge, and Orders First becomes a harder promise to keep. That is the next problem this system creates, and the honest cost of having solved this one.
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