Bukalapak's offline retail arm counted inventory by hand. Each count took about two and a half days and forced a store to close, so every count meant lost sales, and constant mismatches put storemen at risk of penalties. My work: find the real reason it was so slow, and design it away.
If you never go to where the problem lives, you'll design a beautiful solution to a problem that doesn't exist.
On paper this looked like a flow problem, the kind you fix at your desk by tidying screens and cutting steps. But the count fed the replenishment from headquarters, so a wrong number meant the wrong stock arrived: a store could end up short and lose sales, and a missing item could land on a storeman as a penalty. Real revenue and real people were riding on a process that moved at the speed of a manual count.
The instinct was to redesign the counting flow. I wasn't convinced the flow was the problem, so before I touched a screen I went to a store, and I went on its busiest day, so I could watch a storeman serve customers and count stock at the same time.
On the floor the real constraint showed itself in minutes: the warehouse had almost no internet, but the tool required a live connection to count, and a dropped signal could corrupt a count in progress. So instead of polishing the flow, I redesigned the model underneath it. I separated capturing the count from syncing it.
- A storeman gets the day's item list, taps Start, and the whole count runs locally, with no connectivity check that a weak signal could break.
- Only at Finish does it reconcile against headquarters and surface mismatches for a restock-or-write-off decision.
- Because I scoped it as store locally, sync once, rather than live sync, it was far cheaper to build than the team expected, which is how I got engineering behind it.
The same visit surfaced smaller fixes I built around it: barcode scan to jump straight to the right SKU, a list view so long product names stop truncating, and location notes so a storeman knows whether an item sits in the main store, the backroom, or the chiller.
Before handoff, I ran a partial count myself on the shop floor with the supply chain business lead, to test the design against the real job. The numbers come from that field simulation. Spread as small daily counts, stocktaking was projected to go from about two and a half days to zero, with no store closure and no lost sales during the count, roughly $34K a month in lost GMV prevented, and 98.5% data accuracy across the 25 stores in scope. It would also take the penalty risk off the storemen.
The rule I kept from it: the hard part of design isn't the craft, it's finding the right problem, and you only find it where the work actually happens.
This became the first design blueprint I documented in full, and later taught to other designers in a workshop, so the way of working outlasted the one project.