Self-serve admin design for enterprise customers, embedded with engineering through build and design QA, replacing an expert-only setup with a workflow anyone can run.
Activation flow
Role
Lead UX UI designer
Scope
B2B SaaS · Enterprise
Duration
1 year · 4 iterations
1. Overview
ChargePoint runs one of the world's largest EV charging networks, spanning over 1.3 million ports across enterprise customers, property managers, and fleet operators. Polaris Suite gave Org Admins their first self-serve activation flow, so they could get stations live without leaning on a support team for every deployment.
The flow had to work across three very different B2B realities: a first-time site setup, a single-station expansion, and a multi-site rollout of hundreds of stations at once. I led this through four iterations over the course of a year.
Before you read
Who's in the room
Activation is a deeply technical domain, so a quick orientation on the people and the systems in this story.
The systems
ChargePoint runs three legacy platforms - NOS, be.ENERGISED, and Viriciti - each built for a different generation of hardware. Polaris Suite is the new SaaS platform meant to eventually replace them.
Around all four sit field tools: the Installer Mobile App (where technicians capture data on-site), Pinpoint Portal (GPS), and Salesforce (the source of truth for what a customer actually bought).
The people
-
Org Admin - the customer's own operations person. The main user this flow is being built for.
-
Deployment Specialist / CX - ChargePoint internal staff who do most activations today, on behalf of customers.
-
NOC operator - ChargePoint's network admins, who handle activation at fleet scale across many customers.
2. Pain points
1. Fragmented across three systems
Installing 10 stations at the same location meant running the same flow 10 times. Every station was a standalone task.
2. No bulk workflow
Activating 10 stations meant repeating the same flow 10 times. There was no way to apply a shared configuration across a site deployment.
3. Disconnected from the installer ecosystem
The Installer Mobile App and tools like Pinpoint Portal and Salesforce operated in silos. Field data captured during installation wasn't connected to the activation flow.
4. Plan selection required expert knowledge
Cloud plan and policy selection required domain expertise most Org Admins didn't have - with no recommendations based on their use case or customer segment.
3. Why it mattered?
< 40%
CX activation tickets estimated to be eliminated through self-serve.
3–5 days
average time from hardware install to station live, before self-serve.
same day
target time-to-live with self-serve activation via Polaris Suite
What I walked into...
-
I joined ChargePoint a few weeks before the MVP shipped. The activation project had been scoped as a single large work stream with one big handoff at the end and a hard deadline tied to a stakeholder workshop. That shape was workable for shipping one MVP, but it didn't leave much room for what I knew would actually happen - multiple iterations, each one reshaping the assumptions of the last.
-
Over the next few quarters I pushed for the work to be split into smaller, topic-scoped workflows with their own dev handoffs. The four iterations below are the result of that restructuring. Each one was small enough to be designed, tested, and shipped without losing the thread between them.
4. Ideation & iteration
Iteration 1
Iteration 1 · MVP
A three-step wizard for the simplest case -
single stations, one site, default everything.
Before Polaris Suite, every activation ran through a ChargePoint Deployment Specialist: activation form, email, wait, confirm. The MVP compressed that into something an Org Admin could do themselves - a Charger Management view with an "Activate Stations" banner, a Ready-for-Activation list grouped by model family and site address, and a three-step wizard (Org & Plan, Energy Management, Summary).
I chose a wizard over a single form deliberately. Activation involves choices most Org Admins have never made before - cloud plans, warranties, energy management groups - and a flat form would have surfaced all of them at once. Three steps with sensible defaults meant a first-time user could finish by mostly clicking "Next."
UAT · round 1
UAT validated the speed but not the experience. The 4.5/5 score was misleading me, experienced specialists could finish the task because they already knew the data model, so of course they were fast. What they validated was efficiency for experts, not learnability for new users.
They also surfaced two gaps:
4.5/ 5
Overall rating
< 5 min
Avg. activation time
-
Bulk activation didn't exist yet (everyone asked "now how do I do fifty?")
-
Token validity timing - sales order vs. activation date - was opaque from the UI. Both went straight into Iteration 02.
Iteration 2
Phase 2
From single-station to fleet-scale: bulk activation and recovery as a first-class state.
The MVP handled single stations cleanly but broke down at scale, and the first three customer rollouts confirmed it: real deployments are fleets, not stations. This iteration was about making the wizard fluent in bulk.
-
I added Copy / Import Configuration so an admin could reuse the plan, policy, and group settings from an already-activated station: the round's biggest time-saver.
-
I added an Advanced Token selection view so users could see and edit the sales order, start date, end date, and purchase order behind each token, fixing the Iteration 01 ambiguity. And I added a token mismatch recovery dialog for the most common bulk-activation failure.
-
The recovery dialog was the call I'd most want to defend. Two of three Phase 1 customers had silently hit the token mismatch path and assumed the product was broken: they didn't know they'd hit a recoverable error, because the system had been treating failure as a dead end. Designing recovery as a first-class state, with a clear "here's what went wrong, here's how to fix it" surface, was a small UI change but a meaningful mental-model shift for the flow.
UAT · round 2
-
Bulk activation and copy-config landed strongly.
-
Round 2 validated the bulk patterns but surfaced a sharper, more operational gap: Iteration 03 would have to reckon with both.
-
Editing a station mid-wizard blew away the user's progress, forcing them to start over.
-
It also flagged that the flow was still treating activation as a setup task, when for NOS-style technical stations - DC clusters, gateways, pinpointing dependencies - activation is really a fleet management task with prerequisites the UI was hiding.
Iteration 3
Porting the flow into NOS and meeting the silent failure modes Polaris had been quietly ignoring.
Porting the flow into NOS forced a reckoning. The NOS hardware ecosystem - DC fast chargers, gateway devices, larger commissioning dependencies - had three failure modes that Polaris's lighter hardware never really exposed: a station could be physically installed but not yet commissioned by an engineer, the gateway it relied on could be missing or offline, or its GPS pinpointing could still be pending. In all three cases, an operator could happily run the wizard end-to-end and only discover at the end that activation was never going to work.
UAT · round 3
Internal feedback from CX, support engineers, enterprise users, and deployment supervisors was strongly positive.
"The DC blocker banner alone saves us a support ticket every other day." - CX lead, internal review
One structural gap remained:
Multi-port and cluster stations still rendered as a flat list. A 13-port DC station was technically activatable, but operators couldn't see parent-child structure or trace a fault back to the dispenser it came from.
Phase 4 - currently rolling out, extends the same row-level visibility into cluster hardware - nesting each child port under its parent Chargebox so a fleet of clusters reads as a glanceable hierarchy instead of a hundred-row scroll.
(full impact is being measured.)
5. Design QA & Defect Resolution
Once the build started, I ran design QA against the dev builds - reviewing implementations against spec, logging defects in Jira, and driving resolution with engineering before release. This wasn't handoff-and-leave; I stayed embedded through build and triaged design defects as a first-class engineering work stream, not a "polish pass" at the end.
Outcome: design defects caught and resolved pre-release rather than post-launch, reducing the design debt that usually accumulates between handoff and ship.
6. The lessons that survived every iteration.
Each iteration forced me to release an assumption I'd been designing around. The belief that org identity had to be resolved at install time drove the first design into fragility. Letting go of that assumption made everything simpler and more robust. That pattern - finding the locked assumption, not just the surface problem - was the through-line across both rounds.
1. Handoff doesn't have to end at Figma file.
Between Phase 3 and Phase 4, I started running QA passes on the dev builds myself - clicking through every state, breaking the flow on purpose, logging tickets directly to the engineers. It saved a full round of CX escalations and gave me much sharper instincts about which edge cases mattered. The handoff doesn't end at the Figma file.
2. Stay close to support.
The most valuable feedback didn't come from formal UAT - it came from CX and deployment specialists DMing me about what was annoying them this week. Phase 3's pre-activation signals existed because someone in support told me they were tired of getting tickets for the same three failure modes. That kind of insight doesn't show up in a research plan.
3. Scope shape is a design problem too.
The original project was scoped as one big work stream with one big handoff. That shape forced a single all-or-nothing UAT at the end and left no room for the design to change between iterations. Over the next few quarters I pushed to split the work into topic-scoped workflows - bulk activation, NOS port, clusters - each with its own scope, its own deadline and its own internal testing.
7. The bigger picture
I didn't just design the field tool -
I designed what it feeds into.
The activation flow is not where this story starts. It starts in the field, with an electrician scanning a serial number into the Installer App. Everything the org admin sees in Polaris Suite - the station appearing in their queue, the pre-assigned org, the regional activation link - depends on data that was captured upstream, in a product I also designed.
Owning both sides of that handoff meant I could close the gaps that had been invisible when the two products were designed separately. The integration wasn't a feature, it was the design decision that made self-serve possible at all.
Over four iterations and a year, this project also changed how I think about scope. The original single-stream structure would have produced one big handoff and no room to respond to what each round of UAT surfaced. Splitting it into topic-scoped workflows - each with its own dev handoff and its own testing - was as much a design decision as any screen I shipped.
