Project
Preventing vehicle theft with Engine Immobilizer
Role
Product Design
Team
1x Product Manager
1x Design Manager
1x VP of Design
2x Engineering Managers
Duration
2 months
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, it completes the digital ecosystem.
Web: Admin View
Admin configuration for setting up vehicles, managing drivers, permissions, and alerts.
Web: Fleet View
A hub for all Motive products, showcasing real-time information on tracking, safety, maintenance, fuel, and compliance.
Driver App
A companion app for drivers to pair with vehicles, manage assets, perform inspections, and maintain ELD logs.
Fleet App
On-the-go fleet management, including device management, vehicle and asset 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.
Bridging Admin 1.0 and 2.0
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 big impact on the Vehicles page. It was initially designed in the Admin 2.0 style but was never implemented, and over time, the Admin 1.0 version had seen a lot of additions. This created a unique challenge for me: I had to strip the page down and rebuild it, focusing on the most important elements while adding the Engine Immobilizer feature.
Updates to the Fleet View and Tracking Hub
Every page under the Fleet View is part of the tracking hub, which was undergoing major updates. The map, legends, and historical tracking views were all set to change systematically for both Vehicles and Drivers. This was part of a larger initiative to provide a cohesive structure for products, making them capable of functioning as standalone web applications.
Existing: Fleet View page (Updated page hidden for confidentiality)
Challenge: This is the most important and one of the more complex pages on the platform. I had to collaborate with the Tracking team to identify key areas that could be affected, such as the map, icons, and vehicle immobilization statuses across all Fleet View sub-pages.
Conflicts in Admin and Fleet views
Both of these views had become hotbeds for impromptu changes over time. It was no longer clear why each page existed, given the overlapping information. We had two choices: keep adding to these pages or fix them once and for all. We decided to take this opportunity to collaborate with other Product Managers and kick off efforts to reimagine both views.
Admin View
Admin configuration for setting up vehicles, managing drivers, permissions, device inventory, and alerts.
Challenge: Updating the Vehicles list page became an obstacle for Engine Immobilizer due to conflicts between the displayed data and the additions requested by teams.
Fleet View
A hub for all Motive products, displaying real-time information on tracking, safety, maintenance, fuel, and compliance.
Challenge: With real-time data missing from the Vehicles page, it was unclear how the immobilization status would be communicated to the fleet manager.
The Device Hub was in the plans
A new hub, similar to our Safety, Tracking, and Maintenance Hubs, was becoming increasingly necessary to centralize all device controls in one place. With up to nine devices on the horizon, one of the designers was already exploring solutions.
Challenge: Engine Immobilizer was set to become part of the Device Hub once it was completed. This meant I had to think about the product’s future state and design with that in mind. For example, I needed to figure out where to display all the assigned and unassigned Engine Immobilizer devices. Many of the existing patterns would be removed, so designing for those would be throwaway work.
Discovery
Talking to customers
After weeks of effort, my Product Manager scheduled 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, all thanks to our team in Mexico.
I translated all the designs into Spanish using DeepL and Google Translate for smooth communication. Oscar, as seen in the video, bridged the communication with our prospect.
Insight #1
The vehicle immobilization control lies with the fleet manager. Drivers should not have the ability to manage it, except in case of an emergency.
Insight #2
On average, a vehicle needs to be immobilized five times per month. The most common reasons are attempted robbery, followed by drunk driving.
Insight #3
The journey begins with the driver, following two main protocols.
The driver taps the panic button, which sends a help request to the Fleet Manager. The manager can then identify any abnormalities and immobilize the vehicle.
Alternatively, the driver calls the Fleet Manager and describes the situation, allowing the manager to immobilize the vehicle.
Insight #4
Tampering is a major concern. The device cannot be hidden because there are two possible installation locations: the fuel line or the starter line. During theft, thieves can easily locate these points and damage them, preventing the engine from turning off indefinitely.
Insight #5
The preferred method to immobilize a vehicle follows a two-step procedure.
First, the fuel line is cut off to decelerate the vehicle and bring it to a safe stop.
Then, the engine is turned off via the starter line and immobilized.
a deeper dive
The Engine Immobilizer's technical specs
A key factor in the speed of launch was that we couldn’t build this device in-house. With several undisclosed devices already being manufactured, we lacked the capacity to design, build, and ship the device on time. For the first time in Motive’s history, we decided to source these devices from a third-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 starter line or the fuel line
From the start, we had two installation options in mind. We aimed to offer both 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 was to focus on the starter line, as it addressed the primary requirement of fully immobilizing vehicles. The fuel line solution is now 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 be able to assign the engine immobilizer to the vehicle.
Step 1: Edit the vehicle settings
In 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 the vehicle gateway, and it will be ready to use.
Generating the Immobilization request
Let’s run through a scenario: A truck driver has stopped at a gas station and entered the store. The truck has been fitted with an Engine Immobilizer. The driver is ordering a cup of coffee when they look outside and see their truck moving away. What can they or can’t they do?
Option 1: Panic button
A dedicated trigger that sends an emergency alert to the fleet manager's dashboard.
Option 2: Calling the fleet manager
The driver can communicate via the app or call the fleet manager.
Our prospects have used both solutions before. They like the panic button for its simplicity, but it can be costly and lacks portability. The calling option, which aligns better with our scenario, seemed more feasible for the initial release. Most non-life-threatening highway thefts occur when the driver isn't in the vehicle and has no access to the panic button. Motive's driver app includes messaging, and drivers can also call their fleet managers.
Immobilizing the vehicle
Once fleet managers receive the immobilization request, they can immobilize the vehicle through Motive’s web platform in four simple steps.
Step 1: Open the vehicle page
The main access point is the Fleet View, the first page on the web platform.
Step 2: On the vehicle page, click "Immobilize"
I iterated several times on the placement of this action. More details can be found later in the case study below.
Step 3: Confirm the decision
While not very scientific, this extra step ensures that the person is consciously deciding to immobilize the vehicle. I also needed to communicate an important detail: 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 re-mobilized. A banner is displayed at all times when the vehicle is immobilized, providing details on the when, where, and who.
The vehicle status icon changes to "Immobilized" and turns red on the map.
The flow, though relatively simple, required several iterations due to the moving parts mentioned earlier in the case study. It required a lot of dedication and ownership to push this through.
Mobilizing the vehicle
If the immobilization was successful, the loss has hopefully been prevented. The next natural step would be to bring the vehicle back and involve the authorities. Re-mobilizing the vehicle is simple.
Step 1: Locate the vehicle.
Immobilized and pending immobilization vehicles are shown first.
The hover tooltip displays crucial information.
The immobilized icon is highlighted in red.
A new property for immobilized vehicles is added to the “Status” filter.
Step 2: Click Mobilize
The upfront banner makes it easy to identify immobilized vehicles.
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 vehicle's 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, but 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 for 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 little clarity on how the device would pair with the Vehicle Gateway.
Option #1: Auto-detection
An installed device is automatically detected through the Vehicle Gateway, requiring integration with the existing Motive ecosystem.
Option #2: Manual Assignment
The device must be manually assigned to a Vehicle Gateway, similar to how other accessories for the Vehicle Gateway are managed.
Since we chose the LTE-based immobilizer, it could theoretically be assigned independently. However, this approach was avoided due to two major factors:
To prevent irregularities in tracking data, the Fleet View relies on location and tracking data from the Vehicle Gateway to display accurate information. Using an Engine Immobilizer without a Vehicle Gateway would require rewriting everything to adjust our code to a proprietary system, which we have no control over, as it is a third-party device.
The Engine Immobilizer solution was intended to be bundled with the Vehicle Gateway. From a sales perspective, it didn’t make much sense to simply become a reseller of a third-party device.
To fit with the existing ecosystem of Motive devices, the assignment had to be manual. I reused existing flows for Dashcam assignment.
Decision: Manual Assignment
The Engine Immobilizer is manually assigned to a Vehicle Gateway, ensuring accurate communication of location and telematics data for detailed post-incident analysis.
How to find vehicles that have an immobilizer assigned?
This issue was subject to much debate, mainly due to the moving parts mentioned earlier. To reiterate, there were two major challenges:
The Fleet and Admin vehicle pages had become cluttered due to the addition of one-off features.
The Device Hub, a new feature aimed at centralizing devices in one place, was in development, meaning any changes to how devices were displayed on the admin page would be temporary.
The Fleet View Vehicles page
This page is for real-time data. Would an installed device with its status be considered real-time? 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, while 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 scalable.
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 their status.
Anatomy
The page contains real-time telematics, location, and video streams from dashcams. 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 the 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 vehicle's 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 vehicle 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.
Here is how the final flow looks like:
Step 1: The user clicks the "Immobilize…" option from the action menu.
Step 2: A global immobilization banner is shown for 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 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 manager the data.
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 our Spanish-speaking customers for feedback on the 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 the real world where there are many variables. One of those is the dead zones on highways. If we are not able to reach the vehicle, our device is essentially 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 could be used to enter a code to mobilize and immobilize a vehicle.
Option 2: Bluetooth
The driver could pair their mobile with the immobilizer via Bluetooth, but this was not possible since we chose the LTE-based devices.
Option 3: Pedals
Pressing the gas, brake, and clutch pedals simultaneously 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 the added cost. We decided to choose LTE over BLE, so the Bluetooth option was eliminated. This left us with the third option: allowing drivers to manually engage or disengage the immobilizer through a specific pedal sequence. At the time of my departure, we were still in talks with different vendors to explore more cost-effective, functional, and high-quality solutions.
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 received invaluable support from various teams: my manager provided mentorship, visual designers contributed iconography and customer handbooks, the sales team engaged with fleets, project and program managers ensured project success, and finally, the product team brought everything together.
The impact
What it means for the company and customers
This product enabled our team to expand into the Mexican market and unlock seven figures in revenue during the first quarter of 2024. This was just the beginning, with potential for significant growth in the future.
Direct impact
Increased revenue
This project was a direct contributor to the company adding 7-figures in revenue.
Regional expansion
This offering allowed Motive to successfully expand into the Mexican market.
Reduced premiums
Fleet insurance premiums were reduced due to the use of engine immobilizers.
Saved goods
Immobilizers helped protect customer cargo by significantly reducing theft.
Driver safety
Immobilizers + VG + Dashcams = Enhanced Safety
Increased productivity
Peace of mind allows our customers to focus more on their priorities.
This product was a first of its kind for both the company and myself. I was able to step into a very vague problem, figure out a solution, 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. This paved the way for me to really dig into the problem and build the solution.
A message to my future self
The things I will carry forward
When I started 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 I had to figure 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’re trying to solve? Most people suggest a ballpark of at least three iterations per idea, but there’s no hard limit.
*There comes a point where iterating too much leads to offloading the decision to someone else, which I wanted to avoid.
For this reason, I had to balance my ideas with the number of iterations. I divided the iterations into two parts per discussion:
Iterating with existing patterns
Iterating with new patterns
Having a robust design system within a complex product ecosystem gave me access to most design patterns. However, there were bound to be gaps when it came to integrating a completely new product. I eventually encountered such challenges and had to navigate my way through them. This involved researching existing patterns to avoid duplicating components, creating entirely new patterns, and persuading stakeholders to adopt them. With Motive’s design culture, I felt empowered to iterate while maintaining full ownership of the solution.
Talk to customers ASAP
With mounting pressure from the promises we made, I couldn’t sit around and wait for our customers to respond before designing the solution. This meant much of my work had to be based on assumptions, competitive research, and past experiences. Going into the second call with our customers, we realized there were many things we missed. However, I took that as an opportunity to learn more about the space and integrate their findings.
My goal from the start was to have strong fundamentals. The problem space did not change. The solution did not change. What changed was our approach. The customer calls helped inform my decision-making process as we moved forward. Talking to them helped me come up new ideas to integrate into our solution, making it a more robust platform for our customers. Some of those ideas have been discussed earlier in the case study.
Talking to customers is something I really enjoy but rarely get the opportunity to do. It can be an uphill battle at times to get feedback from customers, but I’m all for it because nothing beats learning from lived experiences.
A special thanks to
The teamwork that worked
We couldn’t build everything in the end, but I stayed true to what our customers needed and shipped the product to them, with more planned for the 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 working 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 teams from five countries was involved. This was a once-in-a-lifetime opportunity to design something incredibly complex, and I loved every second of it.
© Mustafa Ali Akbar