UX decisions in real-time vehicle tracking

A vehicle-tracking product looks like a map with dots on it. The dots are the easy part. The product is every decision about what a dot means, when it changes, and what a person watching ten thousand of them is supposed to do next. These are the decisions I made on the fleet and telematics platforms at MapMyIndia, and why.

A vehicle is in one of five states, and the product says which

Moving, stopped, idle, delayed, offline. Before those five were defined, a dot was just a position with a timestamp, and every screen interpreted it differently. Defining the states once, and drawing the line between “stopped” and “idle” and between “idle” and “offline”, gave the map, the alerts, the trip views and the compliance reports one vocabulary. An operator who learns it on the map recognises it in the alarm list. Most of the hard questions in the product were really questions about where those lines sit, and having them in one place means the question gets answered once.

The map turns with the vehicle, not the other way round

Rotation, fit-to-route and route playback sound like map features. They are attention features. Rotating the map to the heading means the operator does not translate “north” into “left”; fit-to-route means one action shows the whole trip instead of a hunt across the screen; playback means a dispute about where a vehicle was at 14:20 is settled by watching, not by reading a table. Each one removes a step a human was doing in their head, and at fleet scale those steps are the whole day.

Alarms, geofences and tickets are one workflow, not three features

An alarm nobody acts on is noise. The alarm, geofence and ticketing workflows were designed as one chain: a geofence defines the condition, an alarm says it happened, a ticket says who owns it now. Splitting them into three separate features, which is how they arrive in a requirements list, produces alerts that fire and go nowhere. Designing the hand-off between them is the product work.

Ten thousand dots is a rendering problem before it is a UX problem

Vahan Shakti draws live positions for a very large fleet; Intouch is optimised for ten thousand active vehicles with headroom to fifty thousand. At those numbers the map cannot draw every marker every second. Clustering, heatmaps and custom markers are not visual flourishes. They are what makes the screen readable at all, and they change what an operator can see: patterns instead of pins. The same is true under the hood: the ~40% improvement on the data-heavy dashboards came from caching, RxJS state management and API optimisation, and a dashboard that renders in time is a UX decision as much as an engineering one.

What I would still measure

How long an operator takes to find one vehicle in a fleet of thousands; how many alarms end as closed tickets rather than dismissed noise; how often route playback settles a dispute. The product exists to shorten the first and raise the second. Those are the numbers I would put in front of the next version.