2024

Designing a Controlled Notification Architecture for Multi-Source Fleet Ecosystems

Context
Fleet managers were drowning in alerts. Every trigger — from battery failures to routine maintenance logs — landed in the same undifferentiated feed. There was no way to tell a critical alert from a routine one, so managers either missed urgent updates or tuned out the feed entirely. My job was to bring order to a system with no existing hierarchy, no filtering logic, and no owner.

​

Project: Fleet Management Platform 
Role: UX Designer (Interaction Design) 
Focus Area: Notification enhancement 
Duration: 2.5 weeks 

The Challenge 

Fleet managers were experiencing "information overload," struggling to distinguish between routine updates and high-priority alerts. With no existing way to filter or manage the influx of data, critical vehicle notifications were frequently overlooked. The challenge was to design a sophisticated notification architecture that balanced high-volume data delivery with user control and visual clarity.

​

My Role 

As an Interaction Designer, describe about your role.

Back

Analysis of existing Notification trigger points: Interviewing experienced technical architect, we traced every notification trigger point across the platform, and ran a card sort with the PM and Tech Lead to group them by source and urgency — this gave us a shared model of what the system was actually sending, not just what it looked like on screen.

From there, I made three calls that shaped the rest of the work:

Categorize, don't just prioritize

Move the bell, not the mental model.

Delay the ask, protect the signal.

​

Categorize, don't just prioritize. Time-sensitive alerts stayed instant; everything else got batched into digest summaries, cutting noise without hiding information.

Move the bell, not the mental model. I relocated notifications from the tab bar to the app bar after benchmarking intranet and OS-level patterns (iOS, Android, Windows, macOS) — matching a convention users already carry with them, instead of teaching a new one.

Delay the ask, protect the signal. Instead of front-loading preference setup during onboarding, I introduced contextual tooltips after a user had seen a few notifications — so they understood what they were customizing before being asked to customize it. Critical alerts like battery failure stayed unskippable regardless of preference.

Empowering Notification Control: Research says 55% of users found notification overwhelm as a reason for primary digital detoxes and 71% users uninstall apps due to excessive alerts.

Keeping that in mind we implemented granular user controls where users can now customize notification types, channels, and frequency (instant, daily/weekly digest), while ensuring critical alerts, like battery charge failures, remain unskippable.

​

Reusable Component Design: To keep this sustainable past launch, I designed the notification module as a single reusable component rather than a set of one-off variants, and documented floating notification behavior separately for iOS and Android since the two platforms don't share the same rules. I handed this off with full navigation flows and UI specs, written so PMs, BAs, and QA could use the same reference without re-explaining the logic to each team.

Streamlined Developer Handoff: Handoff documentation closed the design-to-dev communication gaps, giving four teams (Dev, BA, PM, QA) a single source of truth instead of four separate conversations.

Action