Embedding Spark™ AI into the ChargeLab product experience

About Spark™ AI by ChargeLab

OVERVIEW

Spark™ AI is ChargeLab’s AI intelligence layer built to simplify EV charger operations. By surfacing real-time diagnostics and recommending next-best actions, it helps site hosts and operators troubleshoot faster and with more confidence. Spark was designed to turn complex, technical data into clear, actionable insights directly within the UI.

Role
Product Designer & Researcher

Tools
Figma, Figma Make, Claude

Timeline
4 weeks of research and design, 1 week of testing, rollout phases ongoing through 2026

A Subpar Output

  1. Dense output: Spark was producing hard-to-parse, unstyled HTML that often left users uninterested in its response.

  2. Low visibility: Spark had grown into a small family of tools, but it lived in its own dashboard, separate from the ChargeLab CSMS so operators had no reason to go looking for it.

  3. Low adoption: Between the two, insights that should have driven action simply went unseen.

Context + Role

ChargeLab gives site hosts and operators a full suite of tools to manage their charging network, with the CSMS dashboard at the core. Spark AI was one addition to that suite and since its inception, it had grown into a small family of tools in its own right (chat diagnostics, rules engine, firmware validation, proactive actions and more). Built by a lean team, it lived in its own dashboard, separate from the ChargeLab CSMS. As its capabilities grew, so did a harder question: how do you get real value out of a growing set of AI tools that live somewhere nobody visits by default?

As a first iteration, Spark was brought into the dashboard as a diagnostic tool. But the output inherited its format from Spark's earlier life as a lookup tool for spec questions — a format that never caught up to the new job it was doing.

I was brought in to collaborate with the Spark Pod to rethink the interface of the ChargeLab CSMS and help identify where Spark could add the most value to our users.

Approach

  1. Ran customer discovery interviews alongside the PM to understand where Spark could help site hosts and operators most.

  2. From there, ran a card-sorting exercise with the EM to figure out which of those needs could realistically be built given our limited capacity, and what technical groundwork would unlock them.

  3. Visualized a phased approach for embedding these tools into the dashboard, and built prototypes to test with users and support staff.

OVERVIEW

PROBLEM

GOALS

A Phased Delivery

DESIGN

We reimagined Spark™ AI as a chatbot interface for a more conversational experience, and I redesigned the output itself with color-coded alerts, a concise diagnostic summary, and a clear root cause analysis to make complex AI output understandable and actionable. Engineering led the LLM and backend work; my focus was the interface and experience. It was refined through several rounds of internal and external usability testing before shipping.

This shipped first but only solved half the problem. Spark's output was easier to read, but you still had to know to go looking for it.

PHASE 1: Fixing the output

With Phase 1 live, the next step was surfacing Spark's various capabilities directly inside the CSMS. This came in a few forms:

  • Charger-level notifications: There was no notification engine to build on yet, so I embedded a notification at the top of the charger details page, flagging failures or any valuable charger-level insights. This was the first step in helping users become proactive versus reactive with charger management.

  • Session-level diagnosis: The engineering team was able to tag the likely causes (e.g. user error, hardware error) of most failed sessions, so we decided to surface these tags to our users. It couldn't always pin down a reason for every session, since multiple factors were often at play.

PHASE 2: Bringing Spark into the dashboard

With charger and session-level insights in place, the next step was surfacing patterns at the location level.

This included things like surfacing clusters of failures across sites, chargers nearing the point of needing a firmware update, or notable shifts in session volume or fees collected — patterns that only become visible once you zoom out past a single charger.

PHASE 3: Location level insights

In conversations with customers, several have called out how the added visibility into charger maintenance lets them be proactive. The support team has leaned into these tools too, pulling up Spark's insights while on live calls with site hosts and drivers instead of working from logs alone. Overall, even though not all the changes have rolled out yet, early signals have been positive.

IMPACT

PHASE 4: Vision for the future

The long-term vision: help users spot anomalies at their charging stations quickly, and empower them to fix as many issues as possible themselves. This will show up in two ways on the ChargeLab dashboard:

  • Always-on assistant: Spark can be triggered from anywhere in the dashboard, not tied to any one page, so help is available the moment someone needs it.

  • Notification center: a dedicated home for Spark's proactive alerts, consolidating what's currently scattered across individual pages into one place, something operators can either check on their own or be pinged by directly.