The Problem

The design challenge was clear:

How might we help fleet operations managers identify and act on vehicle risk before failures occur — without increasing the cognitive load of an already data-heavy role?

This led to three design requirements:

A single risk signal. One number that aggregates vehicle health across multiple data points, so priority is immediately clear without interpretation.

A structured triage workflow. Detection, understanding, and action need to be one connected flow — not separate tools that force the manager to do the connective work.

Context at every step. Every screen should answer not just "what" but "so what" — what does this mean, and what should I do next.

The User

The primary user is a Fleet Operations Manager responsible for monitoring around 100–150 vehicles across multiple regions.

Their job isn't to interpret raw telemetry — it's to make fast, informed decisions based on system data. Every morning they're asking three questions: what's urgent right now, which vehicles need action today, and what do I need to schedule this week. They need a system that does the synthesis for them — presenting conclusions, not numbers.

Key characteristics:

• High decision frequency, limited decision time

• Accountable for both operational continuity and cost outcomes

• Not a technical user — needs context and direction, not raw metrics

• Works across multiple tools and communication channels simultaneously

The Solution

Fleetora translates vehicle telemetry into a prioritized risk hierarchy. Rather than overwhelming users with raw metrics, it surfaces what matters most — and connects detection directly to action.

The platform is built around a single core workflow: see what's at risk → understand why → schedule service. Every screen exists to advance that loop. Navigation reflects the natural order of a manager's day, but each page is fully self-contained — because real usage is non-linear and every entry point needs to work independently.

Key Concept - Risk Score

The Fleet Risk Score is the conceptual centre of Fleetora. It addresses a central design hypothesis: fleet managers need a clear way to prioritize vehicle risks without manually interpreting multiple health metrics.

Each vehicle receives a score from 0 to 100, calculated from a weighted combination of health metrics: oil and fluid levels (25%), brake and battery health (30%), engine temperature (20%), mileage since last service (15%), and route intensity (10%).

Scores for overall fleet health fall into three zones: Low (0–33), Moderate (34–66), and High (67–100).

Individual vehicle and component scores are mapped to four severity states: Healthy (0–40), Predictive (41–60), Warning (61–79), and Critical (80–100). These labels appear consistently throughout the product, creating a shared language for communicating risk across different views.

At the fleet level, the score is calculated as the mean of all vehicle scores, providing a single indicator of overall fleet condition.

Design assumption and validation

The scoring weights and thresholds are illustrative, developed to explore how a unified risk indicator could support prioritization. They are not based on a validated predictive model. In a production environment, the scoring logic would need to be defined and tested with fleet operations experts, real vehicle data, and appropriate domain-specific risk criteria.

From a UX perspective, the challenge was to make the score useful without allowing it to become an unexplained number. That's why the interface connects each risk indicator to supporting vehicle health information and a clear next action.

Instead of asking users to interpret every metric independently, Fleetora helps them answer a more immediate question: Which vehicle needs attention first, and why?

Dashboard

A real-time overview organized around the manager's morning question. Stat cards, a fleet health distribution bar, a critical alerts strip, live fleet status, a 7-day risk trend, and weekly alert activity — each answering a distinct part of the picture without overlapping.

Explore the live prototype here

Fleet List

All vehicles sorted by risk score by default. A subtle left-border accent marks Critical rows so severity is scannable before reading any badge. Quick actions include both View and Plan for vehicles at actionable severity levels.

Vehicle Details

Three columns: vehicle metadata, risk score and analysis, health metrics. The risk score is displayed as a semicircular gauge with zone markers and a 7-day trend. Four health metrics on the right — Oil, Battery, Brake, Engine — each show current reading, trend, and a plain-language interpretation of what it means operationally.

Alerts Log

Active and Resolved as tabs, defaulting to Active, sorted by date. The full description column distinguishes this page from the compact alert strip on the dashboard. The summary chips include the Fleet Risk Score as context alongside the severity counts.

Service Planner

A weekly calendar where rows are vehicles and events are scheduled services. Severity is readable across the calendar at a glance from the left-border accent on each event. Two modal interactions — Add Service (2nd screen) and Service Info (3rd screen).

Map

Vehicle positions as callout bubbles with severity-colored anchor dots. Clicking a pin opens a compact card with severity, risk score, driver, status, and region — the minimum needed to decide whether to act. A severity legend and vehicle count chip give context to what's visible in the current view.

Reflection

Fleetora taught me that clarity in a product almost always comes from subtraction.

The decisions I'm most confident in aren't the features I added — they're the ones I didn't. Keeping the dashboard focused on a single question, separating active from resolved alerts rather than filtering them, defaulting to risk-based sorting rather than leaving that choice to the user. Each of these is a small structural decision that shapes how the product behaves before the manager makes any choice at all.

Working across six interconnected pages also reinforced how much consistency depends on underlying logic rather than visual similarity. The tinted badge, the filter chip, the modal structure — these aren't aesthetic choices. They're decisions that, once made, scale across the product without needing to be re-made. A manager who learns the system on the dashboard already understands it on the Fleet List, the Alerts Log, and the Service Planner. That transferability is what makes a product feel coherent rather than just well-designed.

As a concept project, Fleetora also highlighted the importance of validating the assumptions behind a data-driven interface. In a real product, I would want to test whether fleet managers understand the risk indicators, trust the information behind them, and can move from identifying an issue to scheduling maintenance without unnecessary friction. The next step would be to validate these workflows with real users and refine the scoring model with domain experts.

From Structure to Interface

Early wireframes were used to define layout, information hierarchy, and how data should be prioritized across the system — before any visual decisions were made.

User Journey

This journey maps how a fleet operations manager moves from an initial risk signal to a scheduled service — from the first alert on the dashboard, through investigation in Vehicle Details, to a confirmed appointment in the Service Planner.

User Flow

This flow illustrates how Fleetora guides users from risk detection to maintenance scheduling through a structured, low-friction process.

Information Architecture

The platform is structured around six views, each serving a distinct role in the manager's decision workflow:

Dashboard — fleet-wide health at a glance. The start of every morning.
Fleet List — all vehicles ranked by risk, filterable and sortable. For triage at scale.
Vehicle Details — the complete picture of one vehicle. For understanding before acting.
Alerts Log — every active issue, organized by severity and date. For systematic triage.
Service Planner — a weekly calendar of scheduled maintenance. For planning ahead.
Map — geographic positions with severity indicators. For spatial awareness.

The navigation order mirrors the natural flow of a manager's day — overview first, then drill down, then act. Each page is also fully functional as a standalone entry point.

Key Design Decisions

The dashboard as a question, not a summary

I designed the dashboard around one question: Do I need to change my plans for today?

Rather than displaying every available metric, I gave each section a distinct purpose. Summary cards communicate fleet status, the health distribution shows the scale of risk, critical alerts highlight immediate priorities, and trend charts provide context over time.

Information that didn't contribute a distinct answer was kept in its dedicated view, reducing duplication and helping the dashboard remain focused.

Color as a system

I reserved four colors for the severity states: Critical, Warning, Predictive, and Healthy.

These meanings remain consistent across badges, charts, calendar events, map indicators, and other relevant components. Neutral colors support the rest of the interface, so severity colors retain their significance.

Color is also supported by labels and contextual information rather than acting as the only indicator of risk.

Separating active and resolved alerts

I separated Active and Resolved alerts into dedicated tabs, with Active selected by default.

This keeps the primary view focused on issues requiring attention, while preserving access to historical information when needed. It also avoids making users repeatedly filter out completed issues.

Making prioritization the default

The Fleet List is sorted by risk score, highest first.

This was a deliberate interaction decision: the system should help users identify priorities immediately rather than presenting an arbitrary list and requiring them to organize it themselves.

Users can still explore the fleet, but the default state reflects the product's primary purpose.

Connecting detection to action

Identifying a risk is only useful if the user can act on it.

I made Plan Service accessible from multiple relevant entry points, including the Fleet List, Alerts Log, Vehicle Details, and Map.

The scheduling interaction carries vehicle context into the next step, reducing repetitive input and connecting risk detection directly to maintenance planning.

Together, these decisions support the same principle: reduce interpretation, make priorities visible, and help users move from information to action.

From an Open-Ended Problem to a Focused Workflow

Fleet risk management involves multiple types of information: vehicle health, alerts, maintenance history, and operational schedules. The initial design challenge was not simply how to display this information, but how to help a fleet manager decide what deserves attention first.

I approached the problem by identifying three decisions the interface needed to support: which vehicles are at risk, what is driving that risk, and what action should follow.

This led me to focus the experience on one connected workflow: identify risk → understand the cause → schedule service.

Rather than treating dashboards, alerts, and maintenance planning as separate features, I designed them as interconnected parts of the same decision-making process. This became the foundation for the product's information architecture and interaction patterns.