Case Study . Vec-TR, Vecmocon Technologies
Making Remote EV Commands Safe and Reliable
Command Centre is the module we designed in Vec-TR that lets fleet operators and engineers push firmware and configuration updates to thousands of connected IoT devices across EV fleets, in a way that's structured, traceable, and safe by design.
Team
Product Designer, Developers, Product Managers
Duration
11 Months (2023 - 2026)
Platform
Web app
Decipline
Research, UX, UI, Testing
This project involved a larger team of 13 Developers, 2 Product Managers, 2 Designers and 1 Design Lead, 3 QA Analysis and Product Managers of BMS, IoT and Charger.
Overview
Vec-TR is Vecmocon's SAAS platform for monitoring EV fleets remotely — giving operators visibility into asset health, device status, and field issues in real time, from anywhere. Command centre is the part of it that is built to push changes back out to the fleet, rather than just watching it.
The scale is what makes the risk real: Vec-TR tracks close to 10,000 connected devices, each one physically installed inside a vehicle already running on the road. Sending a single firmware command can target up to 500 assets at once — and there's no undo. Once a command reaches a device, it's committed. This project is about making those remote safe and reliable for operators.
The Challenge
Our engineering team were sending firmware updates using Python script, manually coordinated firmware files over chats and spreadsheets. The process "worked" in sending commands but a wrong hardware version would only surface after the command had been sent.
The problem wasn't a missing feature. It was that the existing process would let user do anything, right up until something went wrong with the vehicle.
Solution
We defined two principles that shaped every decision that followed. The goal was to introduce positive friction — small, deliberate pauses that reduce the user's cognitive load by shifting validation from memory to system.
01 - VALIDATE BY SYSTEM
Don't expect user to remember every compatibility rules, let the system validate it.
02 - ONE COMMITMENT AT A TIME
Each step locks in a decision before revealing the next. Instead of managing every variable simultaneously, the user moves through a narrowing set of certain choices.
File Management
A single source of truth for firmware
A central home for firmware files, shifting the memory load from person to system.
Creating a firmware file
Metadata — version, compatible hardware, organisation — set once at creation, then reused as validation everywhere the file is used.
Switching a firmware file from inactive to active
Inactive by default — a file can't be used in a command until someone deliberately switches it on.
This one decision closes the most common failure mode we saw in the old process — a file being deployed before anyone confirmed it was the right one.
Create Command
A guided, 4-step wizard
One decision at a time, checked by system as user go.
1
Select file & devices
Choosing a file first filters the next screen to only compatible assets — anything incompatible simply isn't included. Switch between a flat list or grouped view depending on scale, and assets already mid-command show as unavailable, linked straight to the batch that's blocking them.
Selecting a compatible firmware file before choosing assets.
Incompatible assets automatically excluded from selection.
Toggling between flat list and grouped asset view for scalable selection.
User can directly link to the blocking batch, so they can decide whether to intervene rather than hit a dead end.
2
Set the trigger
Immediate runs the command the moment it's created. Manual holds it pending — open for review, escalation, or cancellation.
3
Set a timeout
A Never command keeps retrying indefinitely, for fixes that can't wait. A defined threshold stops zombie commands from draining device batteries on repeat failed attempts.
4
Review & commit
Every decision — file, targets, trigger, timeout — shown once, and locked. The last chance to catch a mistake before it reaches up to 500 real vehicles.
Command logs
A live audit, with room to act
Every command sent, tracked from
Pending
In progress
Pass
Failed
Ended
Real-time monitoring
Track batch level progress, or drill into the detailed performance of command in every asset.
Manual trigger holding state
Waiting command sit in Pending state with a prominent 'Trigger' action so it does not go unnoticed.
Edits Before Launch
Pending batches can be reviewed and adjusted for last minute changes before they go out.
Retry Command
Retry a command stuck in a long in-progress state or failed due to an error. Clear memory before retrying increase chance of success in next run.
Impact & Learnings
100%
The engineering team fully shifted from python scripts to Command Center.
100%
Reduction in mis-sent commands and configurations.
Friction only earns its place if it catches a real failure. Every pause we added — inactive files, locked steps, the final review — had to prove it stopped something from going wrong, or it was just annoyance in disguise.
Validation has to live inside the flow, not beside it. Moving compatibility checks into the wizard, instead of a rules doc, is what actually changed behaviour — nobody reads a rules doc under deadline.