Giving charging networks their own data
Chargemap Partners · Product Designer · 2026
NDA Written case study. The reasoning is public; the screens aren’t.
Context
Chargemap Partners already gave charging networks two levers on their presence in the app: how they showed up, and what they could promote. It gave them nothing to look at. Chargemap accumulates a large amount of usage data — from the consumer app on iOS and Android, and from the B2B product — and the networks whose points generate it had no real access to any of it.
They weren’t short of a report. They were short of a way to ask a question. Whether a station was underperforming, how drivers behaved around it, what a journey through the consumer app looked like before someone arrived at a point — none of that was answerable on their side.
The brief came from the product manager and the Head of Product, and the ambition predated me: data had been announced to the networks as the missing axis of Partners before I arrived. The request was dashboards. The problem underneath was that nobody knew which of this data these networks would actually use, and when you hold that much of it the tempting move is to publish everything and call it a product.
Scope
I owned the design end to end — the workshops, the prototypes, the screens and the shape of the delivery. I did not own what data existed, nor when the feature had been promised; both were set before I arrived.
- Surface
- The analytics section of Chargemap Partners: three themed dashboards covering station performance, user behaviour, and the journey through the consumer app. Internally the project was the data pack; Insight is the name I gave the tab users actually see.
- Team
- A pair with the product manager for the whole run, from the workshops to the prototypes. A front-end developer took the handoff and pushed to an environment the entire company could open, which is where most of the feedback came from. Sequencing — which dashboard shipped when — was a product call, not mine.
- Constraints
- What could be shown was bounded by what the products already record: this was never a project that could ask for new instrumentation. Access is limited to networks under a partnership contract, so the feature reaches a small, expert audience rather than a general one.
- Mandate
- I was asked for dashboards. What I added was the shape of the delivery: each dashboard was cut into versions in Figma — a first pass of three KPI cards, then a graph of station performance over time, then a table listing the estate — and that sequence was agreed with the developers before anything was built.
The tradeoff
I wanted the data to carry the action. A network that opens a dashboard and reads that a set of stations is underperforming is one step away from doing something about it, and Partners already held the campaign tooling in the next tab. Showing the problem and owning the remedy in the same product, and leaving them unconnected, is stopping halfway.
It didn’t ship that way, and that was the plan rather than a concession. The feature was cut in two from the outset: a first version that shows a network its numbers, a second that lets it act on them. Getting something the networks could open mattered more than getting the whole idea out, and the actionable half was the part that could wait without making the first half useless.
What shipped is three dashboards that are read‑only. The network sees the numbers and does the interpretation itself, in its own head, against its own assumptions about its own estate. That is the cost and it is a real one: an operator can read a dip as a hardware problem when it is a pricing problem, or the reverse, and nothing in the product stops them. Read‑only is not a neutral state. It moves the risk of being wrong onto the customer, quietly, while looking like restraint.
I’d make the same call. A dashboard nobody opens hasn’t earned the right to tell anyone what to do, and the fastest way to learn whether these were the right numbers was to put them in front of the networks that had asked for them. What would have changed my answer is the gap between the two halves. The longer a network interprets alone, the more its own reading hardens into the one it trusts — and a product that turns up later with a different opinion has to argue with a habit it created.
Outcome
What changed is where the first draft came from. The product manager and I started prototyping with an LLM before anything was designed, which gave us something clickable to put in front of developers, and then in front of networks, while the design was still open. It did not remove the design phase: the model has neither our context nor our design system, so it returned flows that didn’t fit the product and components close enough to be misleading — the right colours, the wrong radii, patterns we don’t use. The gain was real anyway, and it came from moving the first conversation earlier rather than from skipping a step.
The versioning did the rest. Because each dashboard was cut into a first, second and third pass before anything was built, the developers were never waiting on a finished design and neither of us ever had to defend a whole feature at once. What it didn’t fix is the thing the tradeoff bought time on: the numbers still don’t do anything, and the network still carries the interpretation. Closing that is the next piece of work, and until it lands the honest description of Insight is that it tells a network where to look, not what to do.
This work is under NDA, so there are no screens here. The reasoning is the part that matters, and that part is on the page. The screens and the walkthrough I’ll go through with you in a call.