02 — Case study
All workFleet Management
Software for organisations running vehicle fleets at scale: challans, document validity, live vehicle location, and driver, manager and owner management — each user type in its own portal. It also manages the progressive pumps the company manufactures, streaming pump health, expiry and maintenance data in over IoT so owners can see which vehicles are fitted and act before something fails.
01
The problem
For the business
The company manufactures progressive pumps, and once a pump left the factory it disappeared. Nobody could say which vehicles carried one, what condition it was in, or when it was next due for service — not the manufacturer, and not the owner of the vehicle it was fitted to. Both of them paid for that blindness in the same event: the service slipped, the pump failed, and a vehicle stopped in critical condition. The owner lost the vehicle and the work it was doing. The manufacturer lost its name to a service call that arrived after the breakdown instead of before it.
For the people using it
Interviewing vehicle owners changed what the product was. Running one or two thousand vehicles, the pump was not their largest problem. Nobody could total the fines — how many, how much, raised where. Nobody could say which documents had expired or were about to, or which Fastags were blocked, empty, or nearly empty. At that fleet size the arithmetic simply cannot be done by hand, so owners did not know where money had to go next, and large sums went to penalties that a week of notice would have prevented.
02
Constraints
What limited us
- The driver app had to work for people who do not read it. Many drivers in India are not literate, so it had to be understood by looking rather than by reading — of everything on this project, that is the part that took the most thinking
- Challan data had to be brought in from outside the product, and putting Fastag recharge inside it meant carrying a payment flow that was not ours. Neither was straightforward to work out
What we were aiming at
- See every pump the company has manufactured once it is in the field — which vehicle carries it, what condition it is in, when it is due
- Get the service call to the vehicle before the breakdown rather than after it, which is where both the owner’s loss and the manufacturer’s reputation were going
03
My scope
What I owned
- All the design across every portal and the driver app — I was the only designer
- Interviewed vehicle owners before designing, and the findings redrew the product’s scope from the pump to the vehicle
- Designed for three distinct user types: owners, managers and drivers
- Designed the IoT pump telemetry views — health, expiry and maintenance
- Designed driver safety around evidence rather than a score alone: every incident lands on the trip’s traced route with cabin, front and rear camera stills attached to it
What I didn’t
- Did not write the production code — the design was mine end to end, the build was not
04
Research
What we found
- The brief was a pump tracker. The owners we interviewed had larger problems than the pump — unpaid challans, expiring documents, blocked or empty Fastags — and none of it was visible at fleet scale
- At one to two thousand vehicles, arithmetic is the product. How much is owed, what expires this month, which cards are empty: every question an owner has is impossible to answer by hand
Where it hurt
- An owner learned about a pump when the vehicle stopped, not before — and by then the vehicle and the work it was doing were both lost
- Fines surfaced as a total after the fact, when a week of notice would have prevented most of them
05
Decisions
Decision 01
The brief was one thing: track our pumps in the field. That was a real problem and a solvable one — but it was the manufacturer’s problem, and the person who would have to open this software every day was the vehicle owner.
Chosen
We interviewed owners before designing, and the product grew from the pump to the vehicle. One page per vehicle now carries pump health off the IoT stream, the Fastag balance and its last transaction, pending challans with the overdue ones flagged, and every document with its expiry — registration, permit, fitness, insurance — beside the chassis number and the driver.
Rejected, and why
Building the pump tracker as briefed was faster, and it was what had been asked for. It lost because an owner will not open a tool daily for the pump alone — and a tool nobody opens does not get the pump serviced either. The manufacturer’s own goal turned out to depend on solving the owner’s problem first.
Decision 02
A reading on a dashboard prevents nothing unless it reaches the person who can act on it, and that person changes with what is wrong and how soon it matters.
Chosen
The pump’s condition decides who hears about it and how loudly. Ordinary conditions notify; urgent ones place a call. A service date coming up reaches the manager and the driver, with a location suggested to have it done. A pump approaching end of life reaches the manufacturer as well as the owner, because replacing it is the manufacturer’s job, not the owner’s.
Rejected, and why
The first plan was a system for the owner alone. Managers came second, and drivers got a mobile application of their own after that. Owner-only lost to the size of the fleet it was built for — someone running a thousand vehicles is not the person who takes one of them in for a service. Each portal exists because the person who can act on a given condition is a different person, and the driver’s is an app because he is the only one of the three who is never at a desk.
Decision 03
A fleet dashboard usually reports what exists: how many vehicles, how far they ran, how much fuel. None of that tells an owner where to spend the next hour.
Chosen
The dashboard opens on what is about to fail. Pumps that have reached end of life, pumps approaching it, pumps low on grease — then unhealthy pumps broken down by fault type and by vehicle type, so a pattern in the machines is visible next to a pattern in the fleet.
Rejected, and why
The first version was a more conventional dashboard and it widened as the platform did. What pushed it was the thing this product exists for: every loss in this business — the stopped vehicle, the service call that came late, the fine nobody saw coming — happens because something was not noticed in time. A dashboard that reports what exists cannot serve that. One that opens on whatever is closest to failing can.
Decision 04
Once the vehicles were on a map the questions changed from maintenance to what happened. An accident is disputed and a claim needs proof. A driver’s habits at the wheel are visible to nobody but the driver. And a safety score on its own is only an accusation — the driver argues with it, the manager cannot check it, and the number stops being used.
Chosen
Cameras and sensors on the vehicle, and the trip drawn as its actual route against the intended one. Every incident carries its time and stills from the cabin, front and rear, so an accident can be reconstructed afterwards and the footage carries the insurance claim. The same channel surfaces what a manager could never otherwise see — drinking, smoking at the wheel, driving past the permitted hours — as events with evidence attached rather than as a figure to be argued about.
Rejected, and why
Nothing was weighed against this one, and it would be tidier to pretend otherwise. The tracking, the telemetry and the three portals already existed, so the question was never which approach to take — it was how far the platform should reach. Having the whole system in place, the answer was as far as the vehicle itself. The cameras and sensors were the reach, not the choice.
06 — The work
04 screens
desktopScreen name — what it does, and the decision it reflects
07
What happened
Knock-on effects
- A pump is visible for its whole life instead of disappearing at the factory gate, and the manufacturer is told directly when one of its own is near end of life
- Service started arriving on time, which was the thing the manufacturer built this for — and pump sales rose with it
- An owner can answer at a glance what a fleet of one to two thousand vehicles made impossible by hand — what is owed in fines, what expires this month, which Fastags are empty. Their operations became organised
- An accident has evidence attached to it, which is what a claim runs on
08
In hindsight
I’d do differently
- I thought about literacy for the driver app and stopped there. Owners and managers in this sector are deeply experienced people, but not necessarily educated ones, and I designed their portals as though they would read them. Given it again I would carry that thinking up through the whole product instead of treating it as the driver’s problem — make managing the same things simpler everywhere, not just at the bottom
What it taught me
- To think region by region, and about who the user actually is rather than who a persona says they are
- To make one screen work for a reader and a non-reader at the same time. The easy answer is a simpler version for one of them; the better one is a single screen neither has to be taught
Next — 03