Designing a menu for a kiosk screen

When a kiosk underperforms, the menu is usually the reason. Operators tend to load the same structure that works on a wall board, then conclude that guests do not like kiosks. A board is read all at once by someone standing back from it; a screen is read one panel at a time by someone touching it. Those are different design problems.

Fewer categories, shallower paths

Every category is a decision, and every decision is a place to stall. A long category list on a screen is worse than the same list on a board, because the guest cannot take it all in at a glance and has to scroll to discover what exists.

• ✓Aim for a category count a guest can see without scrolling on your actual screen size.
• ✓Lead with how guests think — meal occasion or item type — not how your kitchen is organised by station.
• ✓Collapse near-duplicate categories. Two categories with three items each read as clutter; one with six reads as choice.
• ✓Count taps to a finished order for your most common item. If it is more than a handful, the path is too deep.

Photograph the sellers, not everything

Photos do more work on a kiosk than anywhere else in a restaurant, because they are the only description most guests will read. But a half-photographed menu is worse than a consistently unphotographed one: items without an image read as unavailable or second-rate next to items with one.

If you cannot photograph everything, photograph complete categories. Consistency within a screen matters more than coverage across the menu.

Modifiers are where orders are lost

Modifier design is the single biggest lever on both time-per-order and abandonment. A guest facing six required choices to buy a sandwich will take a long time, and some proportion will simply leave the screen.

• ✓Set sensible defaults so the guest can accept rather than choose. Every default is a step removed.
• ✓Make genuinely required choices required, and make everything else optional and skippable.
• ✓Name modifiers in guest language, not kitchen shorthand. The line can read a ticket; a guest cannot read your abbreviations.
• ✓Put the upsell after the item is in the basket, not in the middle of building it. Interrupting a decision costs more than the add-on earns.

Write for a screen, not a board

Item names carry more weight on a kiosk because there is no server to interpret them. A clever name with no description is a gamble; the same name with one short line of plain description is a sale. Keep descriptions to a single line that fits without truncation, and put allergen and dietary information where a guest can see it before committing rather than after.

Keeping one menu across every channel

The practical obstacle to iterating on a kiosk menu is usually that it lives somewhere separate. If updating a price means doing it on the POS, then the kiosk, then the QR menu, the menu stops being improved because improving it is expensive.

Opero runs one menu spine across the POS, kiosk, QR ordering and the kitchen display. Change a price once and it changes everywhere; 86 an item at the register and it disappears from the kiosk in the same moment. Per-location menus can be built once and copied then edited, so a second site starts from your best version rather than a blank screen — which means the menu work in this guide is done once, not once per channel.