Alerting System
PROJECT
Improving Electra’s internal alerting tool used by the maintenance team to oversee charger performance.
Stakeholder: Maintenance team
Testing: wireframes on Miro + interactive Figma prototype
Handoff: to 3 back-end developers
METHODOLOGY
UR: shadowing + interviews
(5 stakeholders)
UX Audit: heuristic evaluation
*Live since May 2025
Overview
Problem: Maintenance engineers spend hours daily resolving alerts — often requiring 15–20 actions per alert due to poor UX.
Impact: The system is inefficient. Users struggle to onboard new countries and lose time navigating scattered information.
Importance: Faster alert resolution means fewer outages, higher uptime, and better revenue.
Constraint: No front-end developers, limited UI flexibility, limited dev time available.
Goal: Streamline workflows to cut alert-handling time down to 10 min (vs 45 min) and ease onboarding for operational teams.
Storytelling time: The user XP as it was
To start with, despite operating in 9 countries, the system lacked a country filter. Teams had to treasure hunt for their stations and memorise station names. A routine action — reset — required 5 clicks, even though it could have been automated or reduced to 2.
To define statuses, users opened multiple windows — each displaying dozens of tabs corresponding to alerts — simply because there was no way to categorise them. Each window was often left open for days.
As for prioritisation: there was none. Alerts arrived in real time, ungrouped and scattered. Ten alerts for the same station, dispersed across the timeline, made it impossible to have efficient interventions.
In short: the information architecture was disorganised, making it hard for users to understand the situation, let alone act on it.
Deconstruct to reconstruct
Before designing solutions, I broke down the current system using real usage insights and heuristic principles. This allowed me to map out what wasn’t working — and more importantly, why it wasn’t working.
