Turning manual transport planning into a guided, self-optimizing flow
At Incubit Global, I was the sole designer on a redesign for DBS Schenker. Their Linehaul Planning Accelerator let planners build truck-traffic plans across European terminals by hand. The manual-plan module was slow and error-prone, so I redesigned it into a stepper-driven route builder with a live map, auto-calculation, and a plan-effectiveness score.
Role
Sole UX/UI Designer (individual contributor)
Company
Incubit Global — for DBS Schenker
Product
Linehaul Planning Accelerator 5000
Surface
Desktop planning web app
0
Plan-effectiveness score the optimized flow surfaces to planners
0
Linear steps replace an open-ended manual form
Auto
Total time & distance now calculated, not typed
The problem
A manual planning module that couldn't measure itself
Planners at DBS Schenker created basic transport plans for truck traffic across Europe using the Linehaul Planning Accelerator 5000. The module built for manual plan creation was holding them back: it couldn't let users cleanly select multiple participating terminals, and it had no structured way to capture each linehaul's distance and time.
The deeper cost wasn't the data entry. Because the inputs were unstructured, the system couldn't automatically measure plan effectiveness, resource utilization, or daily execution. Without those measures there was no way to optimize truck traffic. The module needed a rework that made every plan structured enough for the system to score and improve it.
The real problem wasn't a slow form. It was that an unmeasurable plan can never be an optimized one.
Design process
A user-centered, double-diamond approach
I ran a UCD process weighted toward discovery and structured wireframing, since this was an internal expert tool where the constraints matter more than visual novelty. Discover and define to understand the planner's real job; ideate and deliver to shape the guided flow.
Because the users are logistics professionals inside a regulated industry, discovery leaned on domain and stakeholder research rather than broad consumer interviews. The questions that actually shaped the design clustered into three themes:
The job to be done — what makes a truck-traffic plan effective, and which inputs (terminals, distance, time, break windows) actually drive that?
The friction — where does manual planning break: data that should be derived but is typed, no validation, no feedback on plan quality?
The feasibility — what's technologically and economically realistic so the rework ships, not just demos?
Observation & suggested fix
The original research list had 20+ near-identical questions phrased around "transport plans for truck traffic in Europe." Fix: collapse to 5–6 sharp, distinct questions tied to decisions. A shorter, sharper set reads as more senior and is easier to act on.
There were no real participants or findings. Fix: frame this honestly as expert/stakeholder-led discovery (which it was) and capture 3–4 concrete insights rather than implying interviews that didn't happen.
User persona
Who we designed for
The primary user is a fleet/logistics manager responsible for planning and coordinating the movement of goods across multiple European terminals — experienced, time-pressured, and accountable for efficiency.
Primary persona — John Scott, Fleet Manager
Empathy map · illustrative
What the planner says, thinks, does, feels
Synthesizing discovery into one view kept the team anchored on the planner's reality rather than feature wishlists.
Empathy map — fleet managerillustrative
Card sorting · illustrative
Letting structure come from the users
An open card sort with planning concepts validated how the navigation should group. The clusters mapped cleanly onto five top-level areas, which became the information architecture.
Open card sort — resulting clustersillustrative
Information architecture
Five areas, one source of truth
The card-sort clusters became a flat, scannable IA. Dashboard is the home for monitoring; Route owns creation and viewing; Schedule, Report, and Messages support the rest.
Information architecture
Key scenarios
The flows that mattered most
I scoped the redesign around the planner's core jobs, each a clear scenario from the dashboard into the guided builder and back.
Monitor & start
Dashboard with KPIs and the full plan list; one clear action to start a new plan.
Build the plan
Name the plan, multi-select terminals, then enter each linehaul's distance and time.
Confirm & optimize
Review a summary, confirm, then see an effectiveness score and apply suggested fixes.
Customer journey · illustrative
From dashboard to an optimized, saved plan
Mapping the emotional arc across the five steps showed exactly where to reduce anxiety: auto-calculation removes doubt at input, and the effectiveness score replaces guesswork with proof at the end.
Journey map — create a route planillustrative
The solution
A guided, 4-step route builder
The heart of the redesign is the Create Route flow: a stepper turns an open-ended manual form into a linear, hard-to-get-wrong sequence. The layout splits into a form on the left and a live map on the right, so selecting a terminal immediately drops an origin marker in real time.
Select Terminal — a multi-select list; choices plot on the map as you go.
Inhaul Info — route name, terminals, start/end time, plan type, driver break. Total time and total distance are auto-calculated, not typed, which kills the most common entry error.
Plan Confirmation — a read-only summary so the planner verifies before committing.
Plan Optimization — the system scores the plan (e.g. 94% effective) and, once saved, lists improvement suggestions the user can ignore, fix individually, or "Improve All."
Create Route — stepper states
Dashboard wireframe — KPIs, plan list, create action
Observation & suggested fix
Auto-calc the right fields. Total time and distance should never be manual inputs — deriving them from terminals + the map removes the biggest source of bad plans. The wireframes already point here; make it explicit in the build.
Make the effectiveness score legible. A 94% number is great, but show the why: which factors moved it, so "Improve All" feels trustworthy rather than magic.
Confirm before optimize. Keeping a read-only confirmation step before optimization respects that these plans carry real operational cost.
Design system · illustrative
The tokens behind the screens
A small, consistent system kept the planner tool calm and scannable: a restrained palette, one type scale, and reusable patterns (stepper, split form-and-map, data table, status chips).
Core tokensillustrative
Primary#5B8CFF
Accent#9B6BFF
Teal#3FE0C5
Success#3FE08A
Warning#FF8A3D
Surface#11162A
AaAaAaAaAa monoPlus Jakarta Sans · Spline Mono
Outcome
A plan you can measure is a plan you can improve
The redesigned module turns unstructured manual entry into a guided flow that produces structured, scorable plans. The optimization step surfaces a real effectiveness score and concrete suggestions, so planners move from "I think this works" to "this is 94% effective, and here's how to close the gap." That's the unlock the original brief was really asking for: not a prettier form, but plans the system can automatically measure and optimize.
Structure first, polish second. The score only means something because every input before it was constrained on purpose.
What I'd do next
Where this goes from here
Validate with planners. Run moderated tests of the stepper with 5–6 real fleet managers; measure task completion and error rate against the old module.
Instrument the score. Log which suggestions get applied vs. ignored to learn what "effective" really means in practice, and tune the model.
Quantify the win. Capture before/after planning time and rework rate so the next version of this case study leads with hard numbers, not just the 94% score.
This section will contain critical design decisions and their rationale.
Future-State AI Vision
Future-State AI Vision
[ Future-State AI Vision content — [Add visual or detailed breakdown] ]
This section will contain potential AI/ML enhancements and opportunities.
NOTE — Artifacts marked “illustrative” (empathy map, card sort, customer journey, design-system tokens) are reconstructions built to communicate the thinking, not deliverables produced during the original project. The 94% effectiveness score and the screen flows come from the source work. Replace illustrative artifacts with real ones before publishing.