Fleet operations, redesigned for faster decisions.

Project context

The client operates a fleet supporting day-to-day service and delivery operations. Fleet managers use a mobile product to monitor vehicles, drivers, trips, and operational exceptions.

The engagement was conducted under NDA, so names, visuals, and selected UI details have been modified for confidentiality.

My role

I owned the revamp of the core manager experience, reworking the flows, information architecture, and interaction patterns so managers could focus on what needs their attention.

• Overview — helping managers understand fleet health and what needs attention.
• Fleet — making vehicle states easier to scan.
• Alerts — restructuring how issues are surfaced, prioritized, and acted upon.
• Trips — improving visibility into active and upcoming operations.

Out of scope: job creation, alert-rule configuration, and threshold administration were not part of my assigned scope.

This case study focuses on the Alerts work: what reaches a manager, and how urgently.

The problem

Managers had visibility into the fleet, but not enough clarity on what required their attention, how urgently, and what to do next.

The existing two-level model handled obvious emergencies, but Warning was becoming a catch-all. Once Critical alerts were cleared, managers could still be left with unrelated Warning situations that did not require the same response.

A major route deviation, a trip delay threatening delivery, and a vehicle going offline before an upcoming trip could all sit under the same label — even though each called for a different level of attention.

From signals to actionable alert situations

Before redefining the alert experience, I mapped the broader signal space the fleet could surface. I did not assume every signal belonged in the alert layer; I first separated routine states and events from conditions that could warrant manager attention.

Signal universe — representative slice

A raw signal does not have to be an alert by itself. For example, Battery level is a state; a derived condition such as battery below the operational requirement is what can create a manager-facing alert situation.

Alert Matrix — the manager-facing bridge

The Alert Matrix was one of the first working artifacts I created. It helped turn the broader signal and event space into concrete manager-facing alert situations. I used a trigger → context → consequence → response structure to connect each situation to what the manager needed to decide or do.

The reconciled model keeps the manager-facing situation separate from the raw signal: context determines whether the situation is an alert and which priority it receives.

Making urgency meaningful

With the alert situations defined, I explored whether urgency could be represented as a response ladder rather than a single severity label. The initial hypothesis was three levels: Low / Monitor, High / Investigate, and Critical / Act now.

Initial priority hypothesis

At this stage, Low / Monitor was an exploratory label for lower-urgency situations; the later tests would determine whether it represented a useful distinction in manager response.

Boundary check: not every candidate should alert

Not every situation that looks noteworthy requires a manager response, so I also looked at a few contextual cases that should remain outside the alert experience.

• Offline parked vehicle, no upcoming trip → No manager action → Not an alert
• Minor route deviation, no meaningful impact → No manager action → Not an alert
• Low battery, comfortably sufficient for the trip → No manager action → Not an alert
• Vehicle offline before a trip in 2 hours → Potentially → Warning
• Vehicle offline before a trip in 10 min → Yes, investigate → High

These showed that some situations should remain outside the alert experience rather than being forced into a priority level.

The existing two-level model was too coarse

With those cases separated out, I then tested whether the existing Critical / Warning model could distinguish the situations that did require action. An AI-assisted first-pass analysis suggested that two levels could be sufficient, but I challenged it because Warning could still combine situations with materially different expected responses.

FindingWarning was doing two different jobs: “investigate soon” and “follow up”. A separate High level created a meaningful response distinction.

Did a fourth level add value?

I also checked whether adding another level created a meaningful difference in manager response. It did not. Beyond three levels, the distinctions became harder to translate into a clear action or response time.

Stress-testing the three-level model

With the three-level model retained, I stress-tested it across contextual variants. The same operational situation could move from routine status to Warning, High, or Critical as context and consequence changed.

Across these contextual variants, the model held together: routine conditions could stay outside the alert layer, while the remaining situations separated into distinct response needs. That gave me a coherent decision model to check one final time across a compact set of representative alert situations.

Final scenario-based design evaluation

With the model holding across contextual variants, I ran a final scenario-based evaluation. I compared representative alert situations against the manager response each situation called for, then used a broader 10-alert pass to check whether those distinctions remained consistent across a compact set of situations.

10 representative situations — grouped by the response the model calls for

The model was coherent enough to carry into the app: the priority levels represented meaningful differences in expected manager response, rather than three visual categories. I then used that response framework to shape the alert list, detail, and lifecycle.

Turning the model into the alert experience

Once the decision model was coherent, I carried the logic into the manager-facing screens. The interface decisions were guided by the job each surface needed to support.

Alert card — built for triage

The card is designed for triage, not investigation. It gives the manager enough information to understand what happened, identify the vehicle, assess urgency, and determine what needs attention first. Detailed location information, event history, and further investigation context remain in the alert detail screen.

Alert detail — built for investigation and action

Opening an alert shifts the task from quick triage to understanding the issue and deciding what to do next. I structured the detail view around three needs:

• Understand the situationI brought the alert explanation together with its operational context, helping the manager understand what happened and how it relates to the vehicle’s current trip or activity.
• Investigate with supporting contextI included location, recent events, and related driver or vehicle information to give the manager a clearer picture of the circumstances surrounding the alert.
• Take the next stepI tailored the primary action to the alert type. For a vehicle-offline alert, the primary action was to contact the driver; for a route-deviation alert, it was to view the trip or route. This connected the information in the detail screen to a relevant next step.

Alert lifecycle

An alert doesn’t end when a manager sees it. I separated acknowledgement from resolution so the system could record that an alert had been reviewed without implying that the underlying issue was fixed.

• ActiveThe alert still requires attention.
• AcknowledgedA manager has reviewed it, but the underlying issue may still exist.
• ResolvedThe issue has been addressed or is no longer active.

The alert card reflects the lifecycle state while retaining useful operational context, such as whether the vehicle is on an active trip. This helps managers understand both the alert’s status and the situation around it.

Design outcome

I refined the existing alert experience so that urgency, supporting context, and alert status each play a distinct role in helping managers understand and respond to operational issues.

• A more meaningful priority modelThe existing Critical / Warning model grouped situations that called for different responses. I introduced High as a distinct middle level, differentiating between acting immediately, investigating soon, and following up or monitoring.
• A focused path from triage to investigationI kept the alert card focused on communicating the issue and its urgency at a glance. The detail view provides the additional context needed to investigate, with the primary action tailored to the type of issue.
• A clear split between review and resolutionI defined Active, Acknowledged, and Resolved as distinct lifecycle states. Acknowledgement records that a manager has reviewed an alert without implying that the underlying issue is fixed. The alert list retains this status alongside relevant operational context.

Together, these decisions help managers see what matters, judge how urgently to act, and follow each alert through to resolution.

Reflection

Designing for decisions, not just information

Working on the alert system shifted my approach to operational interfaces. The challenge wasn’t to surface more information, but to decide which situations deserved attention, how context changed their importance, and what response each priority should imply.

Testing the model across contextual scenarios reinforced that a priority level only earns its place when it changes what the manager should do next. The lesson I’ll carry into future projects:

A good operational interface shouldn’t just report what’s happening; it should help people understand why it matters and what to do next.

Thanks for reading

If you’d like to talk about this project or work together, I’d love to hear from you.

• Email
• Portfolio
• LinkedIn