Designing a Guest Ordering Flow That Balances Speed, Clarity, and Admin Control

The guest does not arrive to admire the information architecture. They arrive with a phone, a table and the small question of whether they can get the thing they have just found on the menu. A flow that asks them to understand venue configuration before answering that question has misplaced its effort.

My first instinct was to make the guest page as flexible as the admin system. That produced the familiar dense result: controls that mattered to staff appeared near controls that mattered to somebody trying to order a pint. It was technically expressive and socially unhelpful.

The better division is deliberately uneven. The guest surface moves through a small sequence—entry or table context, menu, basket, checkout—and keeps the current decision visible. The admin surface holds the variations: what appears in the menu, whether ordering is available, which payment connection is live, and how the venue wants its discovery view arranged.

This became clearer while separating the menu display modes. “Simple” and “custom filters” looked like a presentational choice until the same setting had to be understood by an editor, stored in tenant settings, mirrored through SQL and rendered in the guest feed. Making the modes explicit gave staff a predictable control and stopped the guest UI from having to infer intent from a collection of loose options.

The same rule applies to availability. A closed venue should not pretend that checkout is possible, but it should still explain the visible state without making the menu look broken. When a guest-facing setting is unresolved, the safer default is not to expose a half-enabled ordering action. That costs a little optimism during a configuration problem; it avoids a promise the service cannot keep.

Mobile detail follows from this rather than sitting on top of it: readable basket summaries, sensible tap targets, status text that says what happens next, and wallet-first checkout where the environment supports it. None of those details repairs a confused state model.

I now resist the temptation to call every missing step “friction”. Some steps are clutter. Others establish the table, venue or payment state that makes the next action trustworthy. The job is to remove the first kind without accidentally removing the second.