Start with the choices a guest must make before an item can be added to the order. Those prompts need the most attention: if a guest cannot tell what is required, how many options to pick, or what a selection costs, the order may stop there. Next, check choices that can contradict one another or change what the kitchen must prepare.
A good restaurant kiosk menu modifier design gives guests a clear next action and gives the kitchen a usable instruction. Test both ends of that path. A selection that looks correct on the guest screen is not enough if the review price or kitchen ticket tells a different story.
Map required and optional choices
Pick one item with several decisions, not your entire menu. A bowl, pizza, burger, or combination meal works well if guests regularly customize it. Write down the choices in the order a guest encounters them, including decisions that appear only after another selection.
For each group, identify the minimum and maximum selections. Then separate what the guest must choose from what they may change. “Choose one base” is a different instruction from “Add up to two toppings.” If a guest can skip a group, say so. If an option carries a charge, show the amount where the choice is made and make sure it appears in the review total.
Hypothetical worksheet: A restaurant sells a $12 bowl. The guest must choose one base and one protein. Avocado is an optional $2 addition, and extra sauce is an optional $1 addition. Removing the standard onions has no charge. The table shows which prompts need to change before this item is ready for a practice run.
| Choice | Rule and price | Unclear prompt | Clearer prompt |
|---|---|---|---|
| Base | Choose exactly one; included | “Base” | “Choose one base” |
| Protein | Choose exactly one; included | “Protein options” | “Choose one protein” |
| Avocado | Optional; add $2 | “Avocado” | “Add avocado for $2? Optional” |
| Extra sauce | Optional; add $1 | “Sauce” | “Add extra sauce for $1? Optional” |
| Onions | Included by default; removal is free | “Onions” | “Standard onions included. Remove onions? No charge” |
The table does more than improve wording. It exposes rules the menu must enforce. If the screen lets a guest select two bases even though the kitchen expects one, a clearer label alone will not fix the problem. Ask the vendor how to set selection limits and how the screen responds when a guest reaches one.
Also examine defaults. A preselected option can save a tap, but the guest must be able to see and change it. For an included ingredient, distinguish “included” from “added for a charge.” Avoid making a guest guess whether tapping an ingredient adds it or removes it.
Test missing, conflicting, and nested choices
Work through the bowl as a guest would, using a demonstration or test environment. First, try to add it without a base. The screen should identify the missing decision near the relevant choice and give the guest a way to correct it. A generic message such as “Invalid selection” leaves too much work to the customer.
Then choose a base and try to select a second one. Check whether the second tap replaces the first choice or is blocked. Either behavior needs to be understandable on screen. Repeat the exercise for protein. A guest should not reach the review screen believing two choices were accepted when the kitchen will receive only one.
Next, try choices that conflict. For example, remove onions and then try to add onions through another modifier group, if the menu has one. Decide the intended outcome before testing: should the menu prevent the combination, or should the guest be asked to resolve it? The important point is that the final order must not silently carry opposing instructions.
Nested choices deserve a separate pass. Suppose choosing sauce opens a choice of sauce type. The screen should make clear whether that follow-up is required and how it relates to the extra-sauce charge. If the guest changes their mind and removes extra sauce, check that the dependent sauce choice and its charge are removed too. If the software handles dependencies differently, ask the vendor to demonstrate the behavior before committing to the menu structure.
Use these checks for every high-risk item, especially where a choice changes the preparation method, creates a charge, or reveals another required decision. Simple optional additions may need less attention than a required choice with several branches.
Match the review screen to the kitchen ticket
For the same hypothetical bowl, select rice, chicken, avocado, extra sauce, and no onions. The item review should show a $12 base price plus $2 for avocado and $1 for extra sauce: $15 for the customized item. The rice and chicken are included, and removing onions adds nothing. This is an item sale price, not an operating-cost calculation; it excludes any separate order-level charges, taxes, and payment processing fees.
Now inspect the mock kitchen ticket or display for that exact selection. Kitchen staff need to see rice, chicken, avocado, extra sauce, and no onions in language they can act on. Compare the ticket with the review screen line by line. A correct $15 total does not prove that the “no onions” instruction reached the kitchen.
Ask a cook or expediter to read the mock ticket without seeing the kiosk screen. Can they tell which sauce is extra and which ingredient is removed? Can they distinguish an included choice from an addition that changes the build? Note any abbreviation or grouping that requires a staff member to interpret the guest’s intent.
Then change the order before completion: remove avocado and confirm the item price returns to $13. The revised mock ticket should no longer request avocado. Also check that the other selections remain intact. This catches a different problem from the first pass: an edit may change the price correctly while leaving an outdated preparation instruction behind.
Review how the kiosk connects to the restaurant POS system and, if used, the kitchen display system. Ask which modifier names and edits appear on each screen or printed ticket. Do not assume the guest-facing label and kitchen-facing label will be identical, or that every integration handles changes in the same way.
Revise prompts and retest with staff
Turn observations into a short change list. Record the item, the guest action, what appeared on the screen, what the kitchen received, and the intended result. Assign an owner for each change: menu wording may be yours to update, while selection limits or ticket formatting may need vendor help.
Retest each change from the beginning of the item, not just from the screen where the issue appeared. A new prompt can solve one problem while hiding another. For example, a more prominent add-on may make the charge clearer but make the included ingredient harder to find. Check the item review and mock ticket again after every change that affects a selection or price.
Give staff realistic tasks without telling them which buttons to press: order the bowl without onions, add extra sauce, then change your mind about avocado. Ask where they hesitated and what they expected to happen. Watch for a pause before a required group, repeated taps on a selection limit, or a review screen they cannot reconcile with their choices. Those are signs that the prompt or rule needs another pass.
Keep practice safe. Use a simulation or vendor-provided test setup that cannot take a real card payment, send a guest message, or dispatch a courier. Confirm those safeguards before starting. A simulated check is useful for menu logic and mock tickets; it is not proof of how every part of a live service will behave.
Once the practice checks pass, plan a separate, supervised live service pilot with staff ready to assist guests and handle errors. Agree on who can pause kiosk ordering, how staff will enter an affected order through the normal fallback, and how issues will be recorded. Monitor real tickets and order edits rather than promising uninterrupted service. Afterward, revise the menu before expanding the pilot.
For the next step, take one complex item and its completed worksheet to a vendor demonstration. Compare the restaurant kiosk workflow against your operating requirements with Fleksa, including selection limits, review totals, kitchen instructions, and your staffed fallback.
Frequently asked questions
Which modifiers should I test first?
Start with required choices, paid additions, removals, and choices that reveal another decision. These can stop an order, change its price, or alter what the kitchen prepares.
How do I check whether a modifier price is clear?
Look for the charge at the point of selection, then calculate the customized item total and compare it with the review screen. Remove the modifier and check the revised total too.
Does a correct kiosk screen mean the kitchen will get the right order?
No. Compare each selection with the mock kitchen ticket or display, including removals and edits. Have kitchen staff read it without seeing the guest screen.
