top of page

2024

Designing a Controlled Notification Architecture for Multi-Source Fleet Ecosystems

Reducing notification fatigue while helping users focus on what matters most

A leading truck and bus manufacturer wanted to improve how notifications were managed within its fleet management platform. As the platform grew, notifications started arriving from multiple systems and vehicles, making it harder for fleet managers to distinguish critical alerts from routine updates. The opportunity was to create a notification experience that improved visibility, reduced information overload, and gave users more control over how and when they receive updates.


This project focused on transforming notifications from a simple alert list into a more structured and manageable communication system.

Project: Fleet Management Platform 
Role: UX Designer (Interaction Design) 
Focus Area: Fleet Vehicle Details Experience 
Duration: 2.5 weeks

The Challenge

Fleet managers were receiving a high volume of notifications from multiple sources, making it difficult to identify critical events quickly. Key challenges included:

  • Notification overload

  • Missed high-priority alerts

  • Limited control over notification preferences

  • Lack of clear prioritization

 

The goal was to balance visibility, relevance, and user control without compromising critical safety communication.

How it started

Understanding the Notification Landscape

Conversations with technical architects and product teams helped uncover the various notification trigger points across the ecosystem.
A card-sorting exercise helped organize these triggers into meaningful categories, creating a foundation for a more structured notification framework.

SUB HEAD

Where to start? - Strategy & Rapid Execution

With a high-stakes, two-week deadline, we chose a "Music App" concept to demonstrate the system's versatility across Web, Native, and HMI platforms.

Research Data Gathering.webp

Caption text

Organizing Notifications by Purpose

Not every notification requires immediate attention.
Notifications were categorized based on urgency and actionability:

  • Critical Alerts

  • Operational Updates

  • Informational Messages

  • System Notifications

 

To reduce interruptions, less urgent updates were grouped into digest-style summaries.

Notification Architecture.webp

For non-time-sensitive alerts, we implemented a batching technique

to consolidate them into a single, digestible summary, reducing notification fatigue.

SUB HEAD

Building the base variable/token architecture

The backbone of this project was the token strategy, and multi-brand with device scalability was the key challenge. On researching and studying the big companies design system and their structure,  I tried to performed the below activities with team in establishing the base variable-token architecture.

Exploring Notification Patterns

Research across iOS, Android, desktop platforms, and commonly used applications revealed how different products communicate notifications. Understanding these patterns helped create an experience that felt familiar while remaining consistent with the fleet platform.

Analysis-Notification-Properties.webp

iOS and Android floating notification pattern study

SUB HEAD

Building the base variable/token architecture

The backbone of this project was the token strategy, and multi-brand with device scalability was the key challenge. On researching and studying the big companies design system and their structure,  I tried to performed the below activities with team in establishing the base variable-token architecture.

Research.webp

iOS and Android notification pattern study

Analysis-Notification-Properties.webp

Rethinking Notification Placement

The existing notification access point was located within the bottom navigation. Moving notifications to a bell icon in the app bar aligned better with common application patterns and made alerts easier to discover.

Bell-icon-position.webp

Notification bell placement study

Analysis-Notification-Properties.webp

SUB HEAD

Building the base variable/token architecture

The backbone of this project was the token strategy, and multi-brand with device scalability was the key challenge. On researching and studying the big companies design system and their structure,  I tried to performed the below activities with team in establishing the base variable-token architecture.

SUB HEAD

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.

 

A notification settings experience was introduced to allow users to customize:

Notification categories, Delivery channels, and Delivery frequency (Instant, Daily, Weekly).

Critical vehicle and safety alerts remained mandatory to ensure they could not be missed.

Notification-Flow.webp

Enhanced notification feature

SUB HEAD

Building the base variable/token architecture

The backbone of this project was the token strategy, and multi-brand with device scalability was the key challenge. On researching and studying the big companies design system and their structure,  I tried to performed the below activities with team in establishing the base variable-token architecture.

Notification behaviour.webp

Floating notification behavior guidelines for developer

SUB HEAD

Building the base variable/token architecture

The backbone of this project was the token strategy, and multi-brand with device scalability was the key challenge. On researching and studying the big companies design system and their structure,  I tried to performed the below activities with team in establishing the base variable-token architecture.

Communicating Notification Preferences

Instead of requesting notification preferences during onboarding (Option 1), controls were introduced after users had experienced a few notifications (Option 2). Providing context first helped users better understand the value of customization and made the settings easier to discover.

First-Time-User.webp

Notification preference setup design explorations

SUB HEAD

Building the base variable/token architecture

The backbone of this project was the token strategy, and multi-brand with device scalability was the key challenge. On researching and studying the big companies design system and their structure,  I tried to performed the below activities with team in establishing the base variable-token architecture.

Designing for Reuse

Reusable notification components and lightweight documentation helped establish a consistent pattern across the platform. This simplified future enhancements while reducing design and development effort.

SUB HEAD

Building the base variable/token architecture

The backbone of this project was the token strategy, and multi-brand with device scalability was the key challenge. On researching and studying the big companies design system and their structure,  I tried to performed the below activities with team in establishing the base variable-token architecture.

Caption text

SUB HEAD

Additionally, created detailed documentation outlining floating notification patterns for both iOS and Android.

SUB HEAD

Building the base variable/token architecture

The backbone of this project was the token strategy, and multi-brand with device scalability was the key challenge. On researching and studying the big companies design system and their structure,  I tried to performed the below activities with team in establishing the base variable-token architecture.

Caption text

Supporting Development

Detailed interaction flows, specifications, and annotations provided a shared reference for developers, product managers, business analysts, and QA teams.
This helped reduce ambiguity and improved implementation consistency.

SUB HEAD

Building the base variable/token architecture

The backbone of this project was the token strategy, and multi-brand with device scalability was the key challenge. On researching and studying the big companies design system and their structure,  I tried to performed the below activities with team in establishing the base variable-token architecture.

Dev-Handoff.webp

Caption text

​As this is still under development, we don't have analytical data yet.

The proposed notification architecture helped:

  • Improve visibility of critical alerts

  • Reduce notification fatigue

  • Provide greater user control

  • Create a scalable notification framework

  • Improve overall communication across the platform

 

Most importantly, notifications evolved from a source of distraction into a more focused and actionable experience.

Outcome

Future enhancements could leverage Generative AI to summarize large volumes of alerts into concise, prioritized insights, helping fleet managers focus on the most important actions and events.

What's Next? — AI-Powered Notification Summaries

  • Not All Notifications Are Equal: Grouping notifications by urgency helps users focus on what matters most.

  • Placement Influences Behavior: Small placement decisions can significantly impact discoverability and usability.

  • User Control Builds Trust: Giving users flexibility over notification preferences helps reduce fatigue and improve engagement.

  • Simplicity Scales Better: Reusable patterns are easier to maintain, document, and expand.

  • Context Improves Adoption: Users are more likely to engage with notification settings when they understand their value.

Key Learnings

bottom of page