Designing one calm system for a restaurant's busiest hours.
The waiter on their feet, the kitchen mid-rush, and the guest at the table, three roles, three devices, one product.
Understanding the problem
Three users, not one
Waiter, kitchen, guest. Same information, three completely different hands.
Rules nobody writes down
Noise, grease, one thumb, a two-second glance. New staff had to get it in one shift, not one week.
Where the money leaks
Orders lost between floor and kitchen, dishes fired twice, guests who can't pay. Every leak was a design problem.
The approach
One system, three screens
A colour means the same thing on every device; a price is formatted once, in a shared foundation.
Built for the rush, not the demo
The most frequent action is the biggest, closest target. Anything costing an extra tap during service was cut.
Map the whole loop
I mapped the full service, QR scan to cleared table, across all three roles. That map caught the leaks before they shipped.
Designing the flows
The service looked simple. It wasn't, product edits, split payments, returns, cancellations, transfers. I expanded every branch with the developers, then collapsed it into a few calm screens per role.
Coursing, the detail that proves you were there
The kitchen doesn't cook a whole order at once, starters now, mains later. So the station lets the kitchen group items into courses and fire each when it should be cooked. Making meal-timing the default, not extra work, is the kind of decision you only make after standing at a real pass.
From wireframe to final
Same screen, three fidelities. Structure is locked in grey before a single colour is chosen; the final surface only adds what the grey layer proved it needed.
Guest self-ordering, menu, cart, call waiter & pay. Food images are left as labelled placeholders for real photography.
The system
The command center
A live table map (grid ⇄ list) split into "my tables" and "others," with search. From here: order approval, item edits, adding new orders, table & order transfer with hand-back approval, cancellations, and payment.
The ticket rail
Incoming orders land as receipt cards, grouped into courses the kitchen fires one at a time. Auto-print (ESC/POS), countdown badges, and distinct sounds for send / print / ready.
Self-service ordering
Multi-language menu, basket, live order status, and a "request to pay" signal, so the guest is never stuck waiting to catch a waiter's eye.
The screen we rebuilt the most.
Full bill, split by item, split by amount, partial payments, and card and cash in one transaction, all had to live on a single screen without overwhelming a waiter mid-rush.
The core gesture reduced it to one motion: swipe the tile to Card or Cash. The calculator handles splits, change and remainders.
Decisions I'd defend
Transfer with hand-back approval
A waiter can pass a table to a colleague, but the receiver has to accept it. Ownership never changes silently, which kills the "who's got table 9?" problem mid-rush.
Real-time, one source of truth
Empty, seated, ordering, food ready, wants to pay: each is a distinct live state shown the same way on every device, so the floor and kitchen never disagree.
Designed offline states
When the network drops, the app tells the truth, queues actions locally, and syncs on reconnect. The waiter keeps serving.
Friction only where it's costly
Cancelling asks for a reason; irreversible actions confirm. Everywhere else, zero friction.