Case Study 02
Locus Last Mile
LLMOne promise. 661 orders. One manager to make sure it all happens.
RoleProduct Designer
TypePersonal Project
ToolsFigma, AI-assisted
Scroll to explore
One promise. 661 orders. One manager to make sure it all happens.
One promise. 661 orders. One manager to make sure it all happens.
Warehouse manager arrives at 7am. 400 to 800 orders. 2 hours to assign everything before the first slot opens. By midday riders are on the road and things start breaking. A bike breaks down, a customer is not home, a slot is about to be missed. Every failure cascades. The problem is not that he lacks information. It is that he cannot act on it fast enough.
How do we design a dashboard that helps Manjunath stay ahead of failures, not just aware of them? One that enables fast, confident decisions across all orders so every customer gets their parcel exactly when promised.
Manjunath's day has three distinct modes. These became the foundation for every structural decision.
Manjunath, 51
Warehouse Manager, HSR Layout Bangalore Hub
Five questions running in his mind at any moment:
The aim was to design something that removes the anxiety behind all five.
Rajan, 67
Patient, Begur
He ordered his blood pressure medicine three days ago. Delivery was promised between 10 and 12 today. He has not stepped out of his house. He is waiting.
Rajan will never see Manjunath's dashboard. But every design decision in this project exists to make sure his order reaches him on time.
Without access to real users, understanding Manjunath meant getting close to his world through other means. Secondary research, contextual observation, and structured inference shaped everything that followed.
Started by researching how last-mile delivery hubs operate in India. Read about hub-and-spoke logistics models, the 7 to 10am pressure window before the first delivery slot opens, and what makes the morning assignment phase so high-stakes. Browsed Locus's own published content on last-mile operations. Used Claude to stress-test assumptions, think through edge cases, and simulate failure scenarios. Explored operational forums where delivery managers and riders share their day-to-day realities.
Looked up Swiggy, Zomato, and Blinkit dark stores and delivery hubs across HSR Layout, Koramangala, and Begur. Went through photos of the physical spaces, bikes parked outside, handwritten order sheets on tables. Read reviews left by delivery partners, complaints about slot pressure, heat, limited break time, and last-minute reassignments. This is not data. But it made Manjunath feel real.
Managers do not sit. They walk the floor constantly, check their phone in 10-second bursts, and context-switch continuously. The dashboard needed to work at a glance, not as a reading experience.
Help requests pile up exactly when the manager is most overwhelmed. Mid-morning is when exceptions start compounding on top of each other. Exception visibility cannot be buried in a secondary tab.
Rider familiarity with an area is critical in Indian delivery contexts. A new rider in an unfamiliar zone loses 20 to 30 minutes per batch just navigating. The system needed to surface this as a risk signal, not just metadata.
Assumptions were grounded in research. These were the rules of the operational world Manjunath works within.
If a design element does not move one of these numbers, it does not belong on the screen.
95%+
Orders delivered successfully
90%+
Delivered within promised slot
100%
Assigned before 10am
<5%
Failed delivery rate
5 min
Max time to acknowledge help request
2 hrs
Morning assignment window
0
Exceptions requiring dashboard exit
0
Ambiguous failures at shift close
A good day is the day Rajan opens his door at 11:04am and has no reason to call the pharmacy.
The plan is made in the morning. Reality breaks it by afternoon. This shaped how the product was structured from the start.
Manjunath's day mapped across three modes
My first instinct was a single dashboard that shifts based on time of day. Planning Mode in the morning, Monitoring Mode after dispatch. Intelligent, contextual, clean. But it forced Manjunath into a mode he did not choose, and broke down the moment he needed to jump between contexts mid-morning.
Early lo-fi exploration of the unidirectional approach
The shift to a tab structure gave Manjunath control. He moves between Assignment, Monitoring, Orders, Summary, and Settings on his own terms. The system supports his decisions rather than dictating his flow.
Six screens. One morning. This is the happy path.
Manjunath arrives and sees the full picture. Total orders, slot breakdown, rider availability, and the system-generated assignment plan are all visible at once. No hunting for context.
He reviews the plan the system has created. Each rider, their assigned orders, and the geographic grouping are laid out for his approval. He reads, not enters.
Where the system falls short, Manjunath steps in. He can reassign orders, swap riders between zones, or flag priority parcels before confirming.
One action pushes the confirmed plan to all riders. Bulk confirmation, not order-by-order. The morning assignment closes in minutes, not hours.
Riders receive their batches. The dashboard shifts into monitoring mode. Manjunath's role changes from planner to supervisor.
Live view of all riders in the field. Status, location, completion rate, and active exceptions are visible at a glance. The interface stays calm so Manjunath can stay calm.
(Rajan might not get his medicine on time)
Rajan is expecting his medicine before 12pm. Manjunath arrived at 7 and planned to finish assignment by 8. This is what actually happened.
Manjunath reaches the hub. One rider is absent. He activates the 2 buffer riders, but they are new and still getting familiar with the zones. One of them is Deepak.
Barry and Deepak are assigned the same zone 1. Deepak is unfamiliar with the area but the system has flagged this as a risk.
Manjunath receives a help request from Deepak. His bike has broken down and he cannot continue. Manjunath checks the status and location of nearby riders and decides to reassign Deepak's priority orders. One of those orders belongs to Rajan.
The reassignment happens inside the dashboard without leaving the monitoring view. Manjunath selects Rajan's order and moves it to Barry, who is close to Begur.
Manjunath tracks both riders in real time. Barry is moving. The slot window is open until 12.
Barry delivers the package to Rajan. The slot is met. The promise holds.
Rajan opens his door. He has no reason to call the pharmacy.
End-of-shift summary. Every order accounted for.
We take stressful operational scenarios too lightly when we are not close to them. What looks like a simple routing problem is actually a web of human decisions, time pressure, and cascading failures. Design for the person in that pressure, not the ideal-state user.
Given more time, the focus would shift to micro-interactions and component polish. The bigger screens are directionally right, but the value for Manjunath lives in the small moments. How fast does an alert surface? How easy is a reassignment drag? Those details matter more than the layout.
Next steps would be to detail the screens that were left incomplete, then build no-code prototypes to set expectations and test with real hub managers before any development begins.