NextBillion.AI · 2024–25
A brief to redesign one screen. The research said it was two products.
Planning a route and rescuing one are different jobs under different stakes. The old screen treated them as the same, which is why editing a live route felt like defusing something.
Role
Product Designer
Timeline
6 months
Team
PM, engineering, support
Platform
Enterprise web
Users
Fleet dispatchers
Fig. 01 · The screen dispatchers reach for when something has already gone wrong.
11 → 2
clicks to edit a stop on a live route
2
products out of a one-screen brief
78%
of multi-route sessions used the new fleet timeline
The situation
Dispatchers plan routes for commercial fleets. Plans break constantly — a vehicle fails, a driver calls in sick, a customer moves a delivery window. Every one of those means editing a route that is already running.
What was actually wrong
Editing one stop took between six and eleven clicks, and the interface made no distinction between a route still being planned and a route with drivers already on the road. The same destructive controls sat in both.
Route editing came up again and again across six months of support tickets. The brief I was handed asked me to redesign the route edit screen.
The reframe
Field research made the screen the wrong unit of work. Dispatchers were not doing one task badly — they were doing two different tasks in one place, under completely different stakes.
The brief
“Redesign the route edit screen.”
One screen. One flow. Fewer clicks.
Flow 1 · Pre-dispatch
Planning. Nothing is live yet.
Low stakes, fully reversible. Optimised for speed and bulk change.
Flow 2 · Post-dispatch
Intervention. Drivers are on the road.
High stakes, hard to undo. Optimised for speed and for not making it worse.
Fig. 02 · The argument for everything that follows.
What the research turned up
Sessions with dispatchers across four client accounts, plus six months of support tickets and recorded sessions from the live product.
Finding 01
Dispatchers edit under pressure, not at leisure
Almost every post-dispatch edit followed a phone call. The dispatcher already knew what to change — the interface was the obstacle, not the decision.
Finding 02
Planning and intervention are different jobs
The same controls served a route being drafted and a route with drivers on it. Nothing marked the difference in consequence.
Finding 03
Warnings had stopped working
Dispatchers dismissed confirmation dialogs reflexively, without reading them. A warning that is always clicked through is not protection — it is a step.
Eleven clicks, and none of them optional
Moving one stop on a live route. Drawn rather than screenshotted — counting boxes reads faster than reading a screen.
Before
1
2
3
4
5
6
7
8
9
10
11
After
Drag task from Unassigned
Drop on the route timeline
Fig. 03 · [Label the 11 steps with their real names — unlabelled boxes are weaker evidence.]
What we decided not to build
Each cut came with a written condition for revisiting it, so the decision stayed reviewable instead of becoming folklore.
Capability
Decision
Rationale
What we tracked
AI-suggested route optimisation on edit
Deferred
Dispatchers with domain knowledge rejected AI suggestions in 60% of test cases, citing local knowledge the algorithm lacked. Adding AI here would have added complexity without trust.
Will reconsider when we have 6 months of edit-reason data to train against real operator decisions.
Mobile dispatcher app
Deferred
90% of dispatchers worked from desktops. Mobile intervention was a power-user edge case that would have fragmented engineering focus. We validated this in research before scoping.
Mobile session data — if desktop access drops below 70%, we revisit.
Driver-initiated stop edits
Rejected
Client contracts place liability for route adherence on the operator, not the driver. Allowing drivers to edit routes creates legal ambiguity. Product agreed to keep this for v2 only after contract review.
Put in backlog with a legal review gate before it can be reopened.
Bulk route editing
Deferred
Real-time operational changes are singular events. Bulk editing is a planning-phase tool that belongs in a different part of the product (route templates). Mixing them creates a dual-context UI that confuses users.
Watching for support tickets specifically requesting bulk edits — a signal it should be pulled forward.
Edit reason field on pre-dispatch
Rejected
Pre-dispatch is a scratchpad — operators iterate frequently. Mandating reason fields in a planning context would create friction for legitimate exploration. The accountability need only exists once a route is live.
Used as a qualifying question in sales demos — measures how often it accelerates deal closure.
Fig. 04 · Restraint shown as a deliverable. I circulated this after engineering kick-off rather than before, which cost the team rework — see the last section.
Flow 1
Pre-dispatch — built for speed
Nothing is live, so nothing needs protecting. Every control here optimises for changing a lot, quickly.
The map answers “where” and the timeline answers “when”. Dispatchers needed both in view at once — every earlier version made them choose.
Drag and Drop
Bulk Edit
Used in 78% of multi-route planning sessions. Dispatchers had been holding fleet-level timing in their heads or in a spreadsheet beside the screen.
Flow 2
Post-dispatch — built for not making it worse
Drivers are moving. Some things can still change, some cannot, and the interface has to say which without slowing anyone down.
Locked states are visible, not enforced by an error message after the attempt. The dispatcher sees what is still editable before reaching for it.
Step 1 — task picked up from Unassigned
Step 2 — dropped onto the route timeline
Result — assigned and rerouted, toast with undo
Six to eleven clicks became two. The saving came from removing steps that existed only to confirm intent.
Undo Toast
Edit Step popover — coordinate validation
Every change raises a toast with undo, and the step popover validates coordinates inline rather than failing after the save. The safety net moved rather than disappeared — from asking permission before the action to reversing it after.
What changed
Planning and intervention ship as two flows with different defaults. Assignment happens by dragging a task onto the timeline, with the reroute calculated on drop. Validation sits inside the step editor rather than arriving as an error after the save. Every change raises a toast with undo instead of a dialog asking permission first.
The fleet timeline was used in 78% of multi-route planning sessions. That is the one number from this project I can stand behind — dispatchers had been holding fleet-level timing in their heads or in a spreadsheet beside the screen, and now they were not.
Past that I would be guessing. I do not have a post-launch ticket analysis I can publish, so I am not going to claim the category closed or put a number on it. What I can show is the reasoning, the cuts, and the thing that shipped.
What I would do differently
The tradeoff table went out after engineering kick-off. By then the team had already sized work that the table went on to cut, so a chunk of that estimation was wasted. The artifact was right. The timing was not — it should have been circulated before anyone estimated anything.
Two habits I took into the next project. Agree success metrics with the PM before design starts, rather than after, so the target is not quietly reverse-engineered from whatever shipped.
And bring sales into research observation, not just design reviews. They hear objections in the field that never make it as far as a support ticket — by review stage that knowledge arrives as an opinion instead of as evidence.
Next project