TL;DR
Behind every dashboard is a hundred tiny product decisions⏳.This project is about making the right ones.
Type
Duration
Design focus
Context
OXRED is an enterprise platform that helps businesses monitor and manage electric vehicle fleets using real-time telemetry from IoT devices. While the initial scope was translating early product concepts into production-ready designs, the role quickly evolved into identifying workflow gaps, defining interaction patterns, and creating a consistent experience across 12+ interconnected modules.
The Business
As electric fleets continue to grow; from taxis and buses to commercial delivery vehicles; operators need to monitor far more than just a vehicle's location. Battery health, charging behaviour, trip history, maintenance schedules, alerts, efficiency and hundreds of other data points all influence how a fleet performs on a daily basis.
OXRED brings this complex vehicle telemetry into one unified operational platform.
Vehicle Telemetry
IoT devices continuously collect telemetry from every vehicle.
OXRED Platform
Complex telemetry is organised into dashboards, reports and workflows.
Operational Decisions
Fleet managers use these insights to monitor & optimize their operations.
Project Scope
The business had already identified the data available from its IoT devices and outlined the platform's modules. I started by translating these concepts into production-ready designs, but the role quickly evolved into defining workflows, resolving product ambiguities, identifying edge cases and creating a consistent experience across the platform.
MONTH 1 - PHASE STARTED WITH
Translate concepts in UI
MONTH 2 - ROLE EXPANDED INTO
A product-thinking partner to Engineering dept. & PM
01
Resolving workflow ambiguities
02
Identifying crucial product gaps
03
Improving information hierarchy
04
Designing consistently scalable patterns
MONTH 7 - ROLE CONVERGED TO
Maintaining consistency across the platform
The Challenge
Every module solved a different operational problem; vehicles, rides, maintenance, alerts, sustainability, finance and more. Each module also had its set of sub-modules which were also inter-related. While each workflow had unique requirements, the product still needed to feel like one coherent system.
12+ Core Modules
Covering every aspect of Fleet Operations
30+ Sub Modules
Purpose built views and workflows
1 Unified Platform
Consistent experience throughout
Rather than walking through every module, I've highlighted three product decisions that best represent how I approached ambiguity, scalability and operational usability across the platform.
Problem 1 : Scaling analytics for growing fleets.
The dashboards and the interactions were designed for tens. Fleets ship in hundreds. Several modules: Rides, Reports, Vehicle comparisons; let users select multiple vehicles at once. The pattern worked in prototypes with twelve trucks. It did not survive contact with a real 300-vehicle logistics fleet. So the problem was:
How do you select and compare hundreds of vehicles without punishing the manager or the browser?
Large Fleet
100s of vehicles
Selection becomes tedious
Analytics become expensive
What we observed?
Managers were selecting the same 8–10 vehicles every morning; one by one, from a list of 300. The interaction was correct for the demo dataset. It was wrong for the customer.
TL;DR - A pattern that doesn't scale, is a bug in production
Before drawing anything, we sat with the questions.
These are the trade-offs the design has to answer; before choosing a control, a modal, or a limit. Get these questions right and the interface almost designs itself.
How many vehicles should users compare at once?
Every fleet has a "shift" of 8–20. Beyond that, comparison stops being visual.
Should analytics support unlimited selections?
Or does "unlimited" quietly mean "unusable + slow"? And how do represent these selections?
How do we reduce repetitive selection?
Operators pick the same set daily. The product should remember what they mean.
Can exporting behave differently from visualisation?
Reporting wants completeness. The screen wants clarity.
Problem 1 : Solution
The Decision
Split the interaction into three deliberate paths.
Why three paths, not one? Each answers a different job; find fast, compare cleanly, report completely. Collapsing them into one control was the original bug.
Reduce search effort
Vehicle Groups & Classes
Persistent, user-defined subsets. Operators pick a group in one click, not fifteen.
Cap interactive comparison
Selection Limit
15 vehicle selection limit. Above that, comparisons stop being visual. Analytics stays responsive.
Separate export from view
Options in Export
Download selected vehicle data or download all vehicles data. Choice provided always.
Three decisions, visible in the interface.
Reduce search effort
Multiple Filters
Saved groups persist across modules. More filters, more accuracy; lesser selections.
Cap interactive comparison
Max. 15 Selections
Once the max. of 15 vehicles are selected, the rest of the vehicle selections get disabled.
Separate export from view
Download Options
Download selected vehicle data or download all vehicles data. Choice provided always.
"If you've reached till this point, we probably have a lot to discuss….