Dispatch Screen — Embedded Driver Map
Dispatchers were bouncing between the Dispatch screen and a separate Driver Map app to assign orders and track drivers. I helped define the Embedded Driver Map — assignment, real-time tracking and delivery monitoring unified into one screen — with measurable success criteria agreed up front.
Dispatchers switched between Dispatch and a separate Driver Map to assign orders and track drivers — slow, error-prone and fragmented.
Define an embedded driver map with interactive assign / unassign / reassign actions, real-time tracking and ETA, validated across single and multi-order scenarios.
A unified dispatch workflow — near-zero tool switching and clearer delivery visibility, measured against explicit success metrics.
Feature definition, validation & stakeholder alignment
Dispatchers coordinating live deliveries from takeaways
One unified screen — near-zero tool switching, measured against explicit success metrics
Context
Dispatch is the control tower of delivery operations — where orders are matched to drivers and journeys are watched in real time. It runs alongside the Driver Map, which shows where every driver is. Keeping those two in separate places put the cost of switching on the busiest person in the room.
Problem / Opportunity
To assign an order and confirm it was on its way, a dispatcher had to leave Dispatch, open the Driver Map, act, and come back — repeatedly, often mid-rush. The fragmentation slowed assignment, invited mistakes and blurred delivery visibility.
User & Business Need
- Dispatchers needed to assign and track without leaving their primary screen
- Operations needed faster, more reliable assignment during peak demand
- The business needed clearer real-time delivery visibility to protect on-time performance
My Role
- Helped define the embedded-map scope and the interaction model for assign / unassign / reassign
- Validated functional behaviour and real-time business logic across single and multi-order scenarios
- Aligned stakeholders on what 'done' meant by agreeing measurable success criteria
- Worked to remove redundant toggles and duplicate UI so the workflow stayed clean
Product & Delivery Approach
The Driver Map was brought directly into the Dispatch screen, opened via the existing map icon so the established workflow stayed intact.
- Interactive map: tap an order marker to assign / unassign / reassign; tap the car for ETA
- Real-time driver tracking with ETA both en route and returning to the takeaway
- Clear marker states — unassigned, on-delivery and returning — with consolidated multi-order ETAs
- Consistent behaviour for single and multiple takeaway orders, reusing existing popups
- Removal of duplicate map toggles so there was one obvious way to act
Constraints & Trade-offs
- Real-time location data is imperfect — the design had to stay legible when updates lag or jump
- The new map had to layer onto the existing side panel without disrupting a workflow dispatchers rely on daily
- Multi-order scenarios multiply edge cases, so behaviour had to be validated state by state
- Simplicity was a deliberate trade-off — fewer controls, each doing exactly what's expected
Outcome & Impact
- A single screen for assignment, tracking and monitoring — near-zero tool switching
- Clearer, real-time delivery visibility for dispatchers
- Faster, more confident assignment validated against agreed success metrics
- Positive qualitative feedback from the dispatchers who live in the screen
Success Metrics
| Metric | Description | Success indicator |
|---|---|---|
| Dispatch efficiency | Time taken to assign an order from Dispatch | Reduction vs baseline |
| Tool switching | Switching between Dispatch and Driver Map | Near-zero switching |
| Delivery visibility | Usage of the embedded map | Increased adoption |
| User satisfaction | Dispatcher feedback | Positive qualitative feedback |
Key Learnings
- Agreeing success metrics up front turns a vague request into a decision everyone can hold the work to.
- Embedding into an existing workflow is harder than building net-new — but it's where the real adoption lives.
- For real-time tools, the product job is making imperfect data feel trustworthy.