Context
PT XYZ processes roughly 10,000 orders a day. Before shipping, each order goes through picking, retrieving items from the warehouse. This had no dedicated system, accuracy and speed relied entirely on a picker's memory rather than a defined process.
THE PROBLEM
The picker wasn't careless. There was simply nothing in the process to catch a mistake before it shipped.
The Goal
Three things had to be true by the end of this project:
Every item picked matches the order, regardless of picker experience.
Picking gets faster as order volume grows.
The process works the same for any picker, new or experienced.
HOW PICKING WORKS TODAY
This is the process before any redesign, three phases, all manual, all dependent on the picker.
BREAKING DOWN THE PROBLEM
Before sketching any interface, I broke the problem down into the four things that actually determine whether a pick goes right or wrong.
CONSTRAINTS & SCOPE
Before framing any solution, it was worth being explicit about where this project's boundaries sat. Some parts of the fulfillment process were treated as fixed, existing systems, not open for redesign.
HOW MIGHT WE
How might we make picking accuracy independent of who's doing the picking?
How might we turn a flat list of items into a route that scales with order volume?
How might we design a process a new picker can trust on day one, without months of tribal knowledge?
Design Decision 1
A Route, Not a List
Pickers used to receive a flat list of items with no order to follow, leaving the sequence up to whatever felt fastest in the moment. I replaced this with a generated route that sequences every item in a batch by warehouse position, shown as a visual path across zones.
Batches were introduced so a single route could cover multiple orders at once, cutting the number of trips through the warehouse instead of one trip per order.
This turned picking from a search problem into a navigation problem, the system decides the path, the picker just follows it.
Design decision 2
Scan First, Confirm Second
Matching a picked item to an order used to depend entirely on the picker reading a label and comparing it by eye. I moved that comparison into the system: pickers scan the item's barcode, and the app pulls up the SKU it expects at that location before quantity is confirmed.
This shifts verification from something a picker remembers to do, to something the app requires before the flow can continue.
Accuracy stopped being a matter of attention and became a checkpoint the process enforces on its own.
Edge Cases
Incomplete batch
Submit stays disabled until every item in the batch is picked, preventing a batch from being closed while items are still outstanding.
Quantity shortfall
When fewer units are found than expected, the picker adjusts the quantity inline rather than the flow breaking.
Unreadable barcode
Manual code entry sits one tap away, so a failed scan doesn't stop the picker.
TRADE-OFFS
Efficiency added dependencies elsewhere, batching orders into one route only works if the physical handling downstream can keep up.
Accuracy came at the cost of friction, every verification step added is a step the picker didn't have to take before.
Consistency reduced flexibility, removing picker discretion only pays off if what replaces it is genuinely better than judgment.
SUCCESS METRICS
How success would be measured, not results already achieved.
Task success rate — picks matching the order on first attempt.
Throughput — picks per labor hour, ties design to cost.
Time to proficiency — how fast a new picker matches a tenured one.
reflection
This project moved the process off one thing: a picker's memory. The goal wasn't a better screen, it was a system the operation could rely on no matter who was working that shift.
The hardest decisions weren't about the ideal flow, they were about what the system should never let slip through quietly: an incomplete batch, a missed mismatch, a scan that stops someone cold. Those are the moments that cost the business money and cost the picker trust in the tool.
If this went further, the first thing I'd want to test is whether the route stays accurate as the warehouse actually changes, since the whole strategy depends on that route being worth more than the flexibility it takes away.
Warehouse Picking System — Removing the Single Point of Failure
Designed a process that replaces reliance on one person's memory and experience with a structured system.
Role
End-to-end UX ownership -- User research to handoff
Industry
E-commerce
Teams
Product Designer
Year
2026
Context
PT XYZ processes roughly 10,000 orders a day. Before shipping, each order goes through picking, retrieving items from the warehouse. This had no dedicated system, accuracy and speed relied entirely on a picker's memory rather than a defined process.
THE PROBLEM
The picker wasn't careless. There was simply nothing in the process to catch a mistake before it shipped.
The Goal
Three things had to be true by the end of this project:
Every item picked matches the order, regardless of picker experience.
Picking gets faster as order volume grows.
The process works the same for any picker, new or experienced.
HOW PICKING WORKS TODAY
This is the process before any redesign, three phases, all manual, all dependent on the picker.
BREAKING DOWN THE PROBLEM
Before sketching any interface, I broke the problem down into the four things that actually determine whether a pick goes right or wrong.
CONSTRAINTS & SCOPE
Before framing any solution, it was worth being explicit about where this project's boundaries sat. Some parts of the fulfillment process were treated as fixed, existing systems, not open for redesign.
HOW MIGHT WE
How might we make picking accuracy independent of who's doing the picking?
How might we turn a flat list of items into a route that scales with order volume?
How might we design a process a new picker can trust on day one, without months of tribal knowledge?
Design Decision 1
A Route, Not a List
Pickers used to receive a flat list of items with no order to follow, leaving the sequence up to whatever felt fastest in the moment. I replaced this with a generated route that sequences every item in a batch by warehouse position, shown as a visual path across zones.
Batches were introduced so a single route could cover multiple orders at once, cutting the number of trips through the warehouse instead of one trip per order.
This turned picking from a search problem into a navigation problem, the system decides the path, the picker just follows it.
Design decision 2
Scan First, Confirm Second
Matching a picked item to an order used to depend entirely on the picker reading a label and comparing it by eye. I moved that comparison into the system: pickers scan the item's barcode, and the app pulls up the SKU it expects at that location before quantity is confirmed.
This shifts verification from something a picker remembers to do, to something the app requires before the flow can continue.
Accuracy stopped being a matter of attention and became a checkpoint the process enforces on its own.
Edge Cases
Incomplete batch
Submit stays disabled until every item in the batch is picked, preventing a batch from being closed while items are still outstanding.
Quantity shortfall
When fewer units are found than expected, the picker adjusts the quantity inline rather than the flow breaking.Unreadable barcode
Manual code entry sits one tap away, so a failed scan doesn't stop the picker.
TRADE-OFFS
Efficiency added dependencies elsewhere, batching orders into one route only works if the physical handling downstream can keep up.
Accuracy came at the cost of friction, every verification step added is a step the picker didn't have to take before.
Consistency reduced flexibility, removing picker discretion only pays off if what replaces it is genuinely better than judgment.
SUCCESS METRICS
How success would be measured, not results already achieved.
Task success rate — picks matching the order on first attempt.
Throughput — picks per labor hour, ties design to cost.
Time to proficiency — how fast a new picker matches a tenured one.
reflection
This project moved the process off one thing: a picker's memory. The goal wasn't a better screen, it was a system the operation could rely on no matter who was working that shift.
The hardest decisions weren't about the ideal flow, they were about what the system should never let slip through quietly: an incomplete batch, a missed mismatch, a scan that stops someone cold. Those are the moments that cost the business money and cost the picker trust in the tool.
If this went further, the first thing I'd want to test is whether the route stays accurate as the warehouse actually changes, since the whole strategy depends on that route being worth more than the flexibility it takes away.