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

B:Live - EV Mobility Platform·2 MONTHS
B2C AppUX ResearchDesigner0→1 Product
blive.co.in
The redesigned EZY rider app home screen
About

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.

Team
  • Avni Garg (Me)Product Designer
  • Rohith PaulLead Product Designer
  • Sneha JhaAssociate Product Manager
  • DivyanshuFrontend Developer

1. Who, Why & What

Problem

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 0

Before 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 1

A 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.

Signing up — screen

First payout

Week 1

A 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.

First payout — screen

Trying to earn more

Week 2

He 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 2

He 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 3

His 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.

Something goes wrong — screen
Research

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

Competitive research + in-house interviews

What I did

5 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 did

Contextual 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.

Research synthesis board — competitive teardown and interview notes

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.

Two different reads on the problem

Riders vs. stakeholders

What riders asked for

A ticketing/support flow, clear payout visibility, easier vehicle redeployment, and more rental plan options.

What stakeholders assumed

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.

Action plan

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.

01

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.

02

Payout visibility

Give riders a clear, simple view of what they earned, directly inside the app.

03

Ticket support

A basic in-app support flow, with a fuller call-first, escalation-based version scoped for later.

04

Vehicle redeployment flow

Designed and validated with riders, scoped for a later phase.

05

More rental plan options

Designed and validated with riders, scoped for a later phase.

2. Product Scoping

User storyRider user story — onboarding, earnings, and support

3. Design Evolution

Design Iterations

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

Live
Before

Types in name, address, bank account, Aadhar, PAN, license by hand. Gives up around step two.

After

Enters his phone number, most details are pulled in automatically. He just reviews and confirms.

Drop-off: 10/20 → 4/20

Onboarding — before and after screens

Payout visibility

Live
Before

Opens the app looking for one number, and instead finds payslips and line items to piece together.

After

Sees exactly what he earned, right away, plus a status on every payout: Processing, Blocked, or Paid.

Top reason riders were leaving is addressed

Payout visibility — before and after screens

Support

Partial
Before

Vehicle has an issue. He calls the saved number. Nobody picks up.

After

Raises a ticket in-app instead, and sees it logged with a status; someone owns it.

A first support loop is in riders' hands

Support — before and after screens
Design Trade-offs
Shipped

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."

Designed but development on hold

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.

Designed and validated, on hold

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 modernization

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.

EZY design system — before and after rider app screens

4. Resolved partially, and honestly

Resolved
20%
Onboarding drop-off, before → after
4/20
Riders drop off now, down from 10/20
Live
Full payout visibility, shipped.

Some 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.