Operational tooling for CPOs to monitor asset health, dispatch field work, and reduce downtime
End-to-end EV charger lifecycle platform across web ops and field mobile
EV charging reliability is an operations problem: installation quality, proactive maintenance, and fast field resolution. Most CPO teams run these workflows across fragmented tools and reactive processes, which turns downtime into the default.
Iris r-one was designed as a unified lifecycle management platform connecting central operations (web) and field technicians (mobile) into one operational system.
TIMELINE
Jun 2024 – Jul 2025 (12 months)
ROLE
Product Designer
(end-to-end across web + mobile)
PLATFORM
Web ops console + field technician mobile app
SCOPE
Lifecycle workflows, IA, alerting and prioritisation, work management, technician execution flows, design system and handoff
What changed operationally
These outcomes reflect day to day operational changes after adoption. Iris r-one improved how teams plan, execute, and close work across web ops and field mobile, which drove the directional impact reported by the company across live operations.
The operational breakdown
Reliability was limited by workflow design, not effort
As EV networks scale, each charger becomes a live asset with its own failure patterns, maintenance history, parts dependencies, and compliance requirements. The recurring failure mode wasn’t a lack of tools. It was the lack of a single operating model that connects monitoring, decisions, and field execution.
No shared operational truth: health signals, work history, and parts lived in different places.
Reactive maintenance dominated: faults were handled after failure, extending downtime.
Planning and field execution were disconnected: technicians arrived without diagnostic context, driving revisits.
Operational reality
Two teams, one system, very different environments
I designed R-one for two user groups who share the same operational goals but work under different constraints. The web experience had to optimise triage and coordination. The mobile experience had to optimise execution quality under time pressure.
System design
One shared operating model across web and mobile
Instead of designing features in isolation, I defined a shared operational model that both platforms reference. Assets, alerts, work, inventory, and proof of work all map back to one lifecycle timeline. This is what kept the product coherent as scope expanded.
Web optimizes decision speed: prioritize, assign, track.
Mobile optimizes execution quality: guided steps and evidence capture.
Both update the same state: teams stay synchronized in real time.
Key solutions
Designing the lifecycle loop: detect → decide → dispatch → resolve → learn
1) Predictive maintenance and R-score
Reducing cognitive load before commitment
Problem
Health data existed, but teams couldn’t reliably answer one question: what should we fix next.
Design Move
A unified health layer using R-score, combining telemetry and operational signals into an actionable prioritisation metric. Alerts were structured for triage using severity, confidence, and recommended next steps.
Why It Matters
Monitoring becomes decision-ready. Instead of scanning raw logs, ops teams get a ranked view of risk and can allocate field capacity to prevent failures before they become downtime.
2) Web ops console: triage → plan → assign
From implied credibility to visible signals
Problem
Central teams coordinated work across fragmented tools, causing slow prioritisation and inconsistent decisions.
Design Move
I structured the web console around one operational loop: detect → prioritise → create work → assign → track closure → review outcomes. Navigation reflects lifecycle stages rather than feature buckets.
Why It Matters
It reduces decision friction. Planners can see what matters, create the right work quickly, and assign based on real capacity and risk.
3) Technician mobile: guided execution with context
Reducing hesitation through predictable pathways
Problem
Technicians arrived without enough diagnostic context, driving longer fixes and repeat visits.
Design Move
I designed the mobile app as a guided execution tool: clear task intent, asset context (history + recent alerts), structured steps, fast evidence capture, and validated closure.
Why It Matters
It lowers cognitive load on-site and standardises execution quality across technicians, improving first-time fix rates and evidence completeness.
4) Installation and lifecycle standardization
Designing for evaluation, not just browsing
Problem
Installation quality is high variance. Missing steps during install show up later as faults, revisits, and safety risk.
Design Shift
I standardised installation into Workpack Group → Workpack → Checklist, with explicit completion states and audit evidence. Installation data feeds future maintenance so early quality becomes diagnosable later.
Why It Matters
It reduces downstream chaos. Ops teams get a traceable baseline for every asset, and technicians get a consistent execution path.
Impact
Shifting from reactive maintenance to lifecycle operations
R-one changed how teams operated. Maintenance moved from after-the-fact fixes to risk-based planning, and field execution moved from ad-hoc resolution to guided workflows with proof of work.
Better prioritisation reduced revisits and cost
Earlier intervention reduced downtime windows
Standardised installation reduced variance and rework
Field workflows improved closure quality and speed
How we measured success
Measuring reliability, not feature adoption
These workflows weren’t redesigned to look cleaner. They were redesigned to change day-to-day operations: faster triage, fewer repeat visits, higher first-time fix rates, and a tighter loop between planning and field execution. Validation focused on whether the system reduced time lost to coordination and rework, and whether network reliability improved as teams scaled.
Learnings
What this project changed for me
This project reinforced that adoption is rarely a feature problem. It is a confidence problem. Users didn’t need more functionality, they needed clearer signals at the exact moments where commitment happens. Designing for early-stage products means balancing optimism with credibility, because every interaction either increases trust or erodes it.
Explainability drives action: predictive systems only work when users understand why
Design for decision moments: trust cues must appear where commitment happens
Operational UX is systems UX: coherence comes from shared objects and states, not screens