Business case · UX/UI · Internal tool
Uber dispatch console
An operations team assigns a driver to every ride, by hand, thousands of times an hour, weighing four competing factors each time. I designed the userflow and a single-screen console where the system narrows the choice and the operator makes it.
- Type
- Self-directed business case, a brief taken on during a design selection process and run with my own method
- Scope
- Userflow, interface design for an internal tool
- Users
- Uber operations team members
- Tools
- Sketch
The brief
At the time of this brief, Uber had a team that manually assigned a driver to every ride requested. The task: design a userflow that helps the operations team choose the best driver for a given ride.
Internal tools are the least glamorous and most measurable design work there is. Nobody chooses to use them, so every extra click is a cost paid thousands of times a day.
The process, and what was real
Empathise
Partly delivered- Constraints and decision factors from the brief
- Shadowing an operations shift (proposed)
- Time-on-task baseline from the current tool (proposed)
Define
Delivered- The real constraint: speed and accuracy on one screen
- Decision model: what the system decides, what the operator decides
Ideate
Delivered- Userflow covering accept and decline on both sides
Prototype
Delivered- Console interface: queue, detail, map, fleet
Test
Method proposed- Time-on-task test with operators (proposed)
- Error-rate measurement against the current tool (proposed)
Context and constraints
Delivered
The operations team handles thousands of rides an hour and has to be both fast and accurate. Rides come in several types (UberBlack, UberX, UberVan) from all over the world at once, and drivers are frequently nowhere near the pickup point.
To judge whether a driver is the right one, an operator weighs four things:
- Does the driver have the right type of car for this ride type?
- How far is the driver from the pickup location?
- Has this driver worked much more than the others? Uber tries to distribute rides evenly.
- What is the driver’s score?
How I framed it
Four variables, held in a human head, thousands of times an hour, is not a decision problem. It is an arithmetic problem being solved by the wrong processor. The design job is to let the system do the ranking and leave the operator the judgement call, on one screen, without hunting.
Userflow
Delivered
I mapped the flow before drawing anything, because the hard part is not the layout: it is what happens when either side says no. The system pre-filters to three or five available drivers near the pickup point, orders them by hours worked and rating, and only then involves a human. Both refusal branches loop back to the ranked set rather than restarting the request.
One screen, four zones
Delivered
Everything lives on a single screen: the queue of rides needing service on the left, the selected request in the middle with distance, time and price, the map on the right, and the fleet table below. An operator can see what is waiting, what they are working on, and who is nearby without a single navigation.
The request and acceptance states stay permanently visible. In a tool used under time pressure, status that has to be checked is status that gets missed.
- One screen, no navigation. The whole process is fast because nothing is anywhere else.
- Status is ambient. Request and acceptance are always on screen for the operator.
- Minimum clicks. Every interaction on the critical path was counted and reduced.
- The system narrows, the human decides. Fewer choices per assignment means fewer chances to get one wrong.
Looking back
Method proposed written now, looking back: what I would keep and what I would do differently with the experience I have today
Mapping the refusal branches before designing screens is the decision I would repeat. Most dispatch interfaces are designed for the happy path and then patched for the case that actually happens most.
What’s missing is any measurement. For an internal tool, the only argument that matters is time-on-task and error rate against the incumbent, and I have neither. Today I would insist on shadowing a shift before designing, because operators always know where the real friction is, and I would define the two numbers the design is supposed to move before opening Sketch. The fleet table also carries more columns than a 3 a.m. decision needs; I would cut it back to the four factors in the brief.