3
Charging scenarios
The product context covered charging on the road, at home, and at company sites.
Elli / 2022-2023
Case study
Designing clearer B2B driver charging journeys.
Working in the Elli Fleet Charging context across driver app journeys, web and console touchpoints, shared design-system components in Figma, and process improvements that helped the product work move with more structure.
Fleet charging ecosystem
Overview
The work centered on Elli Fleet Charging: a B2B driver charging ecosystem across app, console, web touchpoints, and shared product foundations.
At Elli, my work sat inside a B2B driver charging product area connected to Elli Fleet Charging. I worked on the driver charging app as well as the website version of the experience, where public charging, home charging, account logic, and fleet-related product touchpoints needed to stay understandable across surfaces.
The product context split across two sides of the same service: drivers needed a clear charging journey, while fleet managers needed oversight through the Fleet Charging Console. That meant the driver-facing experience still had to fit into a larger B2B system of charging cards, charging processes, reimbursement, billing, and fleet oversight.
The chapter also included support work around the design system. I worked together with the design-system designer on component construction in Figma and helped improve parts of the process around how product design work moved from structure into reusable interface detail.
At a glance
Scope in one pass
2
Product modes
The ecosystem split between driver-facing charging journeys and fleet-manager oversight in the console.
DS
System support
Design-system support included component construction in Figma and process improvements around product work.
Contributions
Worked across driver charging product design, design-system foundations, and process improvements.
The product work focused on the Elli Fleet Charging ecosystem: driver app flows, web touchpoints, charging-related states, and the interaction structure needed to make the experience easier to follow.
The surrounding fleet product connected several charging contexts: on the road, at home, and at company sites. The Fleet Charging Console gave fleet managers visibility into charging processes, costs, cards, billing, and reimbursement. I use that system context here carefully, without overstating my role beyond the product surfaces and support work I contributed to.
Alongside that product work, I supported design-system component construction in Figma and helped with process improvements so shared product decisions could become more consistent across the team.
Three connected use cases
Three projects show how the work changed as the product problem changed.
The workstreams focus on different product problems. Together, they show how the design approach adapted while the underlying need for clarity stayed consistent.
B2B driver charging
Driver App
The driver charging app had to make charging context, status, card logic, and next steps easier to understand.
Console and web
Console
The web and console side needed to stay coherent with the driver experience while serving fleet-manager needs.
Design system and process
System
Design-system support and process improvements helped fleet-charging product work become more consistent and reusable.
B2B driver charging
Driver App
The driver charging app had to make charging context, status, card logic, and next steps easier to understand.
Elli Fleet Charging makes the driver experience part of a larger company-car system. Drivers charge publicly with an app or charging card, while the business side needs the charging processes to be documented, billed, and understood centrally.
That shifts the design problem from making screens look calm to making the journey legible. The app had to help drivers understand what was happening, what mattered next, and how the charging experience connected back to the broader fleet service.
Design pressure
Unclear status or fragmented flow logic can quickly turn into user uncertainty in a real-world charging moment.
What it demonstrates
Ability to design for confidence in service moments where interface, infrastructure, and driver expectation all meet.
Fleet driver context
Status clarity
The experience needed to communicate what was happening, what was pending, and what the user could do next.
Expectation setting
Trust depended on reducing ambiguity around service behavior rather than hiding complexity behind a polished surface.
Service context
The journey had to respect public and home charging realities instead of behaving like a purely digital checkout flow.
Console and web
Console
The web and console side needed to stay coherent with the driver experience while serving fleet-manager needs.
The work was not limited to a single mobile surface. I also worked on the website version of the driver charging experience, while the wider product context connected that work to the Fleet Charging Console.
That made coherence important. The driver-facing app and the fleet-manager side did not need to look identical in every detail, but they needed to share enough structure, language, and behavior that charging logic did not feel reinterpreted from surface to surface.
Design pressure
The product needed enough consistency across app, web, and console logic that charging, billing, and card behavior felt like one system.
What it demonstrates
Ability to reason across touchpoints and design for product coherence, not just isolated screens.
Fleet Charging Console
Surface logic
The driver app and web experience had to share the same underlying product model while respecting different interaction contexts.
Language
Labels, steps, and hierarchy needed to reduce uncertainty around charging behavior and account context.
Continuity
Coherence became a product-quality signal because driver and fleet-manager touchpoints needed to feel connected.
Design system and process
System
Design-system support and process improvements helped fleet-charging product work become more consistent and reusable.
Alongside the product surfaces, I supported design-system work together with the design-system designer. That included component construction in Figma, where the quality of the details mattered because they shaped how the product could scale.
I also helped with process improvements. The value was not only cleaner UI output, but better structure around how product decisions, component logic, and reusable design work moved through the team.
Design pressure
Components needed to be useful inside real product work, not just polished as isolated design-system inventory.
What it demonstrates
A practical contribution to design-system craft, Figma component construction, and team process.
Fleet charging structure
Component work
Supported the design-system designer with component construction in Figma.
Process
Helped improve parts of the product design process so shared decisions were easier to apply consistently.
Career bridge
Elli connects embedded product rigor to later platform, design-system, and operational systems thinking.
Brand context
What connected the work
The workstreams were different, but they shared one product pattern: charging experiences improve when the system is easier to read across surfaces and components.
01
App and web coherence
The driver charging app, website version, and wider console context needed shared product logic, language, and interaction structure.
02
Components as product logic
Design-system support was about constructing usable Figma components that could carry real product decisions.
03
Process as leverage
Process improvements helped product work become clearer, more consistent, and easier for the team to move forward.
Impact
What it proved
This chapter shows the move from embedded product rigor into B2B charging products, shared components, and team process.
Impact read
What the work established
App
Driver charging
The contribution centered on driver charging journeys inside the Elli Fleet Charging context.
Console
Fleet oversight
The web and console context covered charging processes, cost control, cards, billing, and reimbursement.
DS
System support
Design-system and process work created a bridge toward later platform and enterprise product work.
Learnings
B2B charging products become easier to trust when app, web, components, and process support the same product model.
Charging needs legibility
Driver charging experiences depend on status, timing, account context, and service expectations. If those are unclear, polish cannot compensate.
Surfaces shape one story
App and web do not need to be identical, but they need enough shared structure that the product feels coherent.
Career relevance
Elli is the bridge from MAN's embedded HMI discipline into later design-system, platform, and operational systems work.
The value of this chapter is the systems shift. It shows comfort working where product surfaces, shared components, team process, and real-world charging context all have to support the same experience.
Career sequence
You are on chapter 2 of 4. Continue through the sequence for the clearest career story.
Newer chapter
Lead proofEnterprise systems depth
SIXT
Enterprise product systems where reusable foundations improved workflow clarity, UX consistency, and delivery speed.
Current internal product work across back-office design systems, revenue-management applications, and AI-supported design-to-code workflows.
Earlier chapter
Lead proofEmbedded HMI rigor
MAN Truck & Bus
Embedded HMI across cluster and infotainment where precision, consistency, and technical constraints had to move together.
Automotive interface work spanning graphical production, prototypes, icon systems, and shared interaction logic for truck HMI surfaces.