Designing EV Charging
inside MyMotor

The goal was to bring EV charging into MyMotor as a feature, not as a standalone product. Every serious EV charging app on the market is exactly that: an entire application whose sole reason to exist is finding a charger and paying for a session. MyMotor was proposing something different. Charging would sit alongside everything else the app already did, one module among many, sharing space with the rest of a vehicle owner’s life.

That framing shaped every decision that followed. A standalone charging app can demand the user’s full attention and assume charging is the reason they opened the app. A feature cannot. It has to earn its place, orient a user quickly, and get out of the way. The work spanned the full arc: the initial go or no-go decision, competitive and user research, journey mapping with the product manager, the core design challenge of charger discovery on a map, the end-to-end charging flow with its edge cases, a set of supporting components, onboarding, developer handoff, and post-launch monitoring.

Before a single screen was sketched, the team sat with the uncomfortable first question. Not “how do we build EV charging,” but “should we build it at all, and why us?”

The skeptical case was strong. The competitors who owned EV charging in the B2C space were pure-play charging apps. That was their entire product, their entire team, their entire roadmap. MyMotor would be adding charging as one feature inside a broad app, competing on a surface where rivals were spending everything they had. It is a reasonable place to hesitate.

So the team did the unglamorous thing and listed the pros and cons out loud, weighing the business goals against the user need rather than falling in love with the idea. Several threads converged on a yes.

The first was strategic segmentation. MyMotor served vehicle owners broadly, but EV owners were a distinct, growing, and underserved segment. Charging was the single most frequent, most emotionally charged interaction an EV owner has with their vehicle. Owning that moment meant owning a relationship with a user segment the product wanted to go deep on, rather than serve at arm’s length.

The second was retention. Charging is not a once-a-year event like renewing insurance. It is a weekly, sometimes daily, ritual. A feature a user returns to that often is a retention engine, a reason to keep the app on the home screen and open it out of habit rather than obligation. For a product that mostly handled infrequent administrative tasks, a high-frequency reason to return was valuable on its own terms.

The third was a real, unsolved experience gap. The market was full of charging apps, and it was also full of frustrated charging users. The pain was not that charging apps did not exist. The pain was that using them was tiring, fragmented, and anxiety-inducing. There was room to do it better, and doing it better inside an app users already trusted for the rest of their vehicle life was a genuine advantage, not a handicap.

The verdict was to proceed. Not because EV charging was fashionable, but because it served the business, captured a priority segment in depth, built durable retention, and answered a pain point the market had left open.

The work described here was led end to end by a single experience and product designer, in close partnership with the product manager and, later, the engineering and QA teams. The scope covered problem framing, competitive research, primary user research, journey and flow mapping, interaction and visual design across every screen in the module, prototyping, stakeholder presentation, developer handoff with technical and analytics annotations, and post-launch metric monitoring.

The module was not a single screen. It was a full sub-product living inside a larger app: a discovery experience, a session lifecycle, a wallet, a history, a partner network directory, an educational guide, and an onboarding journey. The challenge was to design all of it to feel like one coherent feature that still belonged to MyMotor.

With the decision made, the work turned to understanding the territory before touching it. This split into two distinct research efforts, one outward and one inward.

Mapping the competitive landscape

The outward effort was a systematic sweep of the existing charging apps. The designer catalogued what was in the market, what each product treated as its core, and what type of charging app each one was, because “EV charging app” is not one thing. Some were charge point operator apps tied to a single network. Some were aggregators stitching many networks together. Some were roaming or payment layers. Each type carried its own assumptions and its own failure modes.

For each, the work went past surface features into experience. What did the journey actually feel like? Where did it delight, and where did it grind? User reviews were mined not for star ratings but for the recurring emotional language underneath them, the specific frustrations people returned to again and again. Journeys were walked and mapped. The good was noted as carefully as the bad, because a case study of competitors is not about mockery, it is about learning what to keep.

Out of this came a body of insight, and insight is only useful once it is ordered. Every finding was sorted by priority: which pains were major, load-bearing frustrations that had to be solved first, and which were minor irritations that could wait for a second pass. That prioritisation, deciding what to solve now versus later, is where research stops being a document and starts being a plan.

Talking to the actual users

The inward effort was more valuable and harder to fake. MyMotor already had users who were EV owners and had added an EV to their in-app Garage. The designer called them.

Not a survey. Actual conversations. How did they come across MyMotor in the first place? How had their experience with the app been so far? Then, the real subject: how did charging feel for them today? Which apps did they use? What was the one thing those apps were missing, the thing they wished someone would just fix? These are the questions that surface the gap between what a user tolerates and what they actually want, and they only come out in a conversation where a real person is listening. Good UX research methods are not about volume, they are about reaching the underlying problem, and a handful of honest phone calls with real users often does that better than a thousand anonymous responses.

The insights from these calls were mind-mapped, cross-referenced against the competitive findings, and folded into the same prioritised picture. By the end, the designer was not staring at a blank canvas. There was a clear, ordered view of what mattered most to the people who would actually use this, and why.

With research in hand, the next move was deliberately not to design a screen. It was to sit down with the product manager and map the journey, first from a broad scope, then through a deeper lens.

The broad pass asked how this module fit into MyMotor as a whole. Where did a user enter it? What was indirectly tied to it, the parts of the app that touched charging without being charging? How would the big-picture journey of the entire module read, start to finish, if you zoomed all the way out?

The deep pass went the other way, drilling into each sub-module and drawing the flows inside it. Every touchpoint was drawn out: where a user would land, what decisions they faced, what could go right, and where the journey could fork or fail. This is the layer where the shape of the product is actually decided, long before anything is visually designed. Getting the journey right with the product manager first meant every later screen had a place to live and a reason to exist.

Every module has a moment that carries disproportionate weight. In EV charging, it is discovery: the map, the pins, the act of finding the right charger. This is where a user spends the most time and the most emotional energy. Everything else in the flow is comparatively mechanical. Discovery is where the anxiety lives, and it was the thing that had to be cracked first.

So before sketching a single variation of the map, the designer stopped and asked a more basic question, borrowed from psychology rather than interface design: what is the very first thing a user’s mind needs to know when it looks at this map?

Strip away the product and put yourself in the driver’s seat. You are low on charge, or planning ahead, and slightly on edge.

Your brain is not admiring the map. It is running a fast, anxious filter with two questions above all others. First, which charger near me is actually available right now, not occupied, not broken, available. Second, does it charge at a speed my specific vehicle can accept, fast enough to be worth stopping for. Availability and compatible speed. Everything else is secondary to those two.

That psychological insight, understanding the need beneath the want, became the design principle for the entire discovery experience. The user was not asking for more map features. They needed to answer two questions in under a few seconds and feel calmer for it. So the sketches and mid-fidelity designs for the map and the location pins were built to answer those two questions instantly, before the user even consciously formed them. The pin itself had to carry availability and speed at a glance, because that is what the mind reaches for first.

Only once that was cracked did the work move into designing and prototyping the discovery experience in full: the map, the location pins, search, filter, and the detail view that appears when a user selects a charger’s pin. Two variations were built and presented to stakeholders. One was finalised, and it became the foundation for everything downstream.

With discovery settled, the flow was built in sequence, each stage picked up only after the previous one was resolved. Designing a lifecycle in order, rather than all at once, keeps each decision honest, because every screen has to hand off cleanly to the one after it.

Step one: discovery

Already described above, this was the entry point. Find a charger, understand its availability and speed at a glance, search and filter to narrow the field, and open a selected charger’s details to commit. The finalised variation carried the whole module’s tone.

Step two: initialising the session

Once a user chose a station, the flow moved into setup. Here the user tells the app three things in sequence: which gun, or connector, they have physically plugged into their car, which vehicle they are charging, and how much they want to charge for, whether measured in units or in amount. Each of these is a small decision, and each was designed to be unambiguous, because a mistake here means charging the wrong car, the wrong way, for the wrong amount.

Step three: the active session

Next came beginning the charge and the live, active session experience. This is the anxious middle, where the user has committed and now waits. It was designed for both the normal path and its edge cases, because charging hardware fails in ways software rarely does. A gun that will not lock, a session that will not start, a connection that drops, a charger that reports a fault mid-session. The normal case is easy to design. The value was in mapping and handling the cases where the real world does not cooperate.

Step four: after the session

When charging completes, the experience does not just stop. The designer worked through the closing arc: the session summary, the invoice, the email template that lands in the user’s inbox, and the collection of feedback on the session that just happened. This closing moment is where trust is either confirmed or quietly eroded, so it was treated as a first-class part of the flow rather than an afterthought.

Beyond the linear charging flow, the module contained several components that lived as their own destinations inside it. Each was designed as a self-contained piece that still belonged to the whole.

These are the components that make a feature feel complete rather than minimal. A charging flow without a wallet, a history, and a way to understand the network is technically functional and practically frustrating.

A feature this large, dropped into an existing app, cannot simply appear. It has to be introduced.

The designer added an opening animation that plays when the feature is launched, giving the module a sense of arrival and identity within MyMotor. For first-time users, a four-slide onboarding journey explained the feature end to end, orienting someone who had never charged through the app before they were dropped into a live map with anxiety already running. The goal was for a first-time user to understand what this was and how it worked before they needed it, not during the stressful moment when they were low on charge and learning the interface for the first time.

Design that never ships is just art. Getting this to production meant a rigorous handoff, and the handoff itself was designed.

First came review. The full module was walked through with product, tech, and stakeholders together, and only after that go-ahead did the handoff work begin. Waiting for alignment before annotating everything avoided annotating things that were about to change.

Then the designs were prepared for engineering with genuine care. Technical and QA notes were added throughout. Elements were annotated so that the developers, and the tools they use to accelerate their work, could pick up intent without guessing. Crucially, the analytics events that needed to be captured were annotated directly in the design: screen names, button clicks, and the other events the team would later need to understand how the feature performed in the wild. Designing the measurement into the handoff, rather than bolting it on after launch, is what made the post-launch monitoring possible at all.

Finally, the work was broken into JIRA tickets covering everything designed, with the relevant Figma design link attached to each task and sub-task, so no engineer ever had to hunt for the source of truth. This kind of close, legible collaboration between the designer, the product manager, and engineers is usually the difference between a design that ships as intended and one that quietly degrades on the way to production. With the tickets prepared and linked, the designs were handed to the developers.

For many teams, launch is the finish line. Here it was the start of a different phase.

Because the analytics events had been designed into the feature from the handoff, the funnels and conversion metrics were legible from day one. After the feature went live, the designer monitored them regularly, watching where users flowed smoothly and where they hesitated or dropped. The point of watching was action: identifying, on an ongoing basis, what was breaking in the real experience and solving it one issue at a time, then going further still. A shipped feature is a hypothesis meeting reality, and the reality of charging, with its dependence on physical hardware across many partner networks, was never going to be fully predictable from a prototype.

Because this feature launched inside a live commercial product, the specific numbers stay qualitative here, but the shape of the outcome is clear.

MyMotor gained a genuine reason for its highest-priority segment, EV owners, to return frequently, converting an app of infrequent administrative tasks into one with a weekly, habit-forming ritual at its core. The charging experience was built around the two questions a driver’s mind actually asks, availability and compatible speed, which is precisely the anxiety the market’s existing apps had left unresolved. The feature shipped as a coherent module, complete with the wallet, history, network directory, and onboarding that make a feature feel finished rather than minimal. And because measurement was designed in from the start, the team could keep improving it against real behaviour rather than opinion, closing the loop between what was designed and what users actually did.

Several lessons ran through the whole project and are worth naming on their own.

The EV charging module inside MyMotor is, on the surface, a map, a few pins, a payment flow, and a receipt. Underneath, it is the result of refusing to skip the hard questions: whether the feature should exist, who it was really for, what those users’ minds were actually doing when they opened the map, and how the whole thing would be measured and improved once it met reality.

That is the throughline of the work. Not the screens, but the reasoning that produced them, in service of the human experience of a slightly anxious driver trying to answer two simple questions before their battery runs low. A dedicated charging app could out-feature this module any day. What it could not do was make charging feel like a natural part of a life the user already managed in one place. That was the point, and that was the design.