12 Restaurant Menu Design Mistakes That Hurt Mobile Ordering

Use the PATH audit: Place, Arrange, Tell, Hand off

The PATH framework turns a visual review into a journey review:

Audit in PATH order rather than starting with colours or photography. Mark each check **pass**, **fail** or **not applicable**. “Not applicable” is important: a view-only QR menu with table service should not be penalised for lacking a cart. Record the exact screen, item or interaction behind every fail. That evidence turns “the menu feels confusing” into a repair someone can implement.

Severity describes the default consequence within the menu journey, not a measured business effect:

Effort is a planning estimate, not a promise. **Low** usually means a content or configuration edit, **medium** means several coordinated edits, and **high** means a template, integration or system change. Adjust effort to match your own publishing and ordering stack.

• **Place** covers arrival: the QR code or link must resolve to the intended menu and identify the relevant service or location.
• **Arrange** covers orientation: categories, hierarchy, controls and type should make the page navigable on a small screen.
• **Tell** covers decision information: descriptions, prices, images, modifiers and dietary notes should answer what the item is and what choosing it involves.
• **Hand off** covers completion and upkeep: where ordering is available, the transition to the ordering system should be understandable; in every case, the published menu needs a repeatable review process.
• **Blocking:** the guest cannot reliably reach the intended content or complete a required step.
• **Confusing:** the journey remains possible, but information or interaction is ambiguous.
• **Cosmetic:** the issue mainly affects consistency or polish while the task remains clear.

The 12-point Mobile Menu Friction Audit

| # | Check and common mistake | Observable pass/fail criterion | Default severity | Typical effort | Recommended action | |---|---|---|---|---|---| | 1 | **QR destination:** sending people through the wrong or confusing page | **Pass:** scanning the code opens the intended current menu and the first screen identifies the relevant location or service. **Fail:** it opens an unrelated homepage, obsolete menu, error, sign-in wall or ambiguous destination. | Blocking | Medium | Point the code to a stable hosted menu; identify location and service near the top; retest every printed placement. | | 2 | **Menu structure:** hiding categories in one continuous page | **Pass:** a person can see or reach recognisable sections without reading every preceding item. **Fail:** unrelated dishes form an undifferentiated list or category navigation does not lead where expected. | Confusing | Low | Group items by the way guests look for them; use concise section names and dependable section navigation where needed. | | 3 | **Visual hierarchy:** styling every element with similar weight | **Pass:** section, dish name, description, price and action have distinct, repeatable roles. **Fail:** the reader must infer which text belongs together. | Confusing | Medium | Establish one item pattern and repeat it; prioritise names and prices; use spacing to separate records. | | 4 | **Controls:** making taps uncertain | **Pass:** interactive elements are visually identifiable, separated from neighbours and usable without accidental activation during a one-handed review. **Fail:** controls are crowded, ambiguous or provide no obvious route back. | Blocking | High | Enlarge the interactive area available in the template, separate adjacent actions, label controls plainly and provide clear back or close actions. | | 5 | **Dish details:** burying decision-critical information | **Pass:** the item view states the dish’s main components and relevant choice information where the decision is made. **Fail:** essential details require repeated opening, guessing or searching elsewhere. | Confusing | Low | Lead with concrete ingredients or preparation; keep supporting copy concise; place essential notes with the item. | | 6 | **Prices:** separating cost from the item or option | **Pass:** the base price sits with the item, and each size, add-on or substitution shows its price effect where selected. **Fail:** the reader must match distant columns, infer a starting price or discover an option charge later. | Confusing | Low | Use one currency format, label starting prices, and place option charges beside the options that create them. | | 7 | **Images:** letting photography displace menu information | **Pass:** selected images support identification, use a consistent treatment and leave complete text available. **Fail:** imagery dominates the screen, crops unpredictably, or carries information absent from the text. | Cosmetic | Medium | Keep only decision-useful images, use consistent crops, optimise files in the publishing workflow and retain complete written descriptions. | | 8 | **Modifiers:** treating choices as an unstructured add-on | **Pass:** required and optional groups are labelled, permitted selections are clear, incompatible choices are handled, and price effects appear with options. **Fail:** a valid configuration requires guessing or backtracking. | Blocking | High | Order choices as a natural conversation: required base choice first, then preparation, sides and optional additions; review the selection before submission. | | 9 | **Readability:** importing print styling without a mobile check | **Pass:** text remains distinguishable over its background, lines are comfortable to follow, and increased browser text does not hide essential information. **Fail:** decorative type, centred blocks, image overlays or cramped spacing impede reading. | Confusing | Medium | Use a legible body face, left-align longer copy, simplify backgrounds and test text enlargement on actual phones. | | 10 | **Dietary and allergen information:** using unexplained or inconsistent labels | **Pass:** any labels used are defined, applied consistently and tied to a maintained internal source of truth. **Fail:** symbols are unexplained, similar items use conflicting labels, or the menu makes unverified assurances. | Blocking | Medium | Pair symbols with words, define the legend, reconcile the menu against current recipe and supplier information, and route uncertainty to staff rather than guessing. | | 11 | **Ordering handoff:** ending the menu without a clear next step | **Pass:** for an order-enabled menu, selected items, modifiers, price information and the next action remain understandable at the handoff. For table service, the menu clearly indicates the service method. **Fail:** the user encounters an unexplained change of system, loses selections or cannot tell what to do next. | Blocking | High | Review the boundary between menu and ordering provider; use explicit action labels and service instructions; do not imply online ordering when the page is view-only. | | 12 | **Maintenance:** designing once and leaving no ownership | **Pass:** an owner and trigger exist for checking links, availability, prices, labels and parallel print versions. **Fail:** nobody can say when the live menu was last reconciled or who handles a change. | Confusing | Low | Assign an owner, connect reviews to operational changes, scan deployed codes and record the corrected version. |

Do not total these checks into a universal “mobile score”. A single blocking fail can matter more than several cosmetic issues, and the relevant checks differ by service model. Instead, sort failures by severity, then by how early they occur in PATH. If two items are equally severe, address the lower-effort repair first unless one depends on the other.

How to inspect the menu without inventing a usability test

This protocol is an operational review, not user research. It produces observations about the current menu but does not establish how all guests behave.

1. **Define the route.** Write the exact location, service period, QR placement and intended completion method: online order, counter order or table service. 2. **Choose representative items.** Include a simple item, an item with required choices, an item with optional additions and an item carrying dietary or allergen information. If a type does not exist, mark it not applicable. 3. **Start from the deployed entry point.** Scan the printed code or open the public link. Do not begin from an editor preview or saved browser tab. 4. **Follow PATH once without editing.** Note the first point where the intended route becomes impossible or uncertain. Capture the page and element, not a judgement about the guest. 5. **Complete the table.** Mark every row pass, fail or not applicable. Record severity changes justified by the service model and identify the likely owner. 6. **Repair blockers before presentation.** A wrong link, unusable required choice or ambiguous handoff precedes image consistency and decorative refinements. 7. **Repeat the same route.** After editing, verify the specific failed criteria again and check that the repair did not create a new problem elsewhere.

For broader coverage, repeat the review on the phone and network conditions already available to your team. Do not convert those observations into claims about all devices or all customers. If the menu relies on a separate ordering provider, review both sides of that boundary and record which team owns each fix.

Example: hypothetical neighbourhood café lunch menu

This example is deliberately fictional. It demonstrates how to document a repair; it is not a customer result or evidence of improved orders.

**Route:** a table card opens a lunch menu for table service. Guests read on the phone and order from a server. The sample reviewer checks a soup, a sandwich with a required bread choice, and a salad with an optional protein addition.

**Before audit**

| Check | Finding | Mark | Priority decision | |---|---|---|---| | QR destination | The code opens a general venue page; “Lunch” appears only after another navigation step. | Fail — blocking | Repair first because it interrupts Place. | | Structure | Drinks, lunch dishes and desserts appear in one long sequence. | Fail — confusing | Add familiar sections after the destination is corrected. | | Prices | The sandwich base price is visible, but the protein addition price appears only in a note below the salad section. | Fail — confusing | Move the charge to the relevant option. | | Modifiers | Bread is required, but the two choices look like optional notes. | Fail — blocking | Label “Choose one bread” and present both choices together. | | Ordering handoff | The page says “Add”, although the café accepts table orders only. | Fail — blocking | Replace the misleading action with accurate table-service guidance. | | Images | Three dish images use different crops, but names and details remain readable. | Fail — cosmetic | Defer until the journey is clear. | | Other checks | Their criteria are met in this hypothetical review. | Pass | Verify again after edits. |

**Proposed after state**

The same QR destination opens the lunch menu directly and identifies lunch and table service on the first screen. The menu has Drinks, Lunch and Dessert sections. “Choose one bread” is attached to the sandwich, while the optional protein and its charge sit together on the salad. The misleading add action is removed and the page explains that guests order with their server. Finally, the three retained photographs use one crop treatment.

A second audit would not declare success from the edits alone. It would rescan the deployed code and repeat the same item route. The after state passes only if the observable criteria are now met. No conversion, speed or customer-satisfaction conclusion follows from this hypothetical exercise.

Implementation sequence for a live menu

1. Create a repair register.

For each failed row, record the URL or QR placement, exact item or control, PATH stage, severity, owner, proposed action and verification status. Avoid vague tasks such as “improve mobile”. A useful task reads: “On the lunch menu, place the optional protein charge beside the salad modifier and verify it in the published view.”

2. Separate content fixes from system fixes.

Content fixes include category names, dish descriptions, service instructions, labels and price presentation. System fixes may include QR routing, templates, control behaviour and an external ordering integration. This separation prevents a copy edit from being treated as a solution to an interaction problem.

3. Reconcile the source information.

Confirm current dishes, availability, prices, modifier rules and dietary information with the people and records responsible for them. The audit can expose ambiguity; it cannot decide recipe facts. When information is uncertain, resolve it before publishing rather than making the interface look more definite than the source material.

4. Publish the smallest coherent repair.

Do not release half of a dependent change. A new required-choice label and its associated options belong together. Likewise, changing a QR destination requires checking the codes already deployed. Group dependent edits, while keeping unrelated cosmetic work out of an urgent blocking repair.

5. Verify the public version.

Use the deployed QR code and public page, not only the editing interface. Repeat the representative routes, check any parallel print menu affected by the same change and close the register only after the observable criterion passes.

If your current workflow makes version control difficult, [MenuCrafters](https://menucrafters.com/) supports an editable hosted mobile menu, a permanent QR link and print-ready PDF output from the same menu source. Those publishing features can reduce duplicate editing, but they do not replace checking recipes, prices, service instructions or a separate ordering system.

Limitations and trade-offs

The PATH audit is a structured editorial and interaction review. It is not controlled usability research, accessibility certification, legal advice, performance benchmarking or proof of commercial impact. A pass means the stated criterion was observed on the route reviewed; it does not guarantee that every guest, device, language or assistive technology will have the same experience.

Some recommendations also conflict in legitimate ways:

Mark checks not applicable when the service model genuinely excludes them. A table-service menu does not need a digital cart, and a text-only menu does not fail the image check. If you need evidence about real guest behaviour, conduct appropriately designed research with representative participants rather than treating this scorecard as a substitute.

• **Direct access versus context:** opening straight to a menu reduces navigation, but multi-location restaurants still need unmistakable location and service identification.
• **Concise copy versus complete detail:** short descriptions aid scanning, but ingredient, preparation, size and dietary information must not be removed merely to make the page shorter.
• **Selective images versus visual identification:** fewer images simplify the page, while unfamiliar dishes may benefit from accurate visual context. Images should support rather than replace factual text.
• **Persistent navigation versus screen space:** category controls can reduce repeated scrolling, but a large fixed bar can obscure content on a small display.
• **One source versus channel differences:** shared information helps consistency, yet mobile, table tent and full print layouts may need different presentation. Reconcile facts even when layouts differ.
• **Fast content repairs versus platform constraints:** wording and grouping may be easy to change; control size, modifier logic and ordering handoffs can require work by a platform or integration owner.