FleetTrackr

2023

SmartCow

FleetTrackr is an AIoT Device Management Platform.

UX

Product Design

Web App

Enterprise

B2B

FleetTrackr

2023

SmartCow

FleetTrackr is an AIoT Device Management Platform.

UX

Product Design

Web App

Enterprise

B2B

FleetTrackr

2023

SmartCow

FleetTrackr is an AIoT Device Management Platform.

UX

Product Design

Web App

Enterprise

B2B

Project Intro

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.

FleetTrackr enables IT departments to manage and scale edge AI deployments securely and remotely. These deployments are applicable to a wide range of use cases, ranging from retailers building intelligent stores to hospitals implementing AI to improve patient care.

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.

My responsibilities:

Problem Definition

Wireflows

Information Architecture

User Stories

User Definition

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 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.

Provide a platform for future distribution of services

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.

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/Obstacles

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

Understanding the “must haves”

With good access to an active 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 User Goals

Initial User Goals

See overview of Fleet

See overview of Fleet

See overview of Fleet

See device health metrics

See device health metrics

See device health metrics

Add, remove users manage access levels

Add, remove users manage access levels

Add, remove users manage access levels

Add new application to device/ multiple devices

Add new application to device/ multiple devices

Add new application to device/ multiple devices

Add new firmware to device/ multiple devices

Add new firmware to device/ multiple devices

Add new firmware to device/ multiple devices

See the status of all active applications

See the status of all active applications

See the status of all active applications

Create a backup of the SSD contents

Create a backup of the SSD contents

Create a backup of the SSD contents

Restore a SSD from backup

Restore a SSD from backup

Restore a SSD from backup

Be alerted of available firmware updates

Be alerted of available firmware updates

Be alerted of available firmware updates

MVP

(Launched in Q1 2023)

(Launched in Q1 2023)

Building an initial structure

From grouping the user goals and building on the existing basic version, we started to form the initial information architecture of our MVP.

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.

MVP: Key Learnings

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.

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.

Start researching the possibility of integrating our app with 3rd party ticket/task management software like Jira.

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

(Current live version as of Q2 2023)

(Current 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?

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 Flows across teams

Our MVP was a single UI that had only 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.

Restructuring V1

(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 core “Fleet” pages

The core “Applications” pages

The core “Tickets” pages

Version 2 Update

(Currently in the design stage)

(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 .

Restructuring V1

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.

By now, the back end issues around grouping devices had been somewhat delt with, although there were still some limitations and so we could begin trying to solve this problem.

My responsibility was to find how we could reorganise our product structure to overcome the confusion.

Proposed Info Arch restructure

As per the current structure, there are 3 distinct sets of groups each used in 3 different unique user flows:

  • 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.

Original Information Architecture

Proposed Information Architecture

  1. 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.

  1. 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 mentioned 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 page 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 that may have occurred or scroll back through previous updates.

Conclusion

What’s 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

This is one of the most complex products I have worked on and while I loved the challenge, it was also a learning experience.

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.

When working on complex products, structure is fundamental but often require interactions.

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.