Case Study . BESS, Vecmocon Technologies
Turning Dense Battery Telemetry into Actionable Insights
Designed the monitoring dashboard that lets operators of battery energy storage systems see what is wrong, where it is, and how urgent it is, without digging through spreadsheets and terminals.
Team
Product Designer, Developers, Product Managers
Duration
3 Months (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
Battery Energy Storage System (BESS) stores generated electrical energy in large banks of batteries to release it when it is needed, for renewable energy, industry, homes and businesses. A single system can hold thousands of cells, each reporting temperature, voltage and current in real time.
That much stored energy carries real risk. An overheating cell can lead to thermal runaway and, in the worst case, a fire. Reading the data correctly and acting on it quickly is a safety task.
Vec-TR is Vecmocon’s SaaS platform for monitoring, diagnosing and configuring these devices. My work turned a battery system’s raw data into an interface people can act on.
Terms used in this case study
• VIM: the IoT gateway that collects data from every BMS on a site
• BMS / node: the battery management system attached to one battery pack
• SoC: state of charge, how full the battery is
• SoH: state of health, how worn the battery is
The Challenge
Operators were watching live device data in spreadsheets and terminal output. At that volume, faults such as thermal anomalies were easy to miss and slow to diagnose.
Three problems stood out:
• No instant read on health. Text-heavy data does not show whether a battery is healthy, and non-technical readers cannot interpret it.
• Faults were hard to act on. Operators could not quickly tell what had gone wrong inside a battery, or what to do next.
• Little support for hindsight. Analysing past data to spot patterns and prevent repeat faults was difficult.
Research Insights
I ran contextual inquiries and semi-structured interviews with system administrators, maintenance engineers, and grid operators (9 participants across 2 organizations). The research revealed several critical operational behaviors:
01 - THE NEEDLE IN HAYSTACK
Operators spent [about 70%] of their troubleshooting time just locating which battery, under which BMS, was dragging system efficiency down.
Design response: surface the pack that needs attention from the list level.
02 - ALERT FATIGUE
Raw data dumps overwhelmed people. They needed routine telemetry (charge, temperature, voltage) kept apart from critical alerts (thermal runaway risk, communication loss).
Design response: separate everyday status from active alarms.
03 - A TOP-DOWN MENTAL MODEL
Operators picture the site as Plant, then VIM, then BMS, then battery. An interface that mirrors this feels natural.
Design Response: navigation that follows the same order.
Information Architecture
The product opens from two short paths that meet at the pack. One starts from the gateway and the other from the pack, and both end on the same detail screen.
Solution
The design strategy heavily leverages a "progressive disclosure" model, allowing users to start with a macro-view of all connected VIMs and systematically drill down into micro-level diagnostics of each battery pack.
Level 1 - Gateway Hub
Two entry points — VIM and BMS list to drill down from different device level health analysis.
The Gateway First
Gateway list informs if all the devices are online, updated and the total number of active nodes. The first and most basic health check of all devices at once starts from number of online devices.
All The Active Nodes on Platform
The BMS list shows every connected battery in one table, with charge, health, voltage and current. Search by ID to jump straight to a specific battery.
Level 2 - BMS Module Directory
Each gateway (VIM) opens a hub page. On the left is the gateway’s own health: connection, signal strength and uptime. On the right are its connected batteries, so a weak one can be spotted and opened for diagnosis.
Scalable View
Data dense list view for engineers to diagnose faults, operators prefer visual grid view for routine monitoring.
Level 3 - Battery Health Dashboard
From glancable health check to deep data.
Real-time Health Update
The top half of the dashboard is dedicated to instantaneous status updates, giving operators immediate visibility into health, component states, and active safety alerts without needing to scroll.
Vital parameters on first priority. Color separates “all OK” from “needs attention”.
Secondary information about battery. Provide early signs of battery health.
Dedicated faults section showing only active alarms by making a critical fault visually different from a warning. Different color shows different level of criticality of fault, combined with the fault code.
Latest value of cell voltages and temperature. The operator doesn’t have to compare 16 numbers by eye. The outliers are already marked, and cell imbalance is the main early signal of pack degradation.
Historical Data
Historical allow operators to investigate trends over time, evaluate wear patterns, and run root-cause analysis.
SoC, Pack Voltage and Current on one chart: These are the signals most diagnoses start from. Overlaid, they show whether a voltage dip lines up with a current spike.
Cell voltages and temperatures over time: One line per cell or sensor. A line that drifts away from the rest signals imbalance and require immediate action.
All Data Table: This is audit layer. Customizable columns, compare over a time period, and export the result to share an analysis.
Impact & Learnings
Operators now go from the fleet view to a single faulty battery in 2 to 3 steps, instead of downloading multiple excel sheets and finding right data fields in each device.
Across 2 organization's users, finding a failing battery became 4 times faster.
Design for the question, not the dataset. Layering the page from snapshot to trend to table let the same screen serve operators and engineers without making either dig.
Data quality is part of the interface. Showing how fresh a reading is, and why it might be missing, mattered as much as the readings themselves. A dashboard people stop trusting is worse than none.