FleetTracker

2023

SmartCow

AIoT Device Management Platform

Web App

Product Design

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.

Company Goals

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.

Solid foundations

Solid foundations

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.

Building a structure

Building a structure

Initial information architecture

From grouping the user stories, we started to form the initial information architecture of our product.

MVP (Launched in Q1 2023)

MVP (Launched in Q1 2023)

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)

MVP: Key Learnings

MVP: Key Learnings

The “grouping” system was confusing to user with 3 distinct groups (Fleet, Software & Hardware) seeming related.

The “grouping” system was confusing to user with 3 distinct groups (Fleet, Software & Hardware) seeming related.

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.

Users like the ticket system but wanted more functionality.

Users like the ticket system but wanted more functionality.

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 clients wanted a way to limit access of certain features to certain user.

Our clients wanted a way to limit access of certain features to certain user.

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.

Version 1 Update (Live version as of Q2 2023)

Version 1 Update (Live version as of Q2 2023)

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?

  • Led the hiring and formation of a design team, built team rituals and processes.

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.

Version 2 Update (Currently in the design stage)

Version 2 Update (Currently in the design stage)

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.

Conclusion

Conclusion

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.

Thanks for reading, check out more of my work

Thanks for reading, check out more of my work

Sphinx

Sphinx

tldr

Tool for controlling Sphinx range of smart cameras.

Tool for controlling Sphinx range of smart cameras.

Web App

Web App

Product Design

Product Design

Reach out and connect.

Interested to know more or think we could work together?

Reach out and connect.

Interested to know more or think we could work together?

Reach out and connect.

Interested to know more or think we could work together?