Everyone who's ever driven a gas car already knows how to use one. Watch the gauge, find a station when it's low, insert the pump, pay, done. It's a mental model that took decades to settle, and it's so automatic most drivers don't think about it at all.
Electric vehicles quietly break that model in three separate places. Finding a charger is less predictable than finding a gas station, since availability fluctuates and the network is thinner. The actual charging process takes meaningfully longer than refueling, even with fast charging. And payment gets complicated fast, since different charging networks run their own cards, apps, and billing systems rather than one universal method. None of this is exotic knowledge to an experienced EV owner. To someone who just switched from a combustion car, it's a genuinely confusing new system layered on top of an old habit they haven't unlearned yet.
That gap, between what a new EV driver expects and what actually happens at a charger, is exactly what Project XCeed set out to close. Built by a small team at Hochschule der Medien in collaboration with Mercedes-Benz, the project's core idea was a voice assistant built directly into the vehicle's charging port, one that adjusts its guidance based on how experienced the person plugging in actually is.
Different Drivers, Different Mental Models
Before designing anything, the team looked at how people's mental models actually shift once they move from a gas car to an EV, and a University of Delaware study on EV charging behavior turned out to map the territory well. It identified three distinct driver types, and they aren't just experience levels, they're genuinely different mental frameworks for the same task.
Inexperienced owners tend to carry their old mental model over more or less directly. To them, the charging symbol works the same way a fuel gauge always did: watch it, and once it's low, go find somewhere to charge. Long-distance drivers, by contrast, plan their charging stops ahead of time, factoring range and station availability into a route the way you'd plan a road trip with limited gas stations in mountainous terrain. And experienced daily drivers eventually settle into something new entirely, an event-based habit where charging happens automatically whenever the car is parked somewhere with a plug, rather than being triggered by a low battery reading at all.
That range of mental models is precisely why a single, one-size-fits-all onboarding flow doesn't work well here. A newcomer needs the fuel-gauge metaphor explained gently. A long-distance planner needs range and routing information front and center. A daily driver mostly just needs the system to stay out of their way. Good onboarding UX, as the team framed it, comes down to three things: actually knowing your target group and what they need, identifying the key actions that matter most for using the product and building onboarding around those specifically, and picking the right medium for how a given user actually learns, whether that's video, text, sound, or simple trial and error.
The Idea: A Charging Assistant That Talks Back
XCeed's answer to all of this was a personal voice charging assistant embedded right where the interaction actually happens: the charging port itself. Rather than a menu-driven app or a static instruction sheet, the assistant listens and responds in natural conversation, adjusting both what it says and how much it explains based on the driver's apparent skill level.
Four core functionalities anchored the concept. It helps with problems as they come up in the moment, rather than requiring someone to dig through a manual. It draws on smart data, contextual information like current charging speed, cost, or grid mix, to give genuinely useful answers rather than generic ones. It adapts its level of explanation to the user, whether that means walking a first-timer through terminology or getting straight to the point with someone who's clearly done this before. And it provides information proactively, surfacing exactly the kind of detail a driver would otherwise have to hunt for.
To ground the concept in something concrete, the team built a persona: Anna Scherer, 32, an environmental consultant who switched from a VW Polo to an EV about four months prior, motivated largely by sustainability concerns. She's not a total beginner (colleagues and friends already own EVs, so she picked up some basics in advance) but she still runs into friction with unfamiliar charging stations on trips, and she genuinely cares about optimizing her charging around renewable electricity, not just plugging in and walking away.
A short user story built around Anna shows the intended experience in practice. Parked at an unfamiliar public charger before a group heads into a cafe, she asks the assistant how much charge she'll have in an hour, and gets a direct, useful answer, including confirmation that it'll be enough to reach her destination with margin to spare. When she returns, the assistant reports the final charge level and cost, and when she asks specifically whether the electricity was sourced sustainably, it answers that too, based on live grid mix data. Nothing about that interaction requires her to know charging station terminology, dig through an app, or interpret a confusing terminal display. It's just a conversation.
Prototyping: From API Assistant to Native Voice
Getting from that concept to a working prototype meant piecing together a fairly standard modern voice pipeline: speech-to-text to capture what the driver says, a large language model to actually reason about the request and generate a response, and text-to-speech to speak that response back. On the hardware side, the team tested across phones, laptops, and a Raspberry Pi, evaluating models and tools from OpenAI, AWS, Google, and Meta along the way.
The first working prototype ran on OpenAI's Assistant API, which offered a genuinely useful feature set for this kind of task: a customized version of ChatGPT tuned for a specific purpose, the ability to call multiple tools in parallel including both OpenAI's built-in file search and self-hosted functions via function calling, persistent threads that retain conversation history and context per user, and the ability to reference files in various formats when generating a response. On paper, that combination covered most of what a charging assistant would need.
In practice, it ran into a real problem: latency. Every voice interaction required a chain of separate API calls, speech-to-text, the assistant's own reasoning and any knowledge retrieval it needed, then text-to-speech again, and that chain added up to response times that fluctuated and, at points, ran uncomfortably long for a conversational interface. Voice control itself was also harder to get right than expected, and at the time, it wasn't clear when the full range of GPT-4o's native capabilities would actually become available through the API rather than staying locked to OpenAI's own consumer apps.
That pushed the team toward a second prototype built directly on native GPT-4o voice chat, at the time available only through OpenAI's Mac desktop application or its native smartphone app. The difference was immediately noticeable: latency dropped enough that the interaction genuinely felt like talking directly to the assistant rather than waiting on a pipeline, and the voice stream did a solid job of recognizing when the user had actually finished speaking and the input should be sent. To simulate the intended experience of the assistant adapting to different user levels without having that adaptation logic actually built yet, the team used a Wizard of Oz approach, manually switching between differently configured custom GPTs by hand after the onboarding step, so participants experienced something close to the real adaptive behavior even though a human was quietly swapping assistants behind the scenes.
Putting It in Front of Real Users
With a working prototype in hand, the team ran a user study at a university Media Night event, recruiting ten participants through a structured flow: a pre-questionnaire to capture background and experience level, a set of realistic test cases performed with the actual prototype, evaluation using the Short UEQ (User Experience Questionnaire) alongside CTAM (a technology acceptance measure), and a closing interview for qualitative reactions.
The test scenarios were deliberately built around a single continuous narrative rather than isolated tasks. Participants started with the onboarding conversation itself, meant to place them into an appropriate experience level and teach them how to actually invoke and use the assistant going forward. From there, they worked through a realistic sequence: arriving low on charge and needing to figure out whether they had enough range left to get home, discovering their charging card wasn't being accepted at the terminal and needing the assistant's help diagnosing and resolving that, and finally checking the cost of a completed charging session and comparing it against what the same trip would have cost with a gasoline car.
The ten participants were a mixed but small group: four women and six men, ages 22 to 63 with an average of 33, all with an academic background. Eight of ten had some prior charging experience, though only four actually owned an EV themselves, averaging about two years of ownership. By the team's own classification, three participants counted as unexperienced, five as intermediate, and two as experts. It's worth being upfront about the obvious limitation here: a sample of ten, skewed toward one educational background, is nowhere near large enough to generalize confidently, and the team flagged that limitation explicitly rather than overselling the results.
What the Numbers, and the Quotes, Actually Said
Across the Short UEQ's paired dimensions, the results were mostly positive with one clear exception. The assistant scored 0.9 on the supportive/obstructive scale, landing as "rather supportive," with participants specifically praising how it responded well to their questions and quickly surfaced the information they needed, though a couple of unexperienced users noted some answers felt partly generic. On the complicated/easy dimension, it scored a strong 1.5, "really easy," with users highlighting how little typing was involved and how direct the interaction felt compared to hunting through buttons and menus, and both usability-related statements in the questionnaire landed at "strongly agree."
Clarity came in at 0.9, "rather clear," with most participants reporting no misunderstandings at all and several specifically praising the accuracy of the answers they got, though a couple of participants did report trouble understanding a specific response or being unsure whether the assistant was still listening. The excitement dimension also landed at 0.9, "rather exciting," with participants generally agreeing the system made charging more interesting, even if one experienced user was less impressed, noting it didn't feel meaningfully different from information they could get elsewhere, just delivered through a different medium.
The one genuinely weak spot was efficiency, which scored negative 0.2, tipping into "slightly inefficient" territory, and the team flagged this explicitly as their main area for improvement. The complaints lined up directly with the latency issues from earlier prototyping: the assistant sometimes talked more than necessary, back-and-forth exchanges cost real time compared to just glancing at a phone, and a couple of participants noted they'd honestly just look certain things up on their own device instead. Willingness to actually use the system in public was still solidly positive, eight of ten participants said yes, though participants were more lukewarm about whether people close to them would actively encourage them to use it, landing closer to neutral.
One more interesting, if statistically fragile, pattern emerged when looking at who liked the assistant most. Participants who were older, already owned an EV, and had more charging experience trended toward being less satisfied overall, while younger participants without an EV and with less prior experience trended more satisfied. Given a sample of ten, that's a trend worth watching rather than a conclusion worth acting on, but it does align with the underlying design premise: a system built to smooth out onboarding friction is naturally going to land best with the people who actually have friction to smooth out in the first place.
Where This Goes Next
The team's outlook for the project focused on a handful of concrete next steps rather than a grand pivot. An additional screen paired with a supporting app could offset some of voice's inherent inefficiency for glanceable information like state of charge or remaining time, addressing exactly the complaint that came through clearest in testing. A Node.js-based prototype was already functioning by the end of the project, with the main open question being when the underlying API would be fully available for that kind of production use. Beyond that, the roadmap pointed toward finer instruction tuning across experience levels, more advanced personalization based on individual driving and charging habits, and, critically, figuring out how to actually track a driver's progress over time so the assistant can recognize when someone has genuinely leveled up and adjust its own behavior accordingly, rather than treating every session as a fresh start.
That last point gets at something the whole project was really circling. A charging assistant that's genuinely useful isn't one that explains everything patiently forever. It's one that notices when a nervous first-timer has quietly become a confident daily driver, and gets out of the way accordingly.