FleetTracker
2023
SmartCow
AIoT Device Management Platform
Introduction
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 & on-going
(3 months upfront with multiple rounds of revisions and updates)
Project Type:
New Product MVP & V1
(Team Project) Product Design, UI Design
Myself and a colleague were the two designers involved in this project. My responsibilities we focused around working closely with the PMS, translating their requirements into product design, and an overarching information architecture. He focused on the final UI design.
Team
Design Team (2)
FE Dev Team (2)
BE Dev Team (5)
Product Management Team (1)
Seeing Opportunity
The origin of this product was the work done with a previous client who wanted a way to manage the system they had build using our products and solutions. When their fleet of devices was less than 30 or so, it was reasonable to edit and monitor device’s functionality and deployment, however, once the fleet began to reach a larger scale, our client needed a platform to fulfil this need.
And thus the idea to create a platform to allow user to manage our ecosystem of products and solutions was born.
Company Goals
Create a complementary packaged offering
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.
Provide a platform for future distribution of services
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.
Gather device performance insights post-deployment
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.
Challenges
Technical
A major issue that impacted the project was fleet scale (how many devices our software would track). Initially, the product was built for hundreds, however, with interest from larger clients it became clear the device count could exceed 1000 for many applications.
This created some challenges from a BE/infrastructure point of view but also needed consideration from the UX team.
Design
How do we ensure our users experience managing a huge fleets of 1000+ devices is intuitive, smooth and most importantly, effective?
This was a question the design would need to tackle particularly when it came to times where actions would need to be applied to a large collection of devices.
Understanding the “must haves”
With good access to an existing customer, who was actively using a very basic version of a Fleet Management application our dev team built, we set about discovering the core functionality that would be foundational to the whole product.
We already knew much of the basic features that would be needed but continued to dig deeper in into the clients needs, workflows and future plans.
Building on existing knowledge & experience
As mentioned before, the FleetTrackr project was initiated as a offshoot, standardised version of an on-going client project.
As such, much of the feedback our team (BE implementation to UI feedback) on the client receives from our Client Project is invaluable for advancing the FleetTrackr project.
This, alongside direct user testing on the FleetTrackr project, form the main research data used in updates and future features planned for implementation.
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. (Image 0.0)
These groups were un-related for back end reasons, it was not technically possible to link them - ie. have a Fleet Group also be used in 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
As found from our initial MVP feedback, fundamental to understanding our users was understanding their workflow. We needed to answer some important questions:
What is the fundamental workflow?
How do the internal teams interact and collaborate with each other throughout the workflow?
What touch points with our product will each user need as part of this workflow?
What goals will each user have as part of this workflow?
What inputs will they need?
What tools / actions will they need?
What output will they generate?
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 would be important in the future if not now.
The Core Version 1 Flows across teams
Our MVP was a single UI that had ony one level of access. After researching the clients team structure as well as the workflow / relationships between each, we set about understanding the specific flows that would see multiple different user sets collaborating together to reach an end goal.
We needed to understand how the teams interacted with each other and what product touch points were present during each flow.
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 much work in Version 1 to alleviate the confusion caused by the “Groups” following the MVP testing, in V1 we also found that this was an issue, even with user who had been given walkthroughs of the application and specifically the features using groups.
Device Groups
Application Groups
Firmware Groups
However, the similarities in visual design & terminology of these flows led to user s either thinking all groups were the same or mixing up the 3.
The duplications make up a large amount of the IA of the first three main pages with sections dedicated to displaying the Groups in list/grid views as well as the update manager being present on two of the pages (Application & Firmware). To add to this, the flows for Creating, Editing and Updating groups are also duplicated.
Proposed Info Arch restructure
The proposed new IA tackles this by adjusting the navigation structure.
Groups Page: This new page moves all the groups to one page. On this page, the groups can be separated into the 3 distinct sets, or displayed all together. The flows for Creating, Editing and Updating the groups all have their start-points on this page too.
Updates Page: This combines the Application and Firmware pages into a single page where the type of Update will be dictated by the groups chosen to apply the update to. Also, the update manager will be accessible here too.
Version 2 UI Design (WIP)
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 and Device overlays
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.
The overlay shows the live metrics for a specific device including component temps and status as well as the applications running on device.
Groups Page
On the groups page, the user can create custom groups or sub-fleets that can used for a variety of functions ranging from simply organising devices to applying mass updates or actions to all devices in the group.
Updates Page - creating a new update
On this page the user can follow the steps to create a new update. They can select groups, add the update details and schedule the update either for immediate action or to take place at a specific time and date.
Updates Page - managing updates
In the update Queue, the user can see all future, current and past updates. From here they can monitor the status of updates, see any issues tht may have occurred or scroll back through previous updates.
Whats next
As of writing this case study we are currently working on the Version 2 Design. The proposed restructure of the product is quite a substantial update and so this version’s review & handover process is slower and more methodical.
We are planning to do in-depth user testing of the new changes before handover to ensure the big change is worth it.
My Key Learnings:
When working on complex products, structure is fundamental but often require interations.
Carrying on from the previous point, no matter how much research and testing you do, with such complex products, having an open mind and getting the latest version in users hands is one of the best ways to learn what is working and what is not.
Sometimes, what is not working may be the fundamental structure of the product as opposed to UI layouts or elements.
This can be a bitter pill to swallow, leading to big changes, but trial and error is often required.
With complex products, turning user goals into a product structure is a difficult task.
With 3 different users, a variety of goals and possible outputs, and a range of functionality needed, this project really made it clear how incredibly difficult it is to create an intuitive product structure.
