From a one-time app to one riders actually trust.

I owned all research and design for this project, every user interview, every hub visit, and every screen. I worked with a senior designer on building the new design system, and partnered closely with the PM on what made it into scope. With a team this small, I wasn't just producing screens; I was the one deciding what riders actually needed, based on research I ran myself.
- Avni Garg (Me)Product Designer
- Rohith PaulLead Product Designer
- Sneha JhaAssociate Product Manager
- DivyanshuFrontend Developer
1. Who, Why & What
An app riders needed once, then abandoned:
Over 10,000 riders used EZY for exactly two things: signing up, and checking their rental. After that, the app gave them no reason to come back, even though it held information they actually cared about.
A rider's first week with EZY, the way it actually happened, moment by moment, with the psychology behind each drop-off point:
Before he even signs up
Day 0Before downloading EZY, he checks what a few options charge upfront. EZY's security deposit is higher than what Zypp Electric asks for, and he isn't sure he'll get it back if he stops riding.
Anchoring
People judge whether a cost is fair by comparing it to the first reference point they see, not in isolation.
A higher deposit than a known competitor, with no clarity on refunds, makes EZY feel like the riskier choice before he's even tried it.
Signing up
Day 1A rider downloads EZY to start delivering. He fills in his phone number, gets an OTP, and lands on a long onboarding list, name, address, bank account, Aadhar, PAN, driving license, all typed in by hand.
“Itna sab bharna padega? Baad mein karta hoon…”
Cognitive Load
The total effort it takes to complete and understand a task. The less effort, the more people finish it.
Every hand-typed field is one more reason to close the app “for later.” 10 out of 20 riders never made it past this point.

First payout
Week 1A rider who pushes through starts working. At week's end he opens the app to check his earnings and finds numbers and categories, but no single clear answer to “how much do I have?” Some weeks the payout doesn't land on the day he expects, or his account gets blocked, with no explanation of why.
“Bas final amount batao, itna detail nahi chahiye.”
Cognitive Load - earnings edition
Data existing isn't the same as data being usable. If understanding a number takes effort, people give up before getting their answer.
The payout data already existed; it just wasn't shown as an answer.

Trying to earn more
Week 2He notices other riders earn more, with no idea why, no in-app guidance on the best time to work, or how close he is to an incentive.
“Aur zyada kama sakta hoon, but kaise?”
Missing Feedback Loop
People stay motivated when a system shows how close they are to a goal. Silence reads as “nothing I do here matters.”
No visible progress toward an incentive gave him no reason to try harder or open the app.
The orders that skip him
Week 2He notices the highest-paying orders never seem to come his way. He asks support, and is told to “change dark stores”, advice that doesn't hold up against how his day actually works.
“App se help milti hi nahi.”
Perceived Fairness
People judge a system not just by their outcome, but by whether the process that produced it felt fair.
Whether or not the allocation was actually biased, it read as unfair, and that belief alone is enough to push a rider toward another platform.
Something goes wrong
Week 3His vehicle has an issue. He looks for help in the app, doesn't find a clear way to raise it, and calls the number he has saved instead. The call isn't picked up.
“App se help milti hi nahi.”
Peak-End Rule
People judge an experience mostly by its most intense moment and how it ends, not the average of everything before it.
One unanswered call in a real moment of need outweighs every smooth screen that came before it.

I ran research on two tracks over the course of a month.




Competitive research + in-house interviews
What I did5 sessions, 10 riders each, a mix of active and lapsed users. Alongside this, a direct benchmark against Zypp Electric, Bounce Daily, Halo, Yulu, and Eveez, plus a review of what riders were already saying about EZY on the Play Store.

On-ground research
What I didContextual inquiry with 3 riders, done alongside our collections team, who visit riders directly. I took part in this in person, seeing where the app's job was quietly being done by a person instead.

The competitive benchmark shaped how I read parts of what riders said, like the deposit comparison in the story above, which only made sense once we saw what Zypp Electric was charging.
Riders vs. stakeholders
A ticketing/support flow, clear payout visibility, easier vehicle redeployment, and more rental plan options.
Riders mainly wanted to see their rider category, for example, their Diamond tier status and its benefits.
I had already flagged payout visibility and an AI-based support chat as priorities before this research, but neither had been treated as a priority until the research gave them direct rider voices behind them.
Research pointed to one core insight: EZY wasn't failing because it was hard to use; it was failing because it gave riders no reason to open it after day one. With three months, I scoped the plan around the two problems most directly causing riders to leave.
Onboarding redesign
Replace manual eKYC and detail entry with auto-fetched data via 3rd-party integration, so riders don't drop off before they even start using the app.
Payout visibility
Give riders a clear, simple view of what they earned, directly inside the app.
Ticket support
A basic in-app support flow, with a fuller call-first, escalation-based version scoped for later.
Vehicle redeployment flow
Designed and validated with riders, scoped for a later phase.
More rental plan options
Designed and validated with riders, scoped for a later phase.
2. Product Scoping
User story
3. Design Evolution
With a small team and a tight timeline, most of the real design work happened in negotiation, deciding what to push for, and what to let wait.
The same rider, now
Three short stories, the same rider from the pain points, living through what changed.
Onboarding
LiveTypes in name, address, bank account, Aadhar, PAN, license by hand. Gives up around step two.
Enters his phone number, most details are pulled in automatically. He just reviews and confirms.
Drop-off: 10/20 → 4/20

Payout visibility
LiveOpens the app looking for one number, and instead finds payslips and line items to piece together.
Sees exactly what he earned, right away, plus a status on every payout: Processing, Blocked, or Paid.
Top reason riders were leaving is addressed

Support
PartialVehicle has an issue. He calls the saved number. Nobody picks up.
Raises a ticket in-app instead, and sees it logged with a status; someone owns it.
A first support loop is in riders' hands

Payout visibility vs. hiding deductions
Stakeholders wanted to hide full payout details from riders, worried that showing the numbers might cause riders to leave the platform. Research said the opposite: riders were already leaving because they had no visibility into what they earned.
I pushed back with the rider research directly, the risk wasn't showing riders their payout, it was continuing to hide it.
Full payout visibility went live. The one compromise: detailed deduction breakdowns still aren't shown; riders see what they earned, not a line-by-line "why."
Call-first support with escalation logic
Support was one of the clearest rider complaints; calls went unanswered, with no reliable way to get help. I designed a 1-tap, call-first support entry point with escalation logic for unresolved issues. A basic ticketing flow shipped, but development on the fuller version hasn't started yet.
Redeployment flow & more rental plans
Riders asked for an easier way to redeploy vehicles and more flexibility in rental plan options. Both were designed and tested with riders, but development on this part of the revamp is currently paused for business reasons, not because the need wasn't real.
Design system, built from scratch
EZY had no consistent design system to build on, so alongside this project, I built one from the ground up with my senior designer, not adapted from an existing component library. Every token, component, and pattern used across the redesigned onboarding and payout flows came out of that system.

4. Resolved partially, and honestly
ResolvedSome of this shipped and is already measurable. Some is validated with riders but paused in development for business reasons; both are part of the honest picture.