Designing for hawker speed: checkout flows under 10 seconds
Lessons from a payments prototype for hawker stalls that never shipped, and why we still use them.
At 12:30pm on a weekday, a hawker stall serves a customer every 20 seconds. Any payment flow that takes longer than the cooking is a problem. We learned this on a six-week prototype for a group of stallholders who wanted a faster way to take payments. Designing for that context taught us more about speed than any design system ever has.
Watch first, design second
We spent three lunchtimes standing beside stalls with a stopwatch. The longest delays weren’t the payment itself. They were finding the right app, typing the amount and waiting for confirmation while the next customer was already ordering.
What we changed
- The amount comes first, and it’s huge. Big numerals, no decimals unless needed, a keypad with the most common prices as shortcuts.
- One screen, one action. No confirmation dialogs. Mistakes are reversible for five minutes instead.
- Confirmation you can hear. A distinct sound and a full-screen green state, readable from a metre away with greasy hands.
- Works offline. Hawker centres have famously bad signal. Payments queue and sync.
If the merchant has to look at the phone for more than a second, we’ve already lost.
Testing in context
We tested prototypes during real lunch rushes, not in a meeting room. Our first version took 14 seconds on average; our final prototype took 7. The biggest single improvement came from removing a screen we thought was essential.
The prototype never shipped. At the end of the six weeks, the stallholders decided the bank QR codes they already had were good enough, and they were probably right. The lessons stayed with us, though, and shaped the merchant app in our cross-border collections work: find the moment of maximum pressure, and design for that, not for the calm demo.
