FleetTracker
2023
SmartCow
AIoT Device Management Platform
Project Goals
Transform manual device management into a scalable, automated platform
Reduce deployment time from days to hours
Enable secure over-the-air updates for large device fleets
My Role & Impact
Led product design and information architecture
Resolved critical UX challenges for managing 1000+ devices
Process Highlights
Conducted user research across 3 enterprise clients
Delivered MVP in 3 months, V1 in 6 months
Currently leading V2 redesign
Key Product Outcomes
Successfully deployed to 5+ enterprise clients
Managing 1000+ devices in production
Project Overview
FleetTrackr is an AIoT Device Management Platform. The platform enables administrators to provision, manage, monitor, and update thousands of devices, securely and entirely over-the-air. It offers simplified deployment and centralized management of edge AI systems through a hybrid-cloud service.
Design Stage time frame
6-9 months & ongoing
Role
Product Designer - Information Architecture & Product Design
Team
2 Designers, 2 Frontend Developers, 5 Backend Developers, 1 Product Manager
Project Catalyst
FleetTrackr's journey began with a crucial observation from our client work. One of our enterprise clients had successfully deployed our edge AI devices but faced a growing challenge: as their device fleet expanded beyond 30 units, the manual management process became increasingly unworkable. What started as a client-specific problem revealed a broader market opportunity - the need for a scalable device management platform.
Business Opportunity Analysis
Working closely with our product team, we identified three key business objectives that would shape FleetTrackr's development:
Create a Comprehensive Ecosystem
FleetTrackr would be complementary with any purchase of hardware and as such made the total package more enticing to potential customers. The idea being that the customers are buying into an eco-system rather than an independent hardware solution and software solution.
Build Distribution Infrastructure
FleetTrackr would be a proprietary platform that we could use to execute updates to our solution applications and device firmware. The advantage is that we would control the platform (as opposed to a 3rd party IoT management system) and could optimize both the platform and applications/firmware for better customer experience.
Enable Data-Driven Improvements
As we work closely with our clients to develop FleetTrackr further, we will have access to the performance data of our devices the client will have deployed in the field, allowing us to highlight areas for improvement and opportunities for future product/services.
Initial Challenges
Technical Constraints
The scale of device management presented our first major hurdle. While our initial architecture could handle hundreds of devices, enterprise client interest pushed us to consider scenarios exceeding 1000 devices. This scale affected everything from backend infrastructure to user interface design.
Design Challenges
The core question became: How do we make managing 1000+ devices not just possible, but intuitive? This challenge manifested in several key areas:
Device organization and grouping
Batch operations and updates
Performance monitoring
Error handling and alerts
User permission management
Understanding Core Requirements
We leveraged our relationship with an existing client using our basic fleet management application to identify essential features. Through regular feedback sessions and usage monitoring, we documented their:
Daily management tasks
Common pain points
Feature requests
Workflow patterns
Leveraging Existing Knowledge
Our advantage lay in having real-world usage data from our client project.
This gave us:
Actual user behaviour patterns
Common error scenarios
Performance bottlenecks
Feature usage statistics
Initial information architecture
From grouping the user stories, we started to form the initial information architecture of our product.
The final UI of our MVP (not my work)
As mentioned before, my college handled the UI so after handing over my wireframes and IA we work to produce our MVP UI screens.
The “grouping” system was confusing to users with 3 distinct groups (Fleet, Software & Hardware) seeming related.
These groups were unrelated for back end reasons, it was not technically possible to link them - ie. have a Fleet Group also be used as a Hardware Update Group. This was quite an issue and the Product Management and Back End teams made this a priority to tackle
This feedback led us to explore 2 options:
Add more advanced ticket management features: including comments, files, priority levels, favourites and new statuses with a review process.
Add more advanced ticket management features: including comments, files, priority levels, favourites and new statuses with a review process.
Our MVP users informed us that the workflow within which our product was being used had multiple internal teams interact and collaborate with each other throughout.
Different teams needed different features from the product and our clients feedback was that they also wanted to limit / give access to some of the features to certain teams.
The workflows & the users
After our MVP launch, we recognized that understanding the complete user workflow was crucial for improvement. We conducted in-depth research with our clients to answer critical questions:
What is the fundamental workflow for device management?
How do internal teams collaborate throughout this workflow?
What are the essential touchpoints with our platform?
What are the specific goals for each user type?
These questions led us to dig into the internal workings of our clients. While we knew these findings could differ between companies / clients, we needed a starting point.
Along with the workflow research, we worked hard to generate as many user goals as possible, both from speaking directly to our clients and working with our hardware team to pre-empt some features that would be important in the future if not now.
The Core Version 1 Flows across teams
We mapped out the primary workflows that involved multiple teams collaborating toward common goals. This helped us understand:
Cross-team dependencies
Communication requirements
ccess control needs
Feature prioritization
The final UI of our Version 1 (Not my work)
As mentioned before, my college handled the UI so after handing over my wireframes and IA we work to produce our MVP UI screens.
Note
This section was added to the case study following its completion and as such, the rest of the study does not reflect the changes discussed below. These changes are “proposed” and are yet to be implemented in the production version of FleetTrackr, however I think they are still relevant and interesting.
Updating the primary user stories
Despite improvements in Version 1, user testing revealed ongoing challenges:
Group System Confusion: The three separate group types still caused confusion:
Device Groups
Application Groups
Firmware Groups
Users continued to:
Mix up group types
Struggle with similar terminology
Face difficulty understanding group relationships
Interface Redundancy: We identified several duplicated elements:
Similar list/grid views across pages
Repeated update manager interfaces
Redundant group management flows
Proposed Info Arch restructure
To address these issues, I proposed a significant restructure:
1. New Groups Page
Consolidates all group types into one location
Allows filtering by group type
Provides clear visual differentiation
Streamlines group management workflows
Unified Updates Page
Combines application and firmware updates
Creates single update management interface
Simplifies update scheduling
Improves update tracking
Version 2 UI Design Improvements
Alongside the structural changes shown in the wireframes above, there were also some requests for a polishing of the visual design as well as some quality of life improvements I wanted to implement. Some of these are highlighted in the following UI examples.
Note
Starting in late 2023, I took over as the sole designer on the project which included adding the UI Design to my existing responsibilities. The following designs are my up-to-date drafts.
Fleet Overview & Device Management UI Enhancements
Here the user can use a map or list view to view all the devices in the fleet. By filtering they can find specific devices types or devices with different status.
For these sections, there were quite a few chanegs:
Added advanced filtering capabilities
Created improved device status indicators
Developed detailed device overlay system
Real-time metric displays
Component temperature monitoring
Application status tracking
Improved alert system
Group Management
On the groups page, the user can create custom groups or sub-fleets that can be used for a variety of functions ranging from simply organising devices to applying mass updates or actions to all devices in the group.
Some of the improvements include:
Simplified group creation
Enhanced group organization tools
Improved group action controls
Better visualization of group relationships
Update Management
Streamlined update creation process
Enhanced scheduling capabilities
Improved status monitoring
Better error handling and reporting
Current Status and Future Plans
Ongoing Development
User Testing
Validate new information architecture
Test updated workflows
Gather feedback on new features
Implementation Planning
Creating detailed technical specifications
Planning phased rollout
Developing user training materials
Future Considerations
Scalability improvements
Additional enterprise features
Advanced analytics capabilities
My Key Learnings:
Structure Requires Iteration in Complex Products
Working on FleetTrackr revealed how even thorough initial research can't predict all user behaviour patterns in complex enterprise solutions. Our group system structure, which seemed logical in theory, created unexpected cognitive load for users in practice. The journey from MVP to Version 2 taught me that sometimes fundamental structural changes are necessary post-launch, and the willingness to make these changes based on user feedback is crucial for product success.
Translating User Goals into Product Structure is a Complex Challenge
Creating a coherent product structure that serves multiple user types proved to be one of our biggest challenges. With three distinct user groups, each with unique workflows and goals, we needed to design a system where features worked harmoniously while remaining intuitive for each user type. While our initial solution of role-based access helped with permissions, it didn't address the underlying structural challenges – a realization that ultimately led to our Version 2 redesign.
Technical Constraints Shape Design Solutions
Scaling from hundreds to thousands of devices showed how technical considerations fundamentally influence design decisions. Close collaboration with engineering teams from the early stages helped shape feasible solutions while revealing new possibilities for solving user problems. The challenge of managing large device fleets pushed us to think creatively about performance optimization and interaction patterns, resulting in solutions that balanced technical viability with user needs.
