Excited to work together?gabi.karacsonyi@gmail.com

Designing an Ecosystem for a Fully Electric Supply Chain

Project Scope & Background

AD
AD

Jungheinrich already operates a mature WMS and FMS. This challenge is about extending their portfolio into long-haul transport and last-mile delivery and connecting all three through a shared integration layer.

Before designing anything, I needed a single, precise definition of what “fully electric supply chain” actually means in this context, and an approach that would surface real design decisions rather than generic principles.

Definition · Fully electric supply chain

The end-to-end operational flow from warehouse management, through long-haul transport, to last-mile delivery; where every vehicle, tool, and handover point runs on electric power and is coordinated through a shared digital system.

Design Process

My approach: build three realistic personas through desktop research, derive concrete scenarios where the system gets challenged, and extract design principles from those tangible cases rather than from abstract values.

Tags:

UX System Thinking, Claude

Product:

B2B Product Ecosystem (Truck HMI, mobile app for drivers, WMS)

Team:

Individual case study

Date:

June 30, 2026

Explore Online Demo

A system design challenge for Jungheinrich: how do three platforms, three personas, and four types of expertise work together across a single shared supply chain: safely, efficiently, and without confusion?

Personas

Each persona has one operational role. I deliberately avoided having a single persona cover two simultaneous roles, it produces muddy design decisions and doesn’t reflect how logistics operations are actually staffed.

markus_portrait
Name: Markus Kessler
Role: Long-Haul Driver
Platform: Truck HMI

 

Experience level
  • Veteran driver
  • Switched to an electric truck 6 months ago
Tasks
  • Delivers goods across Germany
  • Plans routes
  • Executes depot handovers
Pain Points
  • Charging breaks add complexity to his previous routine
    • Highway 80 km/h limit
    • Mandatory 45-min break after 4.5 hrs
    • Charge break every 570 km for 45 min
    • Traffic delays compound all of the above
lisa_portrait
Name: Lisa Bauer
Role: Warehouse Logistics Coordinator
Platform: Warehouse Management System

 

Experience level
  • Has solid experience, but new to the site
Tasks
  • Dock scheduling
  • Charger coordination
  • Driver Handovers
Pain Points
  • Narrow time windows to coordinate arrivals
  • System disruptions or delays can cause congestions
devon_portrait
Name: Devon Ruiz
Role: Last-mile Delivery Driver
Platform: App for drivers

 

Experience level
  • solid delivery experience from his past
  • Novice at B2B logistics
Tasks
  • Delivers a mixed route of store drop-offs and direct consumer orders from the same load
Pain Points
  • Residential deliveries are routine,
    but commercial store drop-offs are protocol-heavy
  • No clear escalation path for mid-route exceptions

Journey Map

I used the journey map to identify the moments where the system has to work hardest: context switches, competing constraints, and handover points where responsibility transfers between actors.

CASE 1 – Long-Haul Transport Route Change

Event:
A charging station on Markus’s planned route goes out of service while he’s driving

System response: 

  • Detects the outage via fleet network
  • Replans autonomously: identifies next viable station within range, given load weight and current charge 
  • Withholds notification until the new route is calculated OR until Markus stops for a break if his current path is not affected
  • Surfaces the route change on the HMI
  • Markus approves (or rejects) by voice command

PRINCIPLE 1 – Guidance Timing

The system holds information until it has a solution ready and the context allows a safe decision. It surfaces a prepared response instead of a problem. Notifications are suppressed during driving and other hazardous tasks.

CASE 2 – Warehouse Dock Assignment

Event:
Lisa receives an update on Markus’ arrival time and charge status due to the route change

System response: 

  • Receives Markus’s updated charge curve and ETA from the fleet backend in real time
  • Recalculates his expected charge on arrival at the hub
  • Identifies that his original charger slot needs adjustment: he needs a longer charging window
  • Flags the dock scheduling conflict to Lisa and proposes a revised dock and charger assignment based on current availability
  • Lisa reviews the system’s proposed dock reassignment and confirms or adjusts in a few taps
  • The dock and charger slot update propagates back to Markus’s HMI, he sees the confirmed dock number before he arrives

PRINCIPLE 2 – Consistency through Shared States

The system calculates with single shared variables and renders them in local context. The truck HMI shows a revised route and dock assignment, the WMS an updated arrival schedule and charging requirement. The vocabulary is consistent,but interaction constraints and UX patterns are platform-specific.

CASE 3 – Handover at the Warehouse

Event:
Markus arrives at the hub after a stressful drive, he’s been in driving mode for hours. The moment he enters the hub perimeter, his task and his relevant information change completely.

System response:

  • Docking mode: Geofencing detects Markus entering the hub. The route recedes, the dock number and charger slot surfaces.
  • Unloading mode: Markus parks correctly and the charger is connected. Transferring good from truck to dock is in progress.
  • Handover confirmation: Markus reviews the manifest and logs the load as delivered. The warehouse worker verifies physical count and condition and confirms the handover independently.

Only when both confirmations are received does the system record the handover as complete and transfers responsibility

PRINCIPLE 3 – Context switches surface the next meaningful step

When a user moves between operational contexts, the system transitions automatically based on location, task completion or vehicle state. Each transition surfaces one primary action and recedes everything irrelevant. Handovers require explicit confirmation from both sides, responsibility never transfers implicitly. Errors caught at the boundary don’t propagate into the next phase.

CASE 4 –Handling a Delivery Exception Case

Event:
Devon delivers SUPs at the retailer. One package got damaged along the way. The store manager opens the box and refuses the one package because the paddle is bent. 

System response: 

  • Devon logs the exception in the app at the retailer 
  • He receives step by step guidance for the return protocol
  • He returns the paddle to the warehouse physically and confirms it in the WMS
  • The system matches Devon’s exception log against the physical return receipt and counts it as a clean completion
  • 10th successful completion triggers an upgrade flag to Devon’s supervisor, who confirms it
  • Devon receives a notification that he reached expert level and now sees a streamlined exception handling process

PRINCIPLE 4 – Task-related Expertise

The system tracks successful completion rates per task type independently. Guidance adjusts at the task level, not the role level. Guided mode and expert mode coexist within the same profile. Competence thresholds are configured and confirmed by humans. Safety-critical tasks maintain a permanent guidance floor regardless of proficiency level.

Takeaway on AI-assistance

I used Claude as an iterative design partner: the value was in stress-testing my own assumptions and translating locked decisions into consistent language fast enough to keep pace with my thinking, not in first drafts, which were often too neat or generic. The discipline that made it work was refusing to accept any output as final — every detail was challenged and re-specified by me before it counted as done. AI accelerated articulation; it didn’t replace the judgment calls that made the thinking good.

Prev
Next