Designed and led regulatory approval for a BBPS-powered FASTag recharge experience — bringing a fragmented, revenue-leaking behaviour back into the BlackBuck app.
of active FASTag users had non-partner bank FASTags — recharging via third-party apps
task success on both critical usability metrics after redesign — up from 62% and 38% in V1
revenue per BBPS recharge transaction captured — at scale across millions of recharge events annually
BlackBuck is India's largest digital trucking platform. The user base spans individual owner-operators with 1–3 trucks to large fleet owners (LFOs) managing 50–100+ vehicles remotely. For trucks with non-partner bank FASTags, drivers were leaving the app entirely to recharge on PhonePe, GPay, or Paytm.
BBPS (Bharat Bill Payment System) is an RBI-mandated interoperable bill payment platform operated by NPCI. For BlackBuck, it was the regulatory pathway to enable recharges for non-partner bank FASTags inside the app. Without it, there was no compliant way to do it.
As an Agent Institution under BBPS, BlackBuck's UI had to meet NPCI's front-end compliance standards before the feature could go live. This wasn't an internal review — it required formal sign-off from the regulator.
The business problem: 35% of active FASTag users were completing high-frequency recharges outside the app — a revenue leak with no visibility and no recovery mechanism.
The user problem: In a truck driver's mental model, a FASTag is a FASTag. The bank behind it is invisible and irrelevant. But the app treated partner-bank and non-partner-bank FASTags as entirely separate categories.
The tension was between system truth and user mental model — and the system had to lose.
The field research insight that reframed everything: We initially assumed our competition was other trucking apps. Field research revealed the real competition was PhonePe, GPay, and Paytm. We weren't building a trucking feature — we were building something that had to feel as effortless as a super-app flow.
Once field research surfaced that PhonePe and GPay were the real competition, I studied their FASTag recharge flows in depth — information architecture, vehicle entry patterns, recharge confirmation states, and error handling. The design language had to feel instantly familiar to someone who'd done this on GPay a dozen times.
The first version presented two distinct entry points: one for partner-bank FASTags, one for BBPS recharges. 87% completed the flow on first attempt. But when asked to repeat a recharge for the same truck, 62% couldn't find their way back. And 38% couldn't locate their existing trucks — the new BBPS section had broken the mental model they'd built around the FASTag homepage.
A flow that worked once but failed on repeat was not a working flow.
Every major BBPS implementation — GPay, PhonePe, Paytm — follows the same pattern: select your FASTag biller first, then enter your VRN. We deviated deliberately — and had to justify why to the regulator.
1. Select FASTag biller
2. Enter VRN
3. Fetch FASTag details
4. Recharge
1. Enter VRN
2. Auto-fetch biller via NPCI
3. Change biller if needed (optional)
4. Recharge
The case for removing biller selection was strongest for large fleet owners (LFOs). An LFO managing 50+ trucks remotely almost certainly doesn't know which bank issued each vehicle's FASTag — not without calling the driver on the ground. Biller selection wasn't just friction. It was an operational blocker.
After a month of negotiation across three parties (BlackBuck, PayU, NBBL), NPCI approved the deviation. The biller change option post-fetch was retained as the compliance concession.
In a driver's mental model, there is no "BBPS recharge" vs. a "FASTag recharge." There is only "recharge my truck." So rather than carving out a separate section, we pre-populated non-partner bank trucks into the same vehicle list — grouped alongside partner-bank trucks. The BBPS rail handled the transaction invisibly.
62%
could repeat a recharge
38%
could locate existing trucks
90%+
task repeatability — restored
90%+
vehicle discoverability — restored
The V1 failure was avoidable. The decision to surface BBPS as a separate category came from system logic — it is technically a distinct rail — rather than from a mental model study of how drivers categorise their trucks and their money.
A short mental model interview round before the first design decision would almost certainly have surfaced the "a FASTag is a FASTag" insight before we built the wrong thing. In hindsight, I'd treat the mental model question as the first design deliverable on any project that introduces a new payment rail into an existing product.