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.
Executive Summary
Executive Summary
The problem in one line
DBS Schenker's manual plan module required planners to type data the system already knew, produced unvalidated inputs, and could never score or optimize the plans it produced — making every plan a best guess.
The answer in one line
Replaced the open-ended form with a 4-step guided stepper: constrained inputs, auto-calculated distance and time, a split form-and-map layout, and a plan-effectiveness score that gives planners proof, not a hunch.
Project at a glance
Role
Sole UX/UI Designer
At Incubit Global
Surface
Desktop web app
Internal B2B SaaS tool
Approach
UCD · Double Diamond
Expert-led discovery
Key outcome
94% plan effectiveness
Score surfaced to planners
Success Metrics
Success Metrics
Primary KPIs
Plan-effectiveness score
Target: measurable at all (baseline: 0%)
94%
Surfaced to planners
Steps to create a plan
Was: open-ended single form
4
Guided, linear steps
Manual data entry fields
Total distance + total time
Auto
Derived, not typed
Design quality metrics
Terminal multi-select
Was: broken / unsupported
✓
Live map + list
Plan optimization suggestions
Was: none
✓
"Improve All" + per-item fixes
Confirmation step before commit
Was: none
✓
Read-only review screen
Effectiveness score · radial
94%
EFFECTIVE
Route coverage
96%
Resource utilization
91%
Schedule adherence
94%
Driver break compliance
88%
Terminal wait time
78%
Terminal wait time is the one factor below threshold — the "Improve All" suggestion targets this first.
Stakeholder Map
Stakeholder Map
Influence × Interest · logistics planning tool
Influence
Low interest
High interest
Keep satisfied
DBS Schenker IT
System integration feasibility
Finance / Procurement
License cost, ROI approval
Manage closely
Product Owner (Incubit)
Feature scope, delivery sign-off
DBS Schenker Ops Lead
Owns planner productivity goals
Lead Fleet Manager
Primary user, validates flows
Monitor
Regulatory / Compliance
EU transport regulation alignment
HR / Training
Planner onboarding to new tool
Keep informed
Fleet Planners (end users)
Daily tool use, error-prone tasks
Truck Drivers
Downstream impact of plan quality
Terminal Operators
Receive route + schedule data
← Low influence
High influence →
Research Insights
Research Insights
Insight 01 · Data derivation
"I have to type in the distance. But the system already knows where both terminals are."
Distance and total time were manually entered fields, meaning a planner could type anything — correct or not. The map data to derive both values existed in the system. This was the single biggest source of plan errors and the clearest win for auto-calculation.
Insight 02 · No quality feedback
Planners had no signal that a completed plan was good, bad, or improvable.
After saving a plan, the module showed nothing. No score, no warning, no suggestion. Planners knew their plans weren't optimal but had no evidence to challenge them — or to show leadership why a plan was approved.
Insight 03 · Terminal selection
Multi-terminal plans were possible in reality, impossible in the tool.
The old module had no multi-select for terminals. Planners involving more than two stops had to create separate plans and mentally stitch them together — a workaround that introduced sequencing errors and duplicated effort.
Insight 04 · Cognitive load
The open-ended form offered no guidance on what order to fill fields or what each one drove.
Fields for route, terminals, time windows, driver breaks, and plan type appeared simultaneously with no logical flow. Experienced planners had a mental order; new planners had to learn it from colleagues, not the software.
"
I want software that simplifies planning the movement of goods — saving time and reducing the chance of errors.
John Scott · Fleet Manager · Primary persona
Opportunity Map
Opportunity Map
Unmet need
Design opportunity
Impact
Distance + time calculated manually — prone to typos and invalid inputs
Auto-derive distance and total time from terminal selections + map data
High
No multi-terminal selection — multi-stop routes require separate plans and manual stitching
Multi-select list paired with a live map; each selection drops a marker instantly
High
No feedback on whether a plan is any good — planners commit with zero confidence signal
Post-save effectiveness score (0–100%) with breakdown by factor and "Improve All" action
High
Open-ended form gives no guidance on input order or field dependencies
4-step linear stepper enforces a logical sequence; each step builds on the last
High
No review step before plan is committed — errors only discovered post-save
Read-only confirmation screen (Step 3) before any data is written to the system
Med
Dashboard shows status chips but gives no actionable path into plan creation
Prominent "+ Create Plan" CTA on dashboard adjacent to routes list
Med
Workflow Architecture
Workflow Architecture
System layers · Linehaul Planning Accelerator 5000
Planner layer
Dashboard Monitor + start
→
Select Terminal Step 1
→
Inhaul Info Step 2
→
Confirmation Step 3
→
Optimization Step 4 · Score
System layer
Terminal DB Location data
→
Map API Route calc
→
Auto-calc engine Dist + time
→
Plan store Structured data
→
Score model Effectiveness %
Output layer
Optimization suggestions Per-item + Improve All
·
Schedule feed Downstream execution
·
Report module Inbound / outbound
Concept Exploration
Concept Exploration
Three directions explored · plan creation module
Direction A
Enhanced flat form
Improve the existing pattern
Plan Name: [__________]
Terminal From: [▼ dropdown]
Terminal To: [▼ dropdown]
Start Time: [__:__]
End Time: [__:__]
Distance: [___ km]
Total Time: [___ hrs]
Break Window: [__:__]
[Save Plan]
Rejected: still relies on manual distance entry. Dropdown can't support multi-terminal routes. No sequence, no confirmation, no score.
Chosen: multi-select, auto-calc, split layout, confirmation step, and optimization score. Every design principle met.
Direction C
Map-first builder
Draw the route, derive the form
[Full-screen map]
Click terminal → adds to route
Route: FRA → MUC → HAM
──────────────────
Panel slides in →
Auto-filled: dist, time
Manual: name, breaks
[Confirm + Score]
Parked: visually compelling but unfamiliar interaction for logistics planners trained on forms. Higher dev cost. Consider as V2 power-user mode.
Wireframes
Wireframes
Key screens · annotated low-fi · desktop
Step 1 · Select Terminal
Linehaul Planner
Route
1
2
3
4
SELECT TERMINALS
☑ Frankfurt
☑ Munich
☐ Hamburg
☐ Berlin
☐ Stuttgart
Next →
LIVE MAP
2 terminals selected
A
Split layout: list left, live map right. Selections plot instantly — no submit needed.
B
Multi-select checkboxes replace the old single-terminal dropdown.
C
Stepper always visible. Step 1 active. No way to jump ahead.
Step 2 · Inhaul Info
Linehaul Planner
✓
2
3
4
ROUTE DETAILS
Route name
FRA–MUC Express
Start time
06:00
End time
10:20
Driver break
08:00 – 08:30
Distance ← AUTO
320 km
Total time ← AUTO
4h 20m
Next →
LIVE MAP
320km · 4h 20m
A
Distance and total time are read-only teal fields — auto-derived, not typed.
B
Map updates to reflect terminals from step 1 — no re-selection needed.
C
Step 1 shown as a checkmark — confirms prior progress without letting user skip.
Step 3 · Plan Confirmation
Linehaul Planner
REVIEW BEFORE SAVING
RouteFRA–MUC Express
TerminalsFrankfurt → Munich
Time window06:00 – 10:20
Distance320 km ← auto
Total time4h 20m ← auto
Driver break08:00 – 08:30
← Back
Confirm + Save
A
All fields read-only. This screen cannot be edited — forces a deliberate "confirm" action.
B
Auto-calculated fields highlighted in teal so planner sees at a glance what was derived.
Step 4 · Plan Optimization
Linehaul Planner
94%
Plan effectiveness
FRA–MUC Express
SUGGESTIONS
Reduce terminal wait at Munich
Fix →
Adjust break to 09:00 – 09:30
Fix →
Ignore all
Improve All
A
Score shown as a radial dial — immediately communicable in a leadership review.
B
Each suggestion has a per-item "Fix" + a bulk "Improve All" — planner stays in control.
C
"Ignore all" is always available — planners are experts, not students.
Design System
Design System
Color tokens · enterprise tool palette
--blue
#4D7CFF
Step active, CTA
--violet
#9B6BFF
Gradient pair
--teal
#3FE0C5
Auto-calc fields
--green
#3FE08A
Score, success
--yellow
#FFD23F
Confirm, caution
--orange
#FF8A3D
Warnings, alerts
Type scale · Plus Jakarta Sans + Spline Mono
H1
Linehaul Planner
26px · 700 · Page titles
H2
Create Route Plan
19px · 600 · Section headers
Body
Frankfurt → Munich · 320 km · 4h 20m
14px · 400 · Data, form labels
Mono
SELECT TERMINAL
Spline Mono · 11px · Labels, kickers, metadata
Core components
Stepper · step 2 active
✓
2
3
4
TerminalInfoConfirmScore
Auto-calc field · read-only
Route name (editable)
FRA–MUC Express
Distance ← AUTO
320 km
Total time ← AUTO
4h 20m
Score dial + status chips
94%
Plan effectiveness FRA–MUC Express
CompletedOn RouteScheduledFailed
Usability Testing
Usability Testing
Context
This was an internal expert tool at an enterprise logistics company. Formal moderated testing with recruited participants was not part of the engagement. Validation occurred through structured walkthroughs with the DBS Schenker ops lead and fleet manager proxies, and a staged review cycle with the product owner at Incubit. The findings below reflect those sessions.
Round 1 · Wireframe review
Ops lead + product owner
Walked through paper wireframes for all 4 steps. Confirmed stepper logic. Identified that the "Inhaul Info" label was unfamiliar — planners call it "route details" internally.
Fix: relabelled step 2 to match planner vocabulary. "Inhaul Info" retained in the system as a technical term, not exposed in the UI label.
Round 2 · High-fidelity walkthrough
Fleet manager proxy · 2 sessions
Tested full flow in Figma prototype. Both completed end-to-end without help. Key friction: the confirmation screen felt like a "dead end" — no visual cue that clicking confirm would trigger the score.
Fix: added micro-copy under the confirm button: "Next: see your plan's effectiveness score."
Round 3 · Score legibility check
Stakeholder presentation
Ops lead raised: "What does 94% mean — is that good enough to execute?" The score lacked a threshold. Planners needed a benchmark, not just a number.
Fix: added a "≥90% is executable" threshold band on the score dial. Red below 70%, yellow 70–89%, green 90%+.
Key findings · what changed
Observation
Design change
Round
"Inhaul Info" label was opaque to planners unfamiliar with the technical term
UI label changed to "Route Details"; internal field name unchanged in system
R1
Confirmation screen felt terminal — no cue that Step 4 (score) was coming
Added sub-copy: "Next: see your plan's effectiveness score" below confirm CTA
R2
94% score meaningful in isolation — ops lead couldn't tell if plan was executable
"Improve All" felt like a black box — planners wanted to understand what would change
Added expandable preview: "Improve All will adjust break window and reduce Munich wait time"
R3
Key Tradeoffs
Key Tradeoffs
Stepper vs. single-page form
Chose stepper
A single-page form would be faster for expert planners who already know the field order. But the old module was a single-page form and it produced unstructured, unvalidatable plans. The stepper's constraint is the point: it forces inputs into a logical sequence the scoring model can act on.
Risk: Power users may find the stepper slower. Mitigated by keyboard navigation between steps and a "quick create" shortcut path planned for V2.
Auto-calc distance vs. manual override
Auto, no override
Stakeholders initially requested a manual override for distance — arguing that planners sometimes know a route better than the map. This was declined: an overridden distance breaks the scoring model's ability to validate the plan against real road data. If the map is wrong, fix the map.
Risk: Map data gaps in specific corridors. Mitigated by a data-correction feedback button surfaced on the confirmation screen.
Show all suggestions vs. top 3 only
Top 3 by default
The optimization model can surface 8–12 suggestions for a complex plan. Showing all of them in the initial view caused cognitive overload in walkthroughs — planners skipped "Improve All" because the list felt unmanageable. Top 3 by impact, with "Show all" available below.
Risk: Low-ranked suggestions get ignored indefinitely. Tracked via a "suggestions applied" metric in the reporting module.
Map-first vs. list-first terminal selection
List-first, map reactive
Direction C (map-first builder) was compelling visually but failed in walkthroughs: planners search for terminals by name, not by geography. They know "Frankfurt" not "the terminal in the south of the city." A searchable list with map confirmation matches how they actually think.
Map-first kept as a candidate for V2 power mode once planners are familiar with the terminal set.
The thread connecting every tradeoff
Every decision above chose plan structuredness over planner freedom — deliberately. The original module gave planners total freedom and produced plans the system could not measure. The redesign constrains inputs precisely enough that the scoring model has something real to work with. That constraint is not a limitation of the design; it is the design.
Future-State AI Vision
Future-State AI Vision
What becomes possible when AI is a first-class planning material
Predictive routing
The system suggests the route before the planner starts
Based on historical plan patterns, cargo volume, and day-of-week traffic data, an ML model proposes a pre-filled plan for the planner to review, adjust, and confirm. Planning goes from "create from blank" to "accept or modify." Most days, the proposal will be correct.
Live disruption response
When a truck is delayed, the plan re-optimizes in real time
Today, a delayed truck forces a planner to manually reroute other vehicles to compensate. An AI layer connected to GPS and terminal data could detect the disruption, calculate the ripple effect across the network, and surface a revised plan for one-tap approval — before the delay becomes a failure.
Score explanation
The 94% score explains itself in plain language
Currently the score is a number. An LLM layer could generate a one-paragraph plain-language summary: "This plan scores 94% because route coverage is optimal and schedule adherence is high. The 6% gap comes from a terminal wait window at Munich that could be reduced by 18 minutes." Planners trust numbers they understand.
Driver behaviour integration
Plans optimized for who's driving, not just what route
Individual drivers have different average speeds, break patterns, and terminal familiarity. A plan that scores 94% for an experienced driver may score 78% for a new one on the same route. Connecting driver assignment to plan optimization closes that gap and reduces the "good plan, bad execution" failure mode.
Cross-plan network optimization
Plans aren't isolated — the whole network can be scored
Today each plan is scored individually. But a fleet of plans that are each 94% effective may still conflict at shared terminals. A network-level optimizer would identify cross-plan congestion, terminal bottlenecks, and resource conflicts — and suggest a revised schedule that lifts the whole network, not just individual routes.
Design principle for AI in logistics tools
Planners are accountable for what the trucks do. Every AI feature in this roadmap surfaces suggestions, not decisions — the planner confirms, not the algorithm. A route that looked optimal on paper and failed because the AI didn't know about a road closure is a system failure the planner owns. The design's job is to make the AI's reasoning transparent enough that the planner can catch the edge cases the model missed. Automation raises the ceiling; human judgment is the floor.
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.