The first concept improved triage, but not diagnosis

My first concept brought connection status, uptime, disconnected duration, and fault information into one network-level view.

It gave operators a faster way to identify which stations needed attention without piecing together alerts, driver reports, and support tickets. The concept worked for triage, which is why it remained in the product.

But it still could not explain what happened at an individual station or what the operator should do next. That gap redirected the redesign toward the station-level investigation.

Design challenge

Operators needed one workflow to identify the station requiring attention, understand what changed, and choose the right response.

A home base for station investigation

After triage, the redesigned Station Overview became the operator’s starting point for investigating an individual station.

Current station and connector status remained visible at the top. Time-based metrics showed recent performance, while tickets, work orders, O&M events, and activity revealed what had happened around the issue.

Support information appeared prominently because operators first checked whether the problem had already been reported, assigned, or escalated to field support. This helped prevent duplicate investigation and unnecessary dispatch.

Each O&M event linked directly to its matching Real-Time Log entry, so operators did not have to find the event manually.

Reducing tool switching without rebuilding Zoho

Operators previously left ChargeLync to search Zoho for station-specific tickets and work orders. This made related or duplicate issues easy to miss.

I initially proposed creating and managing Zoho tickets directly from the Station Overview. Engineering pushed back because bringing the complete ticketing workflow into ChargeLync would significantly expand the scope.

I reframed the requirement: operators did not need all of Zoho inside ChargeLync. They needed to know whether the issue had already been reported, whether someone owned it, and whether field work was underway.

The final solution surfaced ticket counts, recent station-specific links, and work orders while keeping Zoho as the system of record.

From raw activity to focused evidence

Operators could arrive through an exact O&M event or open Real-Time Logs directly to investigate broader station activity.

Time ranges and event filters helped them isolate connection changes, errors, transactions, and heartbeat messages before opening the technical detail. Raw OCPP requests and responses remained available when deeper evidence was needed.

Commands remained a separate action. After sending a reset or remote transaction, operators returned to the logs to verify the response and confirm that heartbeats continued.

How the workflow comes together

The Station Overview and Real-Time Logs helped operators investigate an issue, decide whether a command was needed, verify the outcome, and update the ticket.

Testing the complete workflow

We evaluated the redesign through moderated usability testing with five operations-team members.

Everyone completed the same realistic scenario:

“Station 24PO went offline yesterday. Determine if you need to dispatch a technician.”

We compared how long operators took to complete the scenario using the original and redesigned workflows.

During the first three months after launch, Operations tracked approximately 15% fewer support tickets. I treat that as a supporting business outcome—not a claim that the redesign alone caused the reduction.

Collaboration through delivery

Operations helped identify which station signals supported remote action versus field support. Product helped prioritize the highest-value parts of the workflow. Engineering clarified the history, data, time ranges, and filtering behavior that could be supported reliably.

I documented interaction states and implementation behavior in Figma, linked the work through assigned GitHub issues, answered engineering questions, and completed design QA after implementation.

What I learned

• Solving triage did not automatically solve diagnosis. Operators needed different levels of information at each stage.

• Information hierarchy worked best when it followed the operator’s decision—not the platform’s underlying data sources.

• Influence did not mean getting my original Zoho proposal approved. Reframing the requirement produced a smaller solution that still solved the central problem.