Back to Home
Heroh.
UX & Visual Design.
Eco- System Design.
Driver App.
Redesigning the driver-facing app in the ZeroNow ecosystem shifting from a management model to an execution model so the person responsible for carrying children can focus on driving, not administration.
Overview.
Heroh is the last mile. If it fails, everything fails.
ZeroMoblt has three layers: a Parent App for tracking student commutes, Otime for internal operations, and Heroh the driver-facing app used to manage assigned school routes, pick up students from home, drop them at school, and log the trip.
The backend was being re-engineered from the ground up. The PM asked for a UI redesign alongside it. The constraint was real: two weeks to production. No new features requiring backend changes. A first version that was production-ready, visually consistent with the ecosystem, and meaningfully better than what existed.
Otime was built to replace that fragmentation with a structured ops platform giving supervisors a single place to monitor campuses, track route health, manage tasks, and resolve issues in real time.
The Problem.
The app treated the driver as an administrator.
When I was assigned an actual route and used the app in real conditions, it fell apart. The interface gave equal visual weight to everything route metadata, student names, attendance toggles, trip status so nothing felt urgent. I didn't know what I was supposed to do next.
The attendance flow required me to manually confirm every student at every stop. At each stop: drive, check who's present, tap present for each student, then confirm pickup. That's not a driver. That's a data entry operator who also happens to be behind a wheel.
"For a driver with 4 students across 3 stops, the original flow required 12 deliberate taps before the trip even ended each one a moment of distraction."
Three specific failures: no visual hierarchy (everything competed at the same level), attendance as manual labor, and a header that showed a truncated route code instead of situational context.
Design Principle.
The driver's job is to drive.
Everything else should either happen automatically, be handled by the ecosystem, or require no more than two taps in an exceptional case.
This single principle made every decision easier. When I wasn't sure whether to surface information or hide it, I asked: does a driver need this while driving, or does this belong in a log they check later? When I wasn't sure whether to require a tap, I asked: is this the standard case or the exception?
"The driver went from octopus to operator."
Three specific failures: no visual hierarchy (everything competed at the same level), attendance as manual labor, and a header that showed a truncated route code instead of situational context.
The Decisions.
Four decisions that changed the experience.
Decision 01
Attendance defaults to present.
The original flow required the driver to confirm presence for every student at every stop. The redesign eliminates that entirely for the standard case.
The parent has already scheduled the ride. That booking is the source of truth. If a student is expected, they are marked present by default. The slide to confirm pickup is itself the attendance confirmation no extra tap required. If a student is pre-marked absent by the parent, their card appears as skipped automatically. Zero taps required.
Trade-Off
My version: Defaulting to present means a no-show that isn't caught becomes a false attendance record. The GPS lock and the no-show flow are the safety net that makes the default viable.
Decision 02
The header shows where you are, not what route you're on.
The original header showed the route name truncated, technical, and useless while driving. I replaced it with situational context: "Current Stop: Maya's" or "Upcoming Stop: Sam."
The driver already knows the route. What they need while driving is to know exactly where they are in it. As a side effect, if a supervisor calls mid-trip, the driver can glance and answer precisely without pulling over.
Trade-Off
A driver who is genuinely lost or confused about which route they're on has no way to verify it from the header. The route name is gone. This works when the driver knows their route well which is the standard case but edge cases like a substitute driver covering an unfamiliar route need a fallback. The full route detail is still accessible, just not surfaced by default.
Decision 03
Earnings upfront, setup below.
The redesign leads with Earning Potential base rate and peak bonus visible immediately. A driver opening the app before a shift needs one thing confirmed: that the effort is worth it.
The hierarchy follows the driver's actual priority order: money, then readiness, then information.
Decision 04
The slider prevents accidents and locks the log.
Two problems with a simple confirm button: accidental taps, and drivers backdating confirmations after departing. The slide-to-confirm gesture solves both it requires deliberate intent and once the GPS detects the vehicle moving, the slider disables.
The log is locked to what happened at the location, not what the driver remembers five minutes later.
Trade-Off
GPS isn't perfectly accurate. A driver parked at a stop in a weak signal area could trigger false movement detection, locking the slider before they've finished marking attendance. The threshold for what counts as "moving" is an implementation decision, set it too low and legitimate stationary drivers get locked out, set it too high and the backdating problem returns. This needs real-world calibration from the dev team.
Edge Cases.
The exceptions are where the product earns trust or breaks it.
Edge Case 01
The no-show three states, two taps maximum.
Pre-marked absent by parent → banner notification, stop skipped automatically, zero taps. Unexpected no-show → driver taps card, confirmation modal, two taps total. Confirmed → slider turns red, state holds, GPS locks the log on movement.
Edge Case 02
The two-kids problem.
The parent can cancel up to 60 seconds before the driver arrives. The moment they do, a banner surfaces on the driver's screen: 'Arora is absent today. Rerouting trip.' The route recalculates automatically, skipping the stop and saving the driver unnecessary travel. The driver doesn't need to do anything. The parent's action becomes the driver's updated reality in real time.
This wasn't purely a UI decision. It was a data modelling recommendation that came out of designing both sides of the ecosystem simultaneously. The parent thinks in family accounts. The driver operates on individual pickups. When both sides share the same student-level data model, a cancellation on one side becomes a reroute on the other automatically, without a single extra tap from the driver. Designing one side in isolation would never have surfaced it.
Interface.
The screens.
01 / Onboarding & KYC
The driver's first question is answered before anything else
02 / Active Trip
The driver drives. Everything else follows.
03/ Trip History
Proof of service. Progressive disclosure.
04/ Earnings
Drivers had zero visibility into how their pay was calculated. Now they see everything.
05 / Settings & Diagnostics
Profile as performance. Diagnostics as a map.
Learnings.
Use the product before you design for it:
I wouldn't have found the real problem without running an actual route. The interface that looks reasonable in Figma can feel completely wrong at a stop with 30 seconds before departure.
Edge cases aren't edge cases to the person experiencing them:
Each edge felt rare until I thought through the driver's actual week. The standard flow is easy to design. Exceptions are where trust is earned or broken.
Articulate the reasoning, not just the decision:
"Attendance defaults to present" can be overruled. "Attendance defaults to present because the booking is the source of truth and the driver's job is to drive" has to be engaged with.
Two apps, one ecosystem:
Designing the driver app and reviewing the parent app simultaneously made the gaps visible in ways that designing one side in isolation never would. Consistency across the ecosystem isn't a visual concern it's a trust concern.
Conclusion.
The driver opens the app and knows immediately what they're earning, where they are in the route, and what needs attention. Everything else happens in the background.
On the other side, the parent opens Zero and sees the same truth the driver is acting on.
Three apps. One ecosystem. The driver drives. The parent trusts.
The Supervisor Manages.
This project was completed as part of my apprenticeship at ZeroMoblt. The redesign was handed off to the development team in April 2026.
Back to Home
Heroh.
UX & Visual Design.
Eco- System Design.
Driver App.
Redesigning the driver-facing app in the ZeroNow ecosystem shifting from a management model to an execution model so the person responsible for carrying children can focus on driving, not administration.
Overview.
Heroh is the last mile. If it fails,
everything fails.
ZeroMoblt has three layers: a Parent App for tracking student commutes, Otime for internal operations, and Heroh the driver-facing app used to manage assigned school routes, pick up students from home, drop them at school, and log the trip.
The backend was being re-engineered from the ground up. The PM asked for a UI redesign alongside it. The constraint was real: two weeks to production. No new features requiring backend changes. A first version that was production-ready, visually consistent with the ecosystem, and meaningfully better than what existed.
Otime was built to replace that fragmentation with a structured ops platform giving supervisors a single place to monitor campuses, track route health, manage tasks, and resolve issues in real time.
The Problem.
The app treated the driver as an administrator.
When I was assigned an actual route and used the app in real conditions, it fell apart. The interface gave equal visual weight to everything route metadata, student names, attendance toggles, trip status so nothing felt urgent. I didn't know what I was supposed to do next.
The attendance flow required me to manually confirm every student at every stop. At each stop: drive, check who's present, tap present for each student, then confirm pickup. That's not a driver. That's a data entry operator who also happens to be behind a wheel.
"For a driver with 4 students across 3 stops, the original flow required 12 deliberate taps before the trip even ended each one a moment of distraction."
Three specific failures: no visual hierarchy (everything competed at the same level), attendance as manual labor, and a header that showed a truncated route code instead of situational context.
Design Principle.
The driver's job is to drive.
Everything else should either happen automatically, be handled by the ecosystem, or require no more than two taps in an exceptional case.
This single principle made every decision easier. When I wasn't sure whether to surface information or hide it, I asked: does a driver need this while driving, or does this belong in a log they check later? When I wasn't sure whether to require a tap, I asked: is this the standard case or the exception?
"The driver went from octopus to operator."
Three specific failures: no visual hierarchy (everything competed at the same level), attendance as manual labor, and a header that showed a truncated route code instead of situational context.
The Decisions.
Four decisions that changed
the experience.
Decision 01
Attendance defaults to present.
The original flow required the driver to confirm presence for every student at every stop. The redesign eliminates that entirely for the standard case.
The parent has already scheduled the ride. That booking is the source of truth. If a student is expected, they are marked present by default. The slide to confirm pickup is itself the attendance confirmation no extra tap required. If a student is pre-marked absent by the parent, their card appears as skipped automatically. Zero taps required.
Trade-Off
My version: Defaulting to present means a no-show that isn't caught becomes a false attendance record. The GPS lock and the no-show flow are the safety net that makes the default viable.
Decision 02
The header shows where you are,
not what route you're on.
The original header showed the route name truncated, technical, and useless while driving. I replaced it with situational context: "Current Stop: Maya's" or "Upcoming Stop: Sam."
The driver already knows the route. What they need while driving is to know exactly where they are in it. As a side effect, if a supervisor calls mid-trip, the driver can glance and answer precisely without pulling over.
Trade-Off
A driver who is genuinely lost or confused about which route they're on has no way to verify it from the header. The route name is gone. This works when the driver knows their route well which is the standard case but edge cases like a substitute driver covering an unfamiliar route need a fallback. The full route detail is still accessible, just not surfaced by default.
Decision 03
Earnings upfront, setup below.
The redesign leads with Earning Potential base rate and peak bonus visible immediately. A driver opening the app before a shift needs one thing confirmed: that the effort is worth it.
The hierarchy follows the driver's actual priority order: money, then readiness, then information.
Decision 04
The slider prevents accidents and
locks the log.
Two problems with a simple confirm button: accidental taps, and drivers backdating confirmations after departing. The slide-to-confirm gesture solves both it requires deliberate intent and once the GPS detects the vehicle moving, the slider disables.
The log is locked to what happened at the location, not what the driver remembers five minutes later.
Trade-Off
GPS isn't perfectly accurate. A driver parked at a stop in a weak signal area could trigger false movement detection, locking the slider before they've finished marking attendance. The threshold for what counts as "moving" is an implementation decision, set it too low and legitimate stationary drivers get locked out, set it too high and the backdating problem returns. This needs real-world calibration from the dev team.
Edge Cases.
The exceptions are where the
product earns trust or breaks it.
Edge Case 01
The no-show three states, two
taps maximum.
Pre-marked absent by parent → banner notification, stop skipped automatically, zero taps. Unexpected no-show → driver taps card, confirmation modal, two taps total. Confirmed → slider turns red, state holds, GPS locks the log on movement.
Edge Case 02
The two-kids problem.
The parent can cancel up to 60 seconds before the driver arrives. The moment they do, a banner surfaces on the driver's screen: 'Arora is absent today. Rerouting trip.' The route recalculates automatically, skipping the stop and saving the driver unnecessary travel. The driver doesn't need to do anything. The parent's action becomes the driver's updated reality in real time.
This wasn't purely a UI decision. It was a data modelling recommendation that came out of designing both sides of the ecosystem simultaneously. The parent thinks in family accounts. The driver operates on individual pickups. When both sides share the same student-level data model, a cancellation on one side becomes a reroute on the other automatically, without a single extra tap from the driver. Designing one side in isolation would never have surfaced it.
Interface.
The screens.
01 / Onboarding & KYC
The driver's first question is answered before anything else
02 / Active Trip
The driver drives. Everything else follows.
03/ Trip History
Proof of service. Progressive disclosure.
04/ Earnings
Drivers had zero visibility into how their pay was calculated. Now they see everything.
05 / Settings & Diagnostics
Profile as performance. Diagnostics as a map.
Learnings.
Use the product before you design for it:
I wouldn't have found the real problem without running an actual route. The interface that looks reasonable in Figma can feel completely wrong at a stop with 30 seconds before departure.
Edge cases aren't edge cases to the person experiencing them:
Each edge felt rare until I thought through the driver's actual week. The standard flow is easy to design. Exceptions are where trust is earned or broken.
Articulate the reasoning, not just the decision:
"Attendance defaults to present" can be overruled. "Attendance defaults to present because the booking is the source of truth and the driver's job is to drive" has to be engaged with.
Two apps, one ecosystem:
Designing the driver app and reviewing the parent app simultaneously made the gaps visible in ways that designing one side in isolation never would. Consistency across the ecosystem isn't a visual concern it's a trust concern.
Conclusion.
The driver opens the app and knows immediately what they're earning, where they are in the route, and what needs attention. Everything else happens in the background.
On the other side, the parent opens Zero and sees the same truth the driver is acting on.
Three apps. One ecosystem. The driver drives. The parent trusts. The Supervisor Manages.
This project was completed as part of my apprenticeship at ZeroMoblt. The redesign was handed off to the development team in April 2026.
Back to Home
Heroh.
UX & Visual Design.
Eco- System Design.
Driver App.
Redesigning the driver-facing app in the ZeroNow ecosystem shifting from a management model to an execution model so the person responsible for carrying children can focus on driving, not administration.
Overview.
Heroh is the last mile. If it fails, everything fails.
ZeroMoblt has three layers: a Parent App for tracking student commutes, Otime for internal operations, and Heroh the driver-facing app used to manage assigned school routes, pick up students from home, drop them at school, and log the trip.
The backend was being re-engineered from the ground up. The PM asked for a UI redesign alongside it. The constraint was real: two weeks to production. No new features requiring backend changes. A first version that was production-ready, visually consistent with the ecosystem, and meaningfully better than what existed.
Otime was built to replace that fragmentation with a structured ops platform giving supervisors a single place to monitor campuses, track route health, manage tasks, and resolve issues in real time.
The Problem.
The app treated the driver as an administrator.
When I was assigned an actual route and used the app in real conditions, it fell apart. The interface gave equal visual weight to everything route metadata, student names, attendance toggles, trip status so nothing felt urgent. I didn't know what I was supposed to do next.
The attendance flow required me to manually confirm every student at every stop. At each stop: drive, check who's present, tap present for each student, then confirm pickup. That's not a driver. That's a data entry operator who also happens to be behind a wheel.
"For a driver with 4 students across 3 stops, the original flow required 12 deliberate taps before the trip even ended each one a moment of distraction."
Three specific failures: no visual hierarchy (everything competed at the same level), attendance as manual labor, and a header that showed a truncated route code instead of situational context.
Design Principle.
The driver's job is to drive.
Everything else should either happen automatically, be handled by the ecosystem, or require no more than two taps in an exceptional case.
This single principle made every decision easier. When I wasn't sure whether to surface information or hide it, I asked: does a driver need this while driving, or does this belong in a log they check later? When I wasn't sure whether to require a tap, I asked: is this the standard case or the exception?
"The driver went from octopus to operator."
Three specific failures: no visual hierarchy (everything competed at the same level), attendance as manual labor, and a header that showed a truncated route code instead of situational context.
The Decisions.
Four decisions that changed the experience.
Decision 01
Attendance defaults to present.
The original flow required the driver to confirm presence for every student at every stop. The redesign eliminates that entirely for the standard case.
The parent has already scheduled the ride. That booking is the source of truth. If a student is expected, they are marked present by default. The slide to confirm pickup is itself the attendance confirmation no extra tap required. If a student is pre-marked absent by the parent, their card appears as skipped automatically. Zero taps required.
Trade-Off
My version: Defaulting to present means a no-show that isn't caught becomes a false attendance record. The GPS lock and the no-show flow are the safety net that makes the default viable.
Decision 02
The header shows where you are, not what route you're on.
The original header showed the route name truncated, technical, and useless while driving. I replaced it with situational context: "Current Stop: Maya's" or "Upcoming Stop: Sam."
The driver already knows the route. What they need while driving is to know exactly where they are in it. As a side effect, if a supervisor calls mid-trip, the driver can glance and answer precisely without pulling over.
Trade-Off
A driver who is genuinely lost or confused about which route they're on has no way to verify it from the header. The route name is gone. This works when the driver knows their route well which is the standard case but edge cases like a substitute driver covering an unfamiliar route need a fallback. The full route detail is still accessible, just not surfaced by default.
Decision 03
Earnings upfront, setup below.
The redesign leads with Earning Potential base rate and peak bonus visible immediately. A driver opening the app before a shift needs one thing confirmed: that the effort is worth it.
The hierarchy follows the driver's actual priority order: money, then readiness, then information.
Decision 04
The slider prevents accidents and locks the log.
Two problems with a simple confirm button: accidental taps, and drivers backdating confirmations after departing. The slide-to-confirm gesture solves both it requires deliberate intent and once the GPS detects the vehicle moving, the slider disables.
The log is locked to what happened at the location, not what the driver remembers five minutes later.
Trade-Off
GPS isn't perfectly accurate. A driver parked at a stop in a weak signal area could trigger false movement detection, locking the slider before they've finished marking attendance. The threshold for what counts as "moving" is an implementation decision, set it too low and legitimate stationary drivers get locked out, set it too high and the backdating problem returns. This needs real-world calibration from the dev team.
Edge Cases.
The exceptions are where the product earns trust or breaks it.
Edge Case 01
The no-show three states, two taps maximum.
Pre-marked absent by parent → banner notification, stop skipped automatically, zero taps. Unexpected no-show → driver taps card, confirmation modal, two taps total. Confirmed → slider turns red, state holds, GPS locks the log on movement.
Edge Case 02
The two-kids problem.
The parent can cancel up to 60 seconds before the driver arrives. The moment they do, a banner surfaces on the driver's screen: 'Arora is absent today. Rerouting trip.' The route recalculates automatically, skipping the stop and saving the driver unnecessary travel. The driver doesn't need to do anything. The parent's action becomes the driver's updated reality in real time.
This wasn't purely a UI decision. It was a data modelling recommendation that came out of designing both sides of the ecosystem simultaneously. The parent thinks in family accounts. The driver operates on individual pickups. When both sides share the same student-level data model, a cancellation on one side becomes a reroute on the other automatically, without a single extra tap from the driver. Designing one side in isolation would never have surfaced it.
Interface.
The screens.
01 / Onboarding & KYC
The driver's first question is answered before anything else
02 / Active Trip
The driver drives. Everything else follows.
03/ Trip History
Proof of service. Progressive disclosure.
04/ Earnings
Drivers had zero visibility into how their pay was calculated. Now they see everything.
05 / Settings & Diagnostics
Profile as performance. Diagnostics as a map.
Learnings.
Use the product before you design for it:
I wouldn't have found the real problem without running an actual route. The interface that looks reasonable in Figma can feel completely wrong at a stop with 30 seconds before departure.
Edge cases aren't edge cases to the person experiencing them:
Each edge felt rare until I thought through the driver's actual week. The standard flow is easy to design. Exceptions are where trust is earned or broken.
Articulate the reasoning, not just the decision:
"Attendance defaults to present" can be overruled. "Attendance defaults to present because the booking is the source of truth and the driver's job is to drive" has to be engaged with.
Two apps, one ecosystem:
Designing the driver app and reviewing the parent app simultaneously made the gaps visible in ways that designing one side in isolation never would. Consistency across the ecosystem isn't a visual concern it's a trust concern.
Conclusion.
The driver opens the app and knows immediately what they're earning, where they are in the route, and what needs attention. Everything else happens in the background.
On the other side, the parent opens Zero and sees the same truth the driver is acting on.
Three apps. One ecosystem. The driver drives. The parent trusts. The Supervisor Manages.
This project was completed as part of my apprenticeship at ZeroMoblt. The redesign was handed off to the development team in April 2026.
Always Open to Meaningful Conversation!
Open to roles, collaborations, and conversations.
© 2026 Senthil Nathan.
Always Open to Meaningful Conversation!
Open to roles, collaborations, and conversations.
© 2026 Senthil Nathan.
Always Open to Meaningful
Conversation!
Open to roles, collaborations, and conversations.
© 2026 Senthil Nathan.
Always Open to Meaningful Conversation!
Open to roles, collaborations, and conversations.
© 2026 Senthil Nathan.