Problem
I work in a restaurant kitchen, and most restaurant tech ignores the part I actually live in. Ordering, payment, and delivery get all the attention; what happens after the order hits the line, how it reaches the people cooking it, barely gets touched. And a kitchen isn't one person doing one task. It's a crew working the same order at once, under constant time pressure.
Process
I started where I assumed the problem was: the screen. Better layout, clearer tickets, tighter hierarchy. It fell apart fast. Every screen I drew raised a question a screen couldn't answer — who owns this task, when does it start, who needs to know it changed. The real problem wasn't the interface; it was how information moves through the kitchen.
The fix came from a user flow. I stopped drawing screens and mapped how an order actually travels — who touches it, who owns it, what triggers the next step — and the moment I could see it end to end, the project had a spine.
From there the decisions answered themselves. Each station became its own user — cook, apps, expo — shown only what it needs while staying in sync with the rest. I leaned on state instead of clutter, so a cook reads a ticket at a glance, and the timer became a ring that fills as it counts down, urgency you can read without numbers. The whole thing is built for a real service, interruptions, modifiers, and mistakes included, not an ideal one.
Outcome
The result is a distributed system where cook, apps, and expo all work from the same picture of a constantly changing order. The screens are the visible part; the real deliverable is the workflow underneath them. I spent the first half of this designing screens and the second half designing the system — and the second half is the one that mattered. Screens are outputs. The system comes first.
