A guest should be able to tell what remains before checkout, not just what screen they are on. To find out whether a kiosk makes that clear, give participants an order with several required choices. Pause at specific points and ask what they expect to do before they can pay. Then compare their answers with the actual path.
A progress bar alone is not proof that the path is clear. It may count screens, items, or stages without explaining which. It may also appear nearly complete before a required choice or review screen. The useful buying question is whether the cue matches the work a guest still has to do.
Build an order with several mandatory choices
Choose an order that resembles a busy service transaction, but keep the task focused. For this hypothetical example, a guest orders one chicken meal. The meal requires a size, a side, a sauce, and a drink. The guest then reviews the order and reaches checkout. An optional dessert offer can appear after the required choices.
That gives the owner a known path: four required selections, a possible optional offer, order review, and checkout. Treat checkout as the point where the guest can begin payment, not the point where a payment has been made. If the actual configuration combines two choices on one screen or adds another required screen, update the path before the session.
Ask the vendor to configure the demonstration with the same choice rules you expect to use. A short sample menu with no required modifiers will not answer this question. Neither will a scripted tour in which the vendor taps through every screen before participants can form their own expectations.
Write a task in ordinary guest language: “Order a chicken meal with a large size, fries, barbecue sauce, and water. Stop when you reach the place where you would pay.” Give participants the food choices, but do not tell them how many screens are ahead. The goal is to see what the interface communicates.
Run this as a simulation using a test setup that cannot charge a card, send a guest message, or dispatch a courier. Confirm that an order will not reach the live kitchen queue or sales records. Do not use a real payment card. If the vendor cannot provide a safe simulation, agree on another non-transactional demonstration before proceeding.
Ask guests where they expect to finish
Invite people who are not familiar with the kiosk to try the task individually. Include people with different levels of comfort using touchscreens. Give everyone the same starting instruction, and avoid coaching them through the choices.
Pause at planned moments rather than after every tap. In the example, useful checkpoints are after the size selection, after the sauce selection, and on the final required choice. At each pause, ask:
- “What do you think you still need to do before you can pay?”
- “Does anything on this screen tell you how far along you are?”
- “Do you expect another required choice after this one?”
Record the participant’s answer before explaining anything. Note the cue they point to, such as a step label, a numbered sequence, a progress bar, or the button text. Also note when they say they cannot tell. A confident but wrong answer matters: a guest who expects payment next may be more frustrated by an unexpected required choice than someone who knows another choice is coming.
Watch for the difference between completing an item and completing an order. “Done” could mean the meal is configured, while the guest still needs to review the order. A cue that says “Step 4 of 4” may be accurate for meal choices but misleading if it appears to describe the entire checkout journey. Ask what the participant thinks the count covers.
Do not treat every pause as a failure. Some guests may stop to read a choice or decide what they want. Record confusion about remaining work separately from time spent choosing food. This keeps the test about progress cues rather than menu search, screen density, or the ability to go back.
Compare the cue with the remaining path
Before participants start, walk the configured order through in the safe test environment and record each required action. Include review and the point at which payment can begin. Mark optional offers separately. Then use the worksheet below to compare the visible cue with what actually remains.
The entries illustrate how an owner could record findings for the hypothetical meal. They are examples of possible observations, not results from a real test. The acceptance criteria in the last column are the standards the owner sets before watching participants.
| Checkpoint | Actual path remaining | Example observation | Owner’s acceptance criterion |
|---|---|---|---|
| After size | Side, sauce, drink, review, then checkout; dessert offer may appear | Guest expects only one more choice because the bar looks nearly full | Guest identifies that several required choices remain, or the cue clearly lists them |
| After sauce | Drink, review, then checkout; dessert offer may appear | Guest expects to pay next and misses the drink requirement | Guest expects the drink choice before checkout |
| After drink | Review, then checkout; dessert offer may appear | Guest expects a review and recognizes dessert as optional | Guest can distinguish optional dessert from the required path to checkout |
Use the same checkpoints and criteria across demonstrations. A vendor might show progress as a list of choices, a percentage, or a label such as “Review next.” Judge each against the remaining path rather than against a preferred design. A percentage can be useful, but ask what it counts and whether it changes when an optional offer appears.
Check what happens when the order changes too. If a guest adds a second configured item, does the cue describe the current item or the whole order? If a required selection is unavailable, can the guest still understand what remains? Ask the vendor to demonstrate those paths if they matter to your menu. Do not assume that a progress indicator shown for one item behaves the same way for a larger order.
For a closer buying comparison, ask each vendor for the configured screen sequence, the meaning of each progress cue, and a demonstration of how optional offers and review are presented. Also ask which labels or prompts you can change yourself and which require vendor assistance. Save screenshots or notes from the demonstration so you can compare the same checkpoints later.
Set a revision threshold before the session
Decide in advance what would cause you to ask for a change. For the hypothetical meal, an owner could invite six participants and set this rule: at each checkpoint, at least five of the six must correctly identify the next required choice or, at the final choice, expect review before checkout. If fewer than five meet the relevant criterion at any checkpoint, revise the cue or ask the vendor for an alternative before making the buying decision.
That is a practical internal threshold, not a guarantee that every guest will understand the kiosk. Six participants can expose an obvious mismatch, but the group is too small to establish a reliable rate for the whole customer base. Record both the count and what people said; two guests can give the same wrong answer for different reasons.
Suppose four of six expect payment immediately after sauce, even though the drink is still required. Under the stated rule, that checkpoint fails: four is fewer than five. Ask whether the vendor can make the remaining drink choice clearer, then repeat the same task with different participants if possible. Do not change the threshold afterward simply because the demonstration looked polished.
Also set a rule for optional offers. If a participant mistakes dessert for a required step, record it separately and ask how the screen signals that it can be skipped. A cue should not promise that payment is next if the configured flow routinely inserts another screen without making its optional status clear.
After a simulation, you may choose a supervised live service pilot to observe the workflow under ordinary conditions. That is a separate decision: live orders and payments are real, and staff need an agreed fallback if guests need help. Do not turn the practice task into a live transaction without explicitly planning for it.
Progress cues are one part of the purchase. Compare the installed quote, payment compatibility, accessibility, kitchen capacity, and the help staff can provide when a guest gets stuck. The kiosk break-even guide can help frame the wider cost decision. Ask how the kiosk will connect to your restaurant POS system and fit the rest of your restaurant management software; confirm the actual configuration rather than assuming every combination works.
Next step: Take your worksheet and a representative order to a Fleksa restaurant kiosk demonstration. Fleksa’s kiosk page describes item customization and order review; ask to see your required choices, progress cues, and checkout path configured before buying.
Frequently asked questions
Does a kiosk need a progress bar?
Not necessarily. A clear sequence of labels or another cue may work. The test is whether guests can understand the required work remaining before checkout.
Should optional add-ons count as remaining steps?
Record them separately from required choices. Guests should be able to tell whether an offer can be skipped and what comes next if they skip it.
Is one successful demonstration enough?
It can help you assess the configured path, but it cannot represent every guest or order. Check the variations that matter to your menu and set a clear threshold for requesting changes.
