Before launching a QR menu, ask several people to scan it on different phones and complete ordinary guest tasks without coaching. Watch whether they can open the menu, read it comfortably, find an item, and understand how to get help. Record where they struggle, fix the most consequential problems, and repeat the same tasks.
A successful scan alone is not enough. A guest may reach the menu but find the text too small, miss the drinks section, or mistake a list of dishes for an ordering screen. Test the whole path a guest actually needs to use, and keep a staffed alternative available.
Choose people and devices that expose problems
Start with staff members who have not built the menu. Someone who already knows every category can overlook a confusing label. Include people with different comfort levels using phones and, where possible, different visual or access needs. Ask what would make the session comfortable, but do not ask anyone to disclose a diagnosis.
Use the phones and browsers participants normally use. Aim for a mix of operating systems, screen sizes, newer and older devices, and at least two browsers. You do not need a device lab; you do need more than the manager's phone. Note the general device and browser combination so you can investigate a problem later.
Try the menu on your restaurant Wi-Fi and on a mobile connection. If reception varies around the dining room, include a spot where guests commonly sit and a spot where the signal is weaker. Make sure participants know which connection they are using. A menu that opens quickly at the host stand may behave differently at a back table.
Place the printed code where a guest would encounter it. Test under ordinary service lighting, including a dimmer table if you have one. Check whether glare, a curved holder, a dirty surface, or a code placed too far away makes scanning awkward. Leave the participant free to move the phone as a guest would.
Consider inviting a small number of people outside the staff to try the same tasks before launch. They may interpret category names differently. Keep the invitation voluntary and use a practice setup that does not send real orders or messages.
Run the same scan, reading, and discovery tasks
Give each participant the same starting instruction: “You have just sat down and want to look at the menu.” Avoid explaining which camera setting to use or pointing at the right link. If they ask for help, note the point at which help was needed, then offer it. The goal is to find obstacles, not make anyone pass a test.
- Scan and open: Find the code, scan it, and reach the menu. Notice whether the person recognizes what to do, whether the link opens, and whether the page appears usable on the chosen connection.
- Read an item: Ask the person to read a dish name, description, and price. Look for text that requires repeated zooming, low contrast, clipped lines, or a layout that moves unexpectedly.
- Find a specific item: Ask for a common item in a category the participant has not been shown. Then ask them to find a second item in another category. Watch whether the labels and navigation make sense without your explanation.
- Find a way back: Have the person return to the category list or move from food to drinks. A menu can be easy to enter and frustrating to navigate once a guest goes deeper.
- Ask for help: Ask what they would do if they could not scan or had a question about a dish. Check whether the staffed alternative is visible and understandable.
Ask participants to say what they expect before they tap. Their expectations can reveal whether a button looks like a category, an item detail, or an order action. After each task, ask what was confusing rather than suggesting the answer.
If the menu supports larger text, screen readers, or other accessibility settings, try the relevant controls with participants who normally use them. Check whether content remains readable and whether navigation still makes sense. Do not treat one person's experience as proof that the menu works for everyone; use it to identify questions and improvements.
Keep menu viewing separate from ordering and payment. If you are considering where QR ordering fits in table service, decide whether guests should only browse, place an order, or also pay. Label the screen and staff instructions accordingly. For any ordering practice, use a simulation that cannot create a real payment, guest message, or courier dispatch.
Record task outcomes without personal data
Use one row per device and connection condition, not a profile of the person holding the phone. Record the device type, browser, connection, task outcome, and the obstacle you observed. A short note such as “drinks category label overlooked” is more useful than “user struggled.” Do not record names, phone numbers, payment details, screenshots of personal notifications, or a participant's medical information.
Choose pass criteria before anyone starts. For a basic menu check, a pass could mean the participant opens the menu and completes each discovery task without a hint, while reading the relevant details at a comfortable size. A pass does not require everyone to use the same gestures. Mark a task as assisted if a hint was needed, and as failed if it could not be completed during the session.
The following worksheet is a hypothetical example, not a report of an actual test. The operator wants every participant to open the menu and find both requested items without a hint before relying on the code as the main menu route. There is also a staffed alternative. Each row represents one participant using one device and connection; the results are task outcomes, not a measure of the whole guest population.
| Device and connection | Open and read | Find items | Decision note |
|---|---|---|---|
| Small phone, mobile data | Passed | One item needed a hint | Review category label |
| Larger phone, restaurant Wi-Fi | Passed | Both passed | Keep as a comparison |
| Older phone, mobile data | Opened; text was uncomfortable to read | Not completed | Fix text layout, then repeat |
| Small phone, restaurant Wi-Fi | Passed | Both passed | Keep as a comparison |
In this example, two of four participants completed all tasks without help. One needed a navigation hint, and one could not comfortably read the menu and did not complete discovery. That falls short of the operator's chosen threshold. The next decision is to fix the text layout and category label before making QR the main menu route, then repeat the complete task set. The table does not establish how often guests will encounter those problems.
Keep notes specific enough to reproduce an issue: which page, which task, and what happened. If a page failed to open, note the connection and location. If a label caused confusion, write down the label and the destination the participant expected. Avoid recording a person's spoken comments verbatim if they include identifying details.
Fix the blockers, then repeat the full path
Prioritize problems that prevent access or understanding. A code that will not scan, text that cannot be read comfortably, and a missing route to staff deserve attention before a minor visual preference. Then address navigation problems that cause people to ask for hints or abandon an item search.
Give each issue an owner and a specific action. For example, replace a code holder that reflects light, enlarge or reflow menu text, or rename a category after checking what guests expect to find there. Ask your menu provider which changes you can make yourself and which require its help. Do not assume every layout or accessibility control is available in every product.
After a change, repeat the original tasks on the affected device and connection. Also try the full path on at least one condition that previously worked: a change made for one screen can create a problem on another. If possible, include someone who has not already learned the menu. Record whether each task now passes, needs help, or still fails.
Keep a non-phone route ready even after the menu passes your checks. Staff can bring a readable printed menu or explain the options in person. Tell the team where the alternative is kept and how to respond when a guest cannot scan, has a connection problem, or simply prefers not to use a phone.
If you later add table ordering, evaluate the handoff separately from menu readability. Ask how the system identifies the physical table, how staff see an order and its payment status, and what happens when a guest needs help. Fleksa's QR ordering lets guests scan, order, and pay at the table in a browser without downloading an app. Ask how that workflow would be configured for your service, including its connection to your restaurant POS system.
As a next step, take your task list and fallback plan to Fleksa and compare the QR workflow against your operating requirements. Use a simulation for practice; only consider a live service pilot after staff understand the workflow and you have a plan for real guest orders and payments.
Frequently asked questions
How many phones should I use to test a QR menu?
There is no single number that proves a menu works for every guest. Use several phones with different screen sizes, operating systems, browsers, and connection conditions. Add devices or participants when an important access need or common service condition is missing.
What if the QR code scans but the menu is hard to read?
Treat readability as a blocker, not a successful test. Check text size, contrast, and layout on the affected phone, make the available changes, and repeat the reading and navigation tasks. Offer a staffed alternative in the meantime.
Should I place a real order during a practice test?
No. Use a simulation that cannot trigger a real payment, guest message, or courier dispatch. If you later run a live service pilot, plan it separately so staff know how to handle real orders, payment status, and guest questions.
