Observed
The passenger sees a recommended fare.
It sits right under the price field. Whatever he offers, he offers it against an anchor.
Passenger app
anchor
- The passenger's anchor
Self-initiated, 2026
The passenger gets a price. The driver gets a guess.
Have you ever had an inDrive driver accept your ride, then message asking you to cancel? I used to assume I knew why. Then I started asking, and the answers didn't match. So I spent two weeks beside one new driver, on the app I'd only ever seen from the other side.
Not affiliated with or commissioned by inDrive.
The passenger
gets a price.
A recommended fare,
before he books.
The driver
gets a guess.
+5%, +10%, +15%.
No rate.
No distance.
Before you read: you're the driver. Three rides.
In-city ride requestJust now
Real ride from his two weeks
PKR 453
- Pickup
- 806 m
- Trip
- 7.9 km
12 s
You accepted
After fuelPKR 251
- Fare
- Fuel
- km driven
You priced 3 rides in 36 seconds without the one number that answers the question.
Your game
PKR 0
Losses you took 0
Rates you knew 0 of 3
Keep reading. You'll get a rematch later.
The study in numbers
- 1new driver
- 2weeks
- 3findings
- 11real screens
- 1stress test
I went in expecting a man confused by an interface. He wasn't confused. He had a method.
I wanted the moment before habit: what a new driver runs into before any of it feels normal.
One driver is thin evidence, so I set myself a rule. Every claim on this page carries a label that says exactly where it came from.
- Observed
- Seen with him, on his rides.
- As a passenger
- Seen in my own passenger app.
- Proposed
- My suggestion. Not yet tested.
- First idea thrown out
- A profit score for every ride, built from the mileage drivers enter at sign-up. A figure that's wrong twice poisons every figure after it.
Finding 01: The anchor
Observed
The passenger gets a reference price. The driver gets three unlabelled buttons.
anchor
Observed
The driver sees the passenger's figure, and three buttons.
+5%, +10% and +15%. None is labelled. None says what the trip is worth. He can't tell a fair offer from a lowball without rebuilding the calculation himself.
Driver app
figure+5%, +10% and +15%.
None is labelled.
- The passenger's figure
- +5%, +10% and +15%. None is labelled.
As a passenger
So he takes it first, and does the maths after.
Other drivers see the same offer, so every second spent deciding is a second he might lose it. Not carelessness. The safer move. Then he works it out, finds the answer is no, and asks the passenger to cancel. I saw this from the back seat, repeatedly. The drivers gave this as the reason.
Driver app
figure+5%, +10% and +15%.
None is labelled.
- The passenger's figure
- +5%, +10% and +15%. None is labelled.
Observed
Even the anchor that exists is blind to the car it needs.
Five passengers can't fit in a hatchback. It takes a bigger car: a seven-seater or a large SUV, with more fuel per kilometre and more wear. The same trip should cost more.
The app recommends PKR 19,350 for one passenger and for five. The driver's card says "5 passengers". The anchor price doesn't know.
Passenger app, 1 vs 5 passengers
Same fare for one passenger and for five: PKR 19,350
Observed
And the passenger chooses a car they can't see.
Offers show a model name and a year: "Suzuki Alto, 2023". Models change every year, and most passengers aren't car people. A student, a parent travelling with an older relative, someone heading out of the city with three suitcases: none of them can tell from a name whether they'll fit.
No photo, no seat count, no luggage space. They see the car only after they accept, or they leave the app to search for it.
Passenger app, choose a driver
no seat count
- No image, no seat count
Finding 02: The distance
Observed
City-to-city, he can see where. Not how far.
This finding is about city-to-city rides only. In-city, the app shows the trip distance clearly. That's what makes it a gap, not a limit of the product.
The real trip
~350 kmthe city-to-city trip to IslamabadWhat the app shows
1 kmthe drive to the pickupCity-to-city ride
No trip distance
- Two addresses, no distance
- The only distance
In-city ride
Distance shown
- Distance shown
no distanceThe only distanceDistance shown
Observed
Distance is step one of how he prices every ride.
Switch the tab and watch what happens to his maths without it. His numbers: petrol PKR 325 a litre, 14 km per litre in the city.
Switch the trip
- Distance ÷ mileage0.62 L8.7 km ÷ 14
- × Fuel pricePKR 2020.62 × 325
- Against farePKR 251453 − 202
- DecisionAccept?accept, counter, skip
In-city, he has the distance. He can do the maths, if he has time.
he checked
- Gone while he checked
Observed
So he leaves the app. And the offer is gone.
He finds the distance somewhere else, runs the numbers, and comes back to a full offer. It isn't a timer. It's a cap on how many drivers can bid.
He is competing on speed for information the app already has.
Finding 03: The answer
Observed
In-city, every number is on screen. Except the answer.
- To pickup806 m, 2 min
- Pickup, point AHarapa Rd (Chak 95/6 R)
- Passenger4.7 ★ (40 rides)
- Trip7.9 km, 16 min
- Drop-off, point BChak 82/6 R (Chak 82/6 R)
- FarePKR 453
Is this ride worth taking?
The screen solved the data problem. Not the judgment problem.
The pattern
Three findings. One pattern. No new data needed.
FindingWhat he can't seeWhat happens
01The anchorHe can't see what the trip is worth.He counters blind, or accepts and cancels later.
02The distanceOn the longest trips, he can't see how far.He leaves the app, and the offer caps out.
03The answerIn-city, every number but the answer.He guesses, or takes too long and loses it.
He doesn't need the platform's number. He needs one he can work out himself.
THE SOLUTION
The solutionProposed
Rate Check.
One line of type under the fare. It doesn't make the judgment for him. It clears the arithmetic out of the way, so judgment is what's left.
In-city ride request, the only change
PKR 453
PKR 52/km • your typical 45/km
PKR 52/kmWhat this ride pays per kilometre, including the drive to pickup.
your typical 45/kmHis own median from the last 7 days. Hidden below 20 rides.
new line
The fix, in the real screen
Proposed
Same screen. One new line.
Switch between today and the proposal. The new line is the whole fix.
PKR 52/km
What this ride pays per kilometre, including the drive to pickup.
your typical 45/km
What he usually earns: the median of his last 7 days. Hidden below 20 rides.
- The new line
Why this one
The maths is already done.
His four steps collapse into one comparison: one number against one number.
It's his benchmark, not ours.
It compares him to his own typical ride, so the app never claims a ride is good or bad.
Nothing new to build.
Both figures already exist in the product. Shipping it is one line of type.
Rematch. Same rides, now with Rate Check.
This time the card does the maths. You see what the ride pays per km next to his usual rate, so you know in a second if it's worth it. No calculator, no leaving the app, no guessing. The call is still yours.
In-city ride requestJust now
Real ride from his two weeks
PKR 453
PKR 52/km • your typical 45/km
- Pickup
- 806 m
- Trip
- 7.9 km
12 s
You accepted
After fuelPKR 251
- Fare
- Fuel
- km driven
First game
Play the first game to compare. Go to the first game
PKR 0
Losses you took 0
Rates you knew 0 of 3
With Rate Check
PKR 0
Losses you took 0
Rates you knew 3 of 3
The stress test
Then I tried to break my own idea. It broke.
A number on a driver's screen will be trusted, so it had to survive his real rides first. Six of them, at PKR 23.2 a km in fuel.
| Ride | Fare (PKR) | km driven | Rate per km | Fuel | Margin |
|---|---|---|---|---|---|
| Short pickup | 453 | 8.7 | 202 | 251 | |
| Long pickupDeadhead caught3.1 km unpaid to the pickup | 300 | 9.8 | 228 | 72 | |
| Very short hopFlatters short trips2 km, six minutes | 150 | 2.0 | 46 | 104 | |
| Long deadheadDeadhead caught | 300 | 9.0 | 209 | 91 | |
| Same km, better fare | 400 | 9.0 | 209 | 191 | |
| Long trip, short pickup | 800 | 15.3 | 355 | 445 |
fuel floor, PKR 23.2 per km. Anything right of it pays.Lime a good rateRed a weak rate
Held up
Rate is margin, exactly.
Fuel per km is constant, so margin per km is always rate minus 23.2. It reproduces his four steps instead of approximating them.
It catches deadhead: 3.1 km of unpaid pickup turns PKR 300 into 30.6/km and PKR 72 of margin.
Still blind
Time, and short trips.
Two 8 km rides at PKR 400 both read 50/km, but one takes 38 minutes and the other 14: PKR 338 an hour of margin against 918. A 2 km hop reads 75/km for 104 rupees.
That's why the test plan watches more than the rate.
My first benchmark was wrong.
I started with his average for the day. Then I simulated a day: one long, good ride at 70/km, then four normal ones. Step through it and watch what a normal 45/km offer reads as.
Average so farMedianthe 45/km offer
Press "Next ride" to start the day.
Step through his day, one ride at a time.
The decision
One unusual ride, and every normal offer looks bad all day. So the proposal uses a median.
The stress test changed the design.
A benchmark that lies is worse than none. Three things broke it, and each changed the design.
- Broke on: one unusually good ride
- Median, not mean. One unusual ride shouldn't move the benchmark.
- Broke on: fuel prices moving
- Rolling 7 days. A full weekly cycle, usually inside one fuel-price period. Pakistan resets petrol prices roughly fortnightly.
- Broke on: a driver on day four
- Minimum 20 rides. With too little history the number means nothing, so below 20 rides the rate shows alone. A new driver sees the comparison from around day 3.
The risk
Proposed
How it could backfire and how I'd know.
- The risk
- Drivers counter higher. Fares rise, or passengers wait longer. Countering costs the driver nothing, so the likely response isn't declining. It's holding out for more.
- Why it's smaller
- Some of that pressure already exists. Today it arrives after matching, as a cancellation. This moves it before matching, as a counter. A ride that never matched costs less than one that matched and fell through.
- How I'd test it
- The rate alone first, no comparison. One city. Post-acceptance cancellations, accepted fare, time-to-match and 90-day driver retention, measured together.
- When I'd kill it
- Fares rise and driver retention doesn't improve.
What success would look like Signals to watch, nothing has shipped
New drivers productive faster
No more learning good rides by taking bad ones.
What I'd watch: days to Nth ride, first-week earnings
Fewer cancellations after accepting
He prices before, not after.
What I'd watch: post-acceptance cancellations
Buying city-to-city again
He sees what it bought him.
What I'd watch: repeat purchase rate
Drivers past month three
The slowest benefit, and the largest.
What I'd watch: 90-day retention
Less support load
Fewer disputes to handle.
What I'd watch: contacts per ride
The response
I reached out to inDrive. They loved it.
I reached out to Dima Sergutov, a senior product design manager at inDrive. We met and went through the study together. He found it really informative, loved the work, and asked me to share the presentation so he could pass it on to his team.
Then I shared the study publicly. The comments were the best part: people tested the idea, not just the visuals.
LinkedIn, about a month after posting
- 4,649impressions
- 66reactions
- 15comments
- 1repost
On LinkedIn
Then I shared it on LinkedIn. People loved it too.
Comment on LinkedIn
Really good insight. The app had the data, but not the context needed to make a quick decision. Sometimes good UX isn't about adding more - it's about making the existing information useful at the right moment.
Comment on LinkedIn
Appreciate the efforts you put into this micro case study and the findings as they are providing values from the both business and user side.
My reply
The business side is the part I was most careful about, because a fix that only helps the driver isn't one inDrive would ship.
The sharpest question.
How does the app deal with the scenario where rate for the ride that is available to accept is below the median earnings for majority of the rides? Would that not create a supply problem where drivers are accepting even fewer rides per day?
Bilal NasirProduct and Experience Designer, UX Researcher, Adjunct Faculty for IxD
My reply
This is the right question to ask. It goes straight to the trade-off the whole thing lives or dies on.
On countering
On inDrive, countering isn't refusing. The passenger can accept the counter, and the ride goes ahead. So more counters doesn't mean fewer rides, it means more negotiation, which is what the product is for.
On the median
Half his rides sit below it by definition, so it was never a cutoff. It answers "is this normal for me," not "is this good." Good is the fuel floor, around 23 per km, and nearly everything clears that.
On quotas
I'd push back. That's the platform deciding which rides he takes, and inDrive's premise is the opposite. If acceptance drops on certain routes, that's a signal fares are wrong there.
“This is great!” Moazam Ijaz, UX Design Leader
“Amazing job” Yashfa Zabih, Product Designer @ Dubizzle Group
“Legendary work man!!” Faizan R., Senior Product Designer
“Well done! Appreciate the efforts.” Ali Zain, Software Engineer
Key Takeaways.
Four things this study changed about how I work.
Label The Evidence.
With one driver, the honest move was to tag every claim. It made the thin parts visible, and the strong parts stronger.
Now every claim I make carries its source.
Throwing Out Is Designing.
My first idea was a profit score for every ride, built from the mileage drivers enter at sign-up. That number is wrong twice: drivers guess it, and it drifts as the car ages. Rejecting it is why Rate Check uses his own rides instead.
Now I drop ideas that need a guess to work.
Stress-Test The Number.
The screen looked finished before the maths was. Six rides and one simulated day changed the design more than any layout did.
Now I test the logic before the pixels.
Remove Arithmetic, Not Judgment.
The best fix kept the decision with the driver. It just stopped asking him to do sums in seconds.
Now I design the step before the decision.
inDrive, self-initiated
Two weeks with one driver. Three findings. One line of type.
Shared with inDrive's product design team, and well received on LinkedIn.
Not affiliated with or commissioned by inDrive.
Next, from my case studies
Designing and shipping a luxury property website, end-to-end.
That was a self-initiated study. Here's one of my full case studies.
