Table of contents
The need for an Engine Immobilizer
Engine Immobilizer became a blocker
Leading the design
Intro
The need for an Engine Immobilizer
At the Q3 of 2023, right as I joined Motive, the plans were already in motion for expanding to Mexico. Along with came unique challenges from localization, to policies, and the different needs of the country’s Fleets.
Some statistics from our Sales Engineers in the field in Q2 2023:
90%
prospects in Mexico requested the ability to remotely immobilize vehicles.
1x
significant prospect was lost due to the lack of an engine immobilizer
Engine Immobilizer became a blocker
Based on the above statistics, we realized that we needed the vehicle immobilization feature for expansion to Mexico. We had to backtrack on our priorities and this was the only core requirement we were missing from our comprehensive product offering. As we headed into Q4 2023 with boots on ground, we needed to figure everything towards the end of quarter, with a Q1 2024 launch. The shift warranted a coordinative effort among 3 major teams at Motive: Hardware, Tracking, and Platform.
My Role
Leading the design
I was hired on the Hardware team. Motive operates on a pod-like structure where distributed remote teams lead their own product areas. The larger design team is a coalition of product designers, content designers, visual designers, and managers, led by VP of Product Design, Jadam Kahn. My role was to lead this feature end-to-end with support from Moazzam Khalid (Hardware and 3D), Umer Shahid (Visual and Packaging), and Katrina Zawojski (Content).
The challenge here was to align the several ongoing projects with this one and figure out the far-reaching impact of adding this feature to a lineup of existing products at Motive. I partnered with my Product Manager, Nikhil Karanam, on getting the product to the launchpad.
State of Product
The Existing Landscape
Motive has an existing platform of integrated IoT devices used by over 120,000 companies across the U.S. and Canada.
In a nutshell
Motive builds technology to improve the safety, productivity, and profitability of businesses that power the physical economy.
The Devices
The existing devices range from Vehicles to Assets.
AI Omnicam
360° view of vehicles, used to cover blind spots.
AI Dashcam
Road + Driver facing dashcam with AI capabilities.
Smart Dashcam
Road facing dashcam with AI capabilities.
Vehicle Gateway
Hub for telematics, location, and dashcam data.
Asset Gateway Mini
Small-form battery-powered device for tracking assets .
Asset Gateway Solar
Solar powered asset tracking device for remote locations.
Environmental Sensor
Track reefer temperatures with multi-zone support.
Engine Immobilizer
Prevent unauthorized vehicles use remotely.
Planned for q1 '24
ID Reader
Driver verification without the use of app or passcodes.
Planned for q1 '24
The Platforms
The web platform is primarily used by fleet managers and admins, combined with the Driver App and Fleet App, the digital ecosystem completes.
Web: Admin View
Admin configuration for setting up vehicles, managing drivers, permissions, and alerts.
Web: Fleet View
Admin configuration for setting up vehicles, managing drivers, permissions, and alerts.
Driver App
A companion app for drivers for pairing to vehicles, assets, inspections, and ELD logs.
Fleet App
On-the-go fleet management, including device management, tracking, and alerts.
Major systematic updates were in-progress
The project was at a crossroads with several moving pieces. The product had gradually grown from just a Vehicle Gateway (previously known as ELD) and a Driver Log App to a comprehensive ecosystem of IoT devices used by some of the largest fleets in the U.S. in less than a decade.
Admin platform was upgrading
The entire entire Admin platform was being migrated from Admin 1.0 to Admin 2.0. Working on Admin platform meant jumping between old and new design systems where necessary. Some product areas had already moved to Admin 2.0 making it easier, some product areas had migration dates coinciding with the launch of Engine Immobilizer, and some product areas would update as the direct product of this new feature.
Existing: Vehicles page in Admin 1.0
Planned: Vehicles page in Admin 2.0
Challenge: My work was going to have a major impact on the Vehicles page. It was once designed in Admin 2.0 style but never implemented, and since then, the Admin 1.0 page had many things added to it. This presented a unique challenge to me, where this page had to be stripped down and rebuilt by prioritizing the most important things, while adding the Engine Immobilizer component to it.
Fleet View had major changes in plans
Every page that comes under the Fleet View is part of the tracking hub. It was going through major updates. The map, legends, and the historical tracking views were set to change systematically for both Vehicles and Drivers. This change was a part of larger initiative in providing a cohesive structure to products that could be their own web applications.
Existing: Fleet View page (Updated page hidden for confidentiality)
Challenge: This is the most important page on the platform, and one of the more complex. I needed to work with the Tracking team on identifying key areas that could be affected such as map, icons, and vehicle immobilization statuses across all Fleet View sub-pages.
Conflicts in Admin and Fleet views
Both of these views had become breeding grounds for impromptu changes in the product over time. It was no longer clear why each of these pages existed with overlapping information. We had two choices: keep adding things to these pages or fix them once and for all. We wanted to take this opportunity to collaborate with other Product Managers to initiate efforts to reimagine both views.
Admin View
Admin configuration for setting up vehicles, managing drivers, permissions, device inventory, and alerts.
Challenge: Adding changes to the Vehicles list page became an obstacle for Engine Immobilizer due to conflicts between the data shown and what teams wanted to display.
Fleet View
A hub for all Motive products, showcasing real-time information on tracking, safety, maintenance, fuel, and compliance.
Challenge: With missing real-time data on the Vehicles page, it was unclear how the immobilization status would be communicated to the fleet manager.
Device Hub was in plans
A new hub, like our Safety, Tracking, and Maintenance Hubs was becoming increasingly necessary to centralize all device controls in one place. With up to a total of 9 devices on the horizon, one of the designers was already working on the strategic initiative.
Challenge: Engine Immobilizer was going to become part of the Device Hub once it was finished. This meant that I had to think of the future state of the product and design according to that. An example would be to figure out where to show all the assigned and unassigned Engine Immobilizer devices. A lot of patterns that existed now were going to be removed and designing for those patterns would be throwaway work.
Discovery
Talking to customers
After weeks of effort, my Product Manager was able to set up a call with our largest prospect in Mexico. I was able to get in touch with people the fleet managers and dispatch managers to understand their concerns. This was all enabled through our team in Mexico.
I translated all the designs to Spanish using DeepL and Google Translate for seamless communication. Oscar, as seen in the video was bridging the conversation with our customer.
Insight #1
The vehicle immobilization control rests with the fleet manager. The drivers should not have the ability to manage it, unless it is an emergency.
Insight #2
A vehicle on average needs to be immobilized 5 times per month. The most common reason is robbery attempt, followed by drunk driving.
Insight #3
The journey starts with the driver. There are two major protocols that they follow.
The driver taps the panic button, which sends the help request to Fleet Manager. The manager can then look for abnormalities and immobilize the vehicle.
The driver calls the fleet manager and describes the situation. The Fleet Manager can then immobilize the vehicle.
Insight #4
Tampering is an issue. It is impossible to hide the the device itself because there are two possible install locations: Fuel line, or the starter line. During theft, the thieves can easily locate those and destroy them to prevent the engine from turning off indefinitely.
Insight #5
The preferred way to immobilize a vehicle is through a 2-step procedure.
The fuel line is cutoff to decelerate the vehicle and safely bring it to a stop.
The engine is then then turned off through the starter line and immobilized.
a deeper dive
The Engine Immobilizer's technical specs
A key element for the speed of launch was that we could not build this device in-house. With several undisclosed devices being manufactured, we did not have the capacity to design, build, and ship the device on time. For the first time in Motive’s history, we were going to get these devices from a 3rd party vendor.
Relay: Deciding between LTE or BLE
After talking to potential vendors, we came up with two possible options.
LTE
High unit cost.
Can work as a standalone device.
Requires a data connection.
It can pair with our servers through a LTE connection in case the Vehicle Gateway loses reception.
Anything beyond the connection status can be communicated without the Vehicle Gateway.
BLE
Low unit cost.
Requires pairing with a Vehicle Gateway.
Connects via Bluetooth. No data required.
Single point of failure -- if the Vehicle Gateway has no data reception, the device would be unreachable.
The payload size of Vehicle Gateway increases due to carrying additional data, possibly affecting the low-data limit.
Installation: The fuel line or starter line
We had two installation options from get-go. We wanted to provide both of these as part of the two-step solution.
Starter line
Cuts the ignition
Cannot immobilize a moving vehicle
Once stopped, the engine cannot start again
Installation is usually required in only one location
Fuel line
Cuts the fuel
Used for stopping moving vehicles
The engine can start if multiple fuel lines are present
Depending on the number of tanks and auxiliary lines, multiple devices might be needed
It was becoming increasingly clear through discussions with backend and firmware development teams that we could prioritize only one solution for the Q1 launch. The unanimous decision went to the starter line because it solved the primary request of immobilizing vehicles completely. The fuel line solution is slated for release in late 2024.
Starter line installation diagram, property of Motive.
The final product
The designs
Assigning an Engine Immobilizer
Once installed in the vehicle, the users would have the ability to assign the engine immobilizer to a vehicle
Step 1: Edit the vehicle settings
On the Engine Immobilizer section, click the "Assign…" button.
Step 2: Select the Engine Immobilizer
Select a serial number from the list and click "Assign"
Step 3: Save the vehicle settings
Wait for the immobilizer to pair with vehicle gateway and it will ready to use.
Generating the Immobilization request
Let’s run through a scenario: A truck driver has stopped at a gas station and enter the store. The truck has been fitted with an Engine Immobilizer. They are ordering a cup of coffee when they look outside to see their truck moving away. What can they or can’t they do?
Option 1: Panic button
Admin configuration for setting up vehicles, managing drivers, permissions, device inventory, and alerts.
Option 2: Calling the fleet manager
The truck driver has a line of communication using the driver app, or calling their fleet manager.
Our prospects have used both of these solutions in the past. They like panic button for its ease of use for the truck drivers, but it can incur them extra cost, and it lacks portability. The calling option seemed more feasible for the initial release, and it worked with our scenario, which is how most non life-threatening highway thefts take place. Most of the times, the driver is not in their vehicle with no access to the panic button. Motive has a driver app with the messaging feature. The drivers can also call their fleet managers.
Immobilizing the vehicle
Once the fleet managers receive the immobilization request, they can immobilize the vehicle through Motive’s web platform. All it takes for them 3 steps to do that.
Step 1: Open the vehicle page
The main access point is through the first page on the web platform. The Fleet View.
Step 2: On the vehicle page, click "Immobilize"
I iterated several times on this actions’s placement. Details can be found later in the case study below.
Step 3: Confirm the decision
While not very scientific, this is an extra step to ensure the person is deciding to immobilize a vehicle consciously. I also needed to communicate a very important detail that the vehicle can only be immobilized once the engine has been powered off.
Step 4: The vehicle is immobilized
The immobilized vehicle cannot be started again unless it is immobilized. A banner is displayed at all times when the vehicle is immobilized, completing the when, where, and who.
The icon for the vehicle status changes to Immobilized with a red color on the map.
The flow, while being relatively simple took several iterations due to the moving parts mentioned in the case study previously. It took a lot of dedication and ownership to push this through.
Mobilizing the vehicle
If the mobilization was successful, the loss has hopefully been prevented. Now the next natural step would be to bring the vehicle back (and also get the authorities involved). Re-mobilizing the vehicle is simple.
Step 1: Locate the vehicle.
Immobilized and pending immobilization vehicles are shown first.
The hover tooltip shows crucial information.
The immobilized icon is highlighted in red.
A new property for Immobilized vehicles is added in the “Status” filter.
Step 2: Click Immobilize
Upfront banner helps identify immobilized vehicles easily.
Step 3: Confirm
This is an extra layer to confirm. This was primarily a Product ask and I felt this was appropriate for it to be here.
Step 4: The vehicle is now mobilized
In most cases, the state will be stationary.
The icon reverts to its current state.
From 0 to 1
How I arrived at the final designs
Several key decisions shaped the final interactions, some of which I have discussed previously.
Figuring out the journey
Initially, to figure out the journey and key details, I started working on the user flows. Doing this not only helped me understand the intricacies of existing workflows, it also gave me a very good idea of how the specifics of this new device would work out.
Below is a snippet of a high level user flow of pairing a Vehicle Gateway with an Engine Immobilizer.
Assigning an Engine Immobilizer to a vehicle
Assigning an Engine Immobilizer was still a mystery at this point. Partly because there was very little clarity on how the device is going to pair with the Vehicle Gateway.
Option #1: Auto-detection
An installed device is detected automatically through the Vehicle Gateway. This requires integration with the existing Motive ecosystem.
Option #2: Manual Assignment
The device has to be assigned manually to a Vehicle Gateway. This is similar to how other accessories for the Vehicle Gateway work.
Since we chose the LTE based immobilizer, it could theoretically be assigned independently. However, it was avoided due to two major factors.
To prevent irregularities in tracking data, the fleet view relies on location and tracking data coming from the Vehicle Gateway to display information accurately. Using an Engine 2. Immobilizer without a Vehicle Gateway would mean rewriting everything to adjust our code to a proprietary system which we have no control over since it is a 3rd party device.
The Engine Immobilizer solution was meant to be bundled with the Vehicle Gateway. From a Sales POV, it did not make much sense to just become a reseller of a 3rd party device.
To fit in with the existing ecosystem of Motive devices, the assignment had to be manual. I re-used existing flows for Dashcam assignment.
Decision: Manual Assignment
The Engine Immobilizer is manually assigned to a Vehicle Gateway, enabling accurate communication of location and telematics data for a detailed post-incident analysis.
How to find vehicles that have an immobilizer assigned?
This particular issue was subject to much debate. Partly because of moving parts I mentioned above. To reiterate, there were two major issues:
The Fleet and Admin vehicle pages had become a mess due to addition of one-off features.
The Device Hub, a new feature to centralize devices into one place was in the works, which meant that any changes to how we display devices on the admin page would be throwaway work.
The Fleet View Vehicles page
This page is for realtime data. Would an installed device with its status be considered realtime? I explored a few iterations for this before we decided on not changing anything here.
Option #1: Separate columns for Cameras and Accessories
The idea is simple. The dashcams and omnicams are considered standalone devices. Other small devices are considered accessories. RFID Reader was planned for the future so I decided to make sure we were covering all the bases and my design was scaleable.
Option #2: Single column for all devices and accessories
This exploration was meant to combine all the connected devices to one column. However, the tooltip ended up being too long for most screens.
Decision: Show vehicle status instead
Going back and forth on which data to show, we finally decided that this page was meant to represent realtime status of device, instead of realtime connection status of devices. In our case, the only realtime status was of the vehicle itself, with an added layer of immobilization. This page is now a list representation of Live view.
The Vehicle detail page
This page was the most crucial one for any fleet manager. It was meant to house the action to immobilize vehicles, including the status.
Anatomy
The page contains realtime telematics, location, and video streams from dashcams. The fault codes are highlighted through a banner.
Iterations
There were two problems to solve. Where to show the status and where to place the action for immobilization
Iteration #1
The action is placed on the top right with rest of the buttons
The Immobilize button changes to cancel, with the status mentioned next to it.
Once the vehicle is immobilized, the status will also change to Immobilized.
Iteration #2
The action is placed below the current status
The request status is shown right below it.
Once the vehicle is immobilized, the button changes to “Mobilize”
Iteration #3
The action is placed next to the status
Request details appear below the status
Once the vehicle is immobilized, the details are shown under the status
Iteration #4
I explored adding a new section for Engine Immobilizer on the left pane
The request details will appear within a self-contained section
Once the vehicle is immobilized, the button changes to “Mobilize”, with the status of the immobilizer as “Activated”. This makes the immobilizer status independent of vehicle status.
Iteration #5
For this iteration, the immobilize button is on the top with other action buttons
A global immobilization banner is shown for the immobilization status,
The immobilization status is again shown via banner with the button to Mobilize it.
Decision - Banner with the button
We finally decided on the banner approach. It would be available for less than 1% of vehicles at a time. This meant that it could be easy to miss if the element is not prominent enough. We decided on using a banner under tabs after a few more iterations.
Step 1: The user clicks the "Immobilize…" option from the action menu.
Step 2: A global immobilization banner is shown for the pending and immobilized statuses.
The Vehicle profile page
The vehicle profile page on Fleet View, in most cases is a 1:1 reflection of the vehicle profile page on the Admin View. It reflects the statuses of the installed devices and accessories.
A comparison of different statuses on both pages can be viewed below.
Immobilizer is assigned but the pairing is not complete
Admin View: Vehicle Profile Page
Fleet View: Vehicle Profile Page
Immobilizer is connected and functioning
Admin View: Vehicle Profile Page
Fleet View: Vehicle Profile Page
Immobilizer is not reachable
Admin View: Vehicle Profile Page
Fleet View: Vehicle Profile Page
What if
Not everything goes well
The crisis was averted and everyone is safe, but there is a hiccup. The person who tried to steal the vehicle was not very gentle with driving. You have to report the damages and get coverage. Hopefully the company that sold you all these devices could help here.....right?
The tracking analysis
For starters, there is a complete map history view available for the Fleet Managers. A simple addition for the immobilization events could prevent any liability for the fleets. Have a Motive AI dashcam? That’s even better since there is footage now.
Vehicle - History View
The history view contains a map-based timeline, with timestamps for events across a trip.
Timestamps
The left pane shows a list-view of events with timestamps
Map
The map view shows exactly when the request was initiated and completed.
Timeline View
A color-coded and labeled timeline view with seek and play functionality helps Fleet Managers visualize incidents.
It has been happening a lot lately
Turns out your fleet has been hit multiple times and you need to figure out what exactly, and when.
Reports
The purpose of reports is simple. Analyze, export, or ignore. Want to make a case for more precautionary measures for your fleet? Just show your boss the tables.
Testing it out
Field Testing and Feedback
All the while preparing the designs, I was translating them to Spanish since we were trying to schedule a meeting with with our customers for feedback on designs. One sudden day, my Product Manager gave me a one-hour notice for the call. I quickly hopped on the call to walk them through the solution we built for them, anxiously waiting for their feedback.
Surprisingly, our customers (previously prospects) really liked the solution we built for them, but they were worried about a few things.
Customer Feedback: What if someone tried to steal the immobilizer?
We cannot rule out the possibility that the vehicles thieves would know how to disengage an immobilizer by hot wiring, or maybe, a more technologically advanced solution such as jamming. I designed some alerts just for those events.
Tamper Alert
If someone tries to remove the Engine Immobilizer, or makes changes to the configuration, an alert will be sent.
Jammer Alert
Designed to alert users if someone decides to disrupt the communication between the Engine Immobilizer and the Motive Platform.
Customer Feedback: What if there is no reception?
There is one issue with our tech. It has to work in real world where there are many variables. One of those is the dead zones on the highways. If we are not able to reach the vehicle, our device is useless. I partnered with my Product Manager on figuring out how to bypass not having a signal. We were limited by both cost and technology. Our customers recalled having used all of these solutions before.
Option 1: KeyPad
A remote control device that can be used to enter a code to mobilize/immobilize a vehicle.
Option 2: Bluetooth
The driver can pair their mobile with immobilizer via bluetooth, but this was not possible since we chose LTE.
Option 3: Pedals
Similar to taking a screenshot, this gas+brake+clutch combo could be used to activate or deactivate the immobilizer.
Ideally one or more of these options would be available to the driver. KeyPad was not a possibility due to added cost. We decided to choose LTE over BLE, so Bluetooth was eliminated. This left us with the third option, allowing the drivers to manually engage or disengage the immobilizer through pedals for the initial phase. At the time of my leaving, we were still in talks with different vendors for a better cost, function, and quality solution to this.
Rolling out
Launching the product
This product launch was a collaborative effort between the broader design, product, embedded, marketing, and sales teams. While I led the digital Product Design, I had the support from my manager in the form of mentorship, the visual designers in the form of iconography and customer handbooks, the sales team in reaching out to fleets, the project and program managers for getting the project through, and finally the product team in bringing everything together.
The impact
What it means for the company and customers
This product enabled our team to expand to Mexico, and unlocked $8 million in done deals throughout Q1 of 2024 with the opportunity for more deals going forward.
Direct impact
Increased revenue
This project was a direct contributor to the company adding 7-figures in revenue.
Regional expansion
Motive was able to expand to Mexico as a result of this offering.
Reduced premiums
Using engine immobilizers meant the fleet insurance premiums were reduced.
Saved goods
The immobilizer would save cargo by preventing theft for our customers.
Driver safety
By pairing the immobilizer with VG and Dashcam, the net safety is increased.
Increased productivity
Theft prevention means that our customers can focus more on operations.
This product was a first of its kind for both the company and I. I was able to step into a very vague problem and realize its potential. It was a bold vision for everyone involved. At the start of the project, I struggled with connecting many moving parts, but having conversations with so many dedicated people by jumping into design critiques, product meetings, and executive reviews across broader teams helped me form a strong foundational understanding of the product and its future vision.
A message to my future self
The things I will carry forward
While working on this project, I had accumulated 5 years of my time in UX Design. One thing I have always enjoyed about working in the space is the constant opportunities to learn and work with a diverse team of so many incredible people and their ideas. Naturally, this project didn’t come without its intricacies in teaching me some new things.
Embrace the ambiguity
Running into such an impactful undertaking as soon as I joined the company meant understanding a vast array of projects, team dynamics, and product areas in a very limited time. At times, I found myself exhausted with the onset of new problems. As I described earlier, several projects and revamps were in motion. No one wanted to do any throwaway work, and most folks were busy with their own projects. This meant that figuring out a very refined set of questions to ask them to understand their projects and how my work could affect them. I had to plan months ahead, even while the problem space was very ambiguous, and keep every team in the loop. This helped me avoid conflicts and give everyone a heads-up on what to expect.
Iterate x ∞*
What’s a good number of iterations for any problem you are trying to solve? Most folks give a ballpark of at least 3 iterations per idea, but there is no cap on it.
*There comes a fine point where you iterate so much that you offload the decision to someone else, and I wanted to avoid that. For this purpose, I had to balance my ideas with iterations. I divided the iterations into 2 parts per discussion.
Iterate with existing patterns
Iterate with new patterns
Having a robust design system with a complex product ecosystem meant I had access to most of the design patterns, but there were going to be some missed spots when it came to integrating a completely new product. I eventually ran into such problems and had to figure my way out. This meant researching existing patterns to avoid duplicating components, and coming up with completely new patterns and convincing our stakeholders to implement those. With Motive’s design culture, I felt empowered to iterate while maintaining ownership of the solution.
Talk to customers ASAP
With mounting pressure from the promises, we couldn’t sit around and wait for our customers to respond before we started designing. This meant that a lot of our work had to be based on assumptions, competitive research, and our past experiences. Going into the second call with our customers, we realized there were many things we missed out on, however I took that as an opportunity to learn more about the space and integrate their findings. My goal, since the start was having strong fundamentals. The problem space did not change. The solution did not change. What changed was our approach, the customer calls helped inform our decision-making process as we went ahead. It gave us new ideas to integrate with our solution to provide a more robust platform for our customers. Some of those ideas have been discussed above in the case study.
Talking to customers is something I really enjoy, but rarely get the opportunity to do so. It is an uphill battle at times to get a word from the customers but I am all for it because nothing beats lived experiences.
A special thanks to
A special thanks to
We couldn’t build everything in the end, but I stayed true to what our customers needed, and shipped it to them, with more planned for future. I stayed in touch with our customers post launch to see how this product would help them in their day to day needs. I am wholeheartedly grateful to the entire team for woking together to make this product a reality.
A laser-focused coalition of Backend, Frontend, Security, Electrical, QA, Design, TPM, Supply Chain, Hardware Compliance, Supportability, Pricing, Legal, Product, and Product Marketing from 5 countries was involved. This was an opportunity of a lifetime to design something incredibly complex and I loved every second of it.