Zero training, hundreds of dishes.

In all-you-can-eat hot pot, sushi, and BBQ restaurants, guests order in multiple rounds — a single table can accumulate over a hundred, sometimes several hundred dishes, and relying on servers to enter them by hand simply doesn’t hold up at peak hours. Menus are priced in tiers, too: what a table can order depends on which tier it paid for — expecting servers to memorize who may order what, and what’s already been ordered, is neither realistic nor error-proof.

The core question: how do you let a completely untrained guest smoothly self-order hundreds of dishes — while staying within tier permissions and round-based rules?

The users are dine-in guests seeing this interface for the first time — from children to grandparents, with zero training opportunity and zero willingness to learn. This is the exact opposite design premise from Mobile POS, which serves trained servers: the interface must carry zero learning cost. The secondary stakeholders are merchants, who care about operational efficiency and the accurate enforcement of tier and round rules.

Before design began, I conducted field observation in real restaurants, studying how guests behave in actual dining environments. Combined with market research and merchant interviews, this converged on the three demands that mattered most:

• Display ordered items, so guests don’t re-order dishes they’ve forgotten — which wastes food
• Strictly enforce dining round control
• A desire for a full-poster, interactive ordering experience, distinct from the traditional image list

These three demands met three different fates: the first two became core features — and the third’s fate is a story of its own (see “The feature we didn’t build”).

Many AYCE venues are mixed-format — the same restaurant lets a table choose all-you-can-eat hot pot, BBQ, or sushi. So navigation is two-tiered: the top bar carries the dining modes (hot pot, BBQ, sushi, plus drinks and desserts); tap one and a left side-navigation slides in with that mode’s sub-categories — pork, chicken, beef, seafood, veggies, noodles.

Because a table can order hundreds of dishes, a density toggle lets guests switch layouts on the fly: three-per-row for big, appetising photos, or four-per-row to scan far more of the menu at once.

Two ideas I pushed for that didn’t make the cut in the shipped product: a collapsible cart and a collapsible category rail, so guests could hide the chrome and focus purely on the food. The demo below reconstructs the collapsible cart as a concept — still worth revisiting.

Facing tiered menu permissions, the most straightforward approach is to hide dishes a guest can’t order — the cleanest interface. We didn’t take that path. The final solution: greyed-out + lock badge — higher-tier dishes remain visible, just locked.

• For guests: they see the full menu, and never wonder “why does that table have a dish I can’t find?”
• For merchants: a greyed-out higher-tier dish is itself the motivation to upgrade — guests can see it but can’t order it, and the call-server button is exactly that upgrade entry point

The cost is an interface that always looks fuller than one showing only orderable dishes — we accepted the visual density in exchange for the double win of unconfused guests and built-in upgrade motivation.

Round rules differ completely across dining formats — hot pot, sushi, and BBQ each restrict differently. So round control couldn’t be fixed logic; it was designed as a merchant-configurable rule system rendered dynamically in the interface — one interface, carrying different round rules in different restaurants. Guests always see exactly what they can still order this round, which heads off rule disputes between guests and servers before they start.

Around those decisions sits the rest of the ordering flow — the parts that let a whole table’s meal run without a server hovering:

• Cart: the confirmation zone before submitting — quantities and options at a glance, so a shared table order goes in without mistakes
• Order history: guests can check what the table has already ordered at any time, killing duplicate orders — and wasted food — at the source
• Call server: self-service doesn’t mean no service — one tap summons a server for tier upgrades, special requests, or questions, reserving human attention for the moments that genuinely need it

For the poster-style ordering merchants widely asked for, we built a prototype demo to validate the direction — and ultimately decided not to build it:

• Engineering cost didn’t match the payoff: high implementation effort against a small base of merchants it would apply to
• Wrong dining format: poster-style immersion suits high-end dining, while mid-to-low-priced AYCE guests want to order fast, frequently, and in rounds — not admire a beautiful menu

That decision let the team concentrate resources on what the target segment actually needed: navigation that scales, tier permissions, round control, and order history.

A component library and variant architecture let restaurants across merchants and dining formats assemble their own ordering interface from the same components, instead of redesigning from scratch for every new merchant — the delivery foundation behind the 411-tablet rollout.