The modules existed but the system did not. Collision avoidance, alcohol testing, fuel and load monitoring each reported separately, so a driver had device feedback rather than a picture of his own trip — and a fleet manager had five data streams rather than a fleet.
The behaviour the hardware detects is common enough to be normal. Unsafe driving, fatigue behind the wheel and skipped alcohol checks are not rare edge cases in this fleet — they are close to the baseline, which is why the interface could not treat any of them as an occasional alert.
Nothing was laid out for a screen mounted in a moving vehicle. Targets sized for a desk are not targets you can hit over a pothole, and alerts that need reading are alerts that get ignored at speed.
Sensor positions were fixed before design began. A camera on the mirror, the screen on the dash, the breathalyser within reach of the wheel, load sensors in the bed, proximity sensors on four sides. The interface had to work with where the hardware already was.
Too much information with no order of precedence. Drowsiness, a close call, a fuel reading and a load discrepancy arrived with equal weight, which in practice means none of them arrive at all.
Designed against the gap in the category, not the category
Every serious competitor — Samsara, Verizon Connect, Geotab, Fleet Complete, FleetX — covers GPS, diagnostics and harsh-braking analytics. None covers alcohol or drowsiness natively. That gap is Starkenn’s entire proposition, so the design brief was not "build a fleet dashboard" but "make physiological state as legible as location". There are no established patterns for that, which is why the module set and the alert model were designed from first principles rather than borrowed from the incumbents.
Decided what became a module and what did not
My scope was composition rather than parameters: which capabilities merged, which stayed separate, what each needed to show. Five modules was the answer — driver monitoring, collision avoidance, breathalyser, load, fuel — arrived at by asking what a driver would act on differently. Drowsiness and distraction sit together under DMS because both mean the same thing to a driver: stop. Fuel theft and mileage sit together because both are questions the fleet owner asks, not the driver.
Ordered the flow by when it matters, not by hierarchy
Login, dashboard, slide to start, breathalyser, trip. The sequence follows the driver’s morning rather than the system’s architecture, which is why the alcohol test sits between intending to drive and actually moving instead of in a settings menu. It is the only moment at which the test can do anything.
Made severity legible without reading
Alerts are colour-coded high, medium and low — but colour alone assumes a driver can distinguish red from orange through a windscreen in direct sun. So severity also drives flicker rate: the higher the severity, the faster the pulse, with intensity adjustable in settings. Motion reads peripherally in a way colour does not, and it requires no literacy at all.
Drew six pictograms and borrowed the rest
Drowsiness, object too close, collision, low fuel, over-speeding, engine overheat — six domain concepts with no adequate existing icon, drawn as vehicle-side pictograms rather than abstract symbols. Everything generic came from IBM Carbon. Same philosophy as the other two products in this portfolio: buy the parts that are solved, spend the time on the parts that are not.
Used colour saturation to carry device state
On the All Devices screen an active module is fully saturated and an inactive one is flat grey — the module icon itself is the status indicator, rather than a badge attached to it. A driver checking whether the load sensor is live should not have to read a label to find out.
Made the incident video the unit of evidence
Every logged alert carries a 40-second clip. A row saying "drowsiness, medium, 11 April" is a claim; the clip is the evidence, and it is what turns a disputed alert into a settled one. Designing the history views around video rather than around rows is what makes the system usable in a conversation between a fleet manager and a driver.
Kept one design language across opposite users
The driver HMI optimises for glanceability; the admin console optimises for density — device connection status, calibration dates, storage remaining, provisioning. Same components, same icon set, same severity language, inverted priorities. A support call about one screen should not require learning another.
Designed both ends of the day
Full light and dark treatments, not an inverted palette. Night driving is the higher-risk condition, so dark mode was designed first and checked for glare against an unlit cab rather than derived from the light one afterwards.
“Should a driver be able to override the ADAS on the screen?”
The straightforward answer is no. The entire purpose of the system is to intervene when a driver will not, and an override is a button that undoes the product. The breathalyser makes this concrete: fail it and the accelerator is cut and the administrator is notified.
I raised it anyway, because the opposite failure is worse than it looks. Sensors misread. A load cell mis-calibrates, a proximity warning fires on a roadside barrier, a breathalyser returns a false positive on a driver who has not been drinking. A system with no override does not merely inconvenience him — it strands a working vehicle and flags him to his employer on the strength of a bad reading. The five-test, four-to-pass threshold exists precisely because a single reading was not trusted enough to act on.
This was the client’s decision rather than mine; thresholds and interlock logic sat with their domain experts. My job was to make sure the question was asked before the screen was built, and that the interface had somewhere sensible to put the answer either way. Raising the failure mode nobody has priced yet is most of what design contributes on a safety system.
One in-cab interface where severity is carried by flicker rate as well as colour so it needs no reading, plus a customer platform and admin console reading the same telemetry at a different altitude.
The HMI unifies five previously separate hardware modules into one interface a driver can operate at speed, spanning login through trip completion, incident history and device health.
The engagement ran thirty days in March 2025. Mfable’s founder made the introduction; I led the work from that point — requirements with the client, module composition, user flows and interaction decisions — directing one designer on screen execution.
The redesigned HMI has since shipped to production vehicles, running on Starkenn’s installed hardware base of 2,500+ vehicles.
The wider platform work — customer portal, admin and super-admin consoles, mobile app — extended the same system outward from the cab to the people managing it.
Starkenn reports 500,000+ km driven in real-world fleet testing (10,000,000+ km across testing frameworks spanning commercial and mining operations), 50+ commercial fleets onboarded nationwide, 500+ safety-critical events mitigated, and 98% detection accuracy across the sensor-fusion and driver-monitoring stack. These are company-wide hardware and business metrics, not figures specific to this HMI redesign.
The platform holds 15+ patented innovations and 12+ IP filings spanning ADAS, ARAS and radar hardware, and is built toward India’s AIS 162 (Automatic Emergency Braking) and AIS 184 (Driver Drowsiness and Attention Warning) standards, plus DGMS mandates for mining safety.
All names, identifiers and figures shown in these screens are randomised dummy data. Any resemblance to a real company or product is for representational purposes only and implies no affiliation, endorsement or ownership.