Design for a guest who is already deciding.
Someone opening a menu on a phone may be walking, coordinating a group, checking a price, or deciding whether the restaurant fits a dietary need. The page should help them answer that question without zooming, rotating the phone, or opening another app.
That means the information hierarchy matters more than decorative motion. Put the menu name, service period, and category navigation before long stories or full-screen photography.
Keep the menu in the page.
Readable HTML adapts to the screen, works with browser zoom, can be navigated by assistive technology, and gives search systems actual text to understand. It is also easier to link directly to a category or item.
If the kitchen or marketing team still needs a printable PDF, keep it as a secondary link labeled clearly with the file type. The on-page menu remains the primary experience.
Use categories that match how people order.
“Starters,” “Mains,” “Desserts,” and “Drinks” are useful because guests know what they mean. If the restaurant has its own service logic—raw bar, tasting menu, lunch, happy hour, late night—use that language consistently across the page and reservation flow.
For long menus, add category links near the top and a clear way back. Avoid a horizontal carousel that hides categories off-screen without a strong cue.
Keep each item complete.
- Place the price next to the item it belongs to.
- Use concise descriptions for ingredients or preparation details that change the decision.
- Define dietary symbols in text and apply them consistently.
- State when prices, availability, or menus can change.
- Do not put essential information inside an image.
Separate browsing from ordering.
A guest may want to read the menu without starting an order. Keep “View menu,” “Order online,” and “Reserve” as distinct actions. If ordering happens on another platform, label the destination and open the correct restaurant or location.
A persistent action can help on mobile, but it should not cover menu items, prices, or accessibility controls. Test it at narrow widths and at 200% zoom.
Plan for menu changes before launch.
A beautiful menu that nobody can update will become inaccurate. Decide who owns item names, prices, availability, dietary notes, and service periods. Give that person a process that does not require editing code.
For multiple locations, make the active location unmistakable and prevent a global menu from silently overriding local differences.
Test the decisions, not only the layout.
- Can someone find a specific category in a few taps?
- Can they enlarge the text without losing prices or actions?
- Does the correct order or reservation destination open?
- Do dietary notes have text equivalents?
- Does the menu remain usable when an image or script fails?
- Can the restaurant update it before the next service?
Worth remembering.
In five lines.
- HTML first; PDF second.
- Use familiar categories and complete item information.
- Keep browsing, ordering, and reserving distinct.
- Do not let sticky actions cover the menu.
- Design the update process with the page.
Read next.
Is the menu doing too much work?
Show us the current guest path. We will reply with fit questions and the next available step.