A Physical Button Map for a Kiosk Website

A kiosk with three or four physical buttons and no keyboard turns every website screen into a puzzle. If a visitor lands somewhere the buttons cannot leave, the only fix is a staff member. This workflow is a proposal for deciding what each button does, so that every screen has a way out.

Start with the screens, not the buttons

List every distinct screen a visitor could reach. Mark the ones that need a choice (a list, a form, a gallery) and the ones that only display (a confirmation, a map). Buttons are scarce, so a screen that needs three different actions will probably cost you one button too many. Consider simplifying that screen before you consider adding hardware.

The button-to-action map

Build a table with one row per screen and one column per button. Fill each cell with a verb, or write NONE. Then add two columns: Exit and Timeout. A possible layout for a four button kiosk:

Buttons: A (Next), B (Previous), C (Select), D (Home).

Rules you may want to adopt as defaults, adjusting for your hardware:

One button is always Home or Back to start, and it behaves identically on every screen.
Select never changes the meaning of a button elsewhere. If C selects here, C does not also mean Cancel on the next screen.
A button with no action on a screen is marked inactive on screen as well, so the visitor is not left guessing.
Long press is avoided unless the screen states it, since visitors rarely discover hidden gestures.

Branching choices

If the screen is a list, A and B move focus, C opens, D exits. If the screen is a form, consider whether the form belongs on a kiosk at all; if it must stay, give each field a single on screen option set so A and B cycle values and C confirms. If the screen has more than about five focus targets, group them or split the screen. If you have only two buttons, choose Next and Select, and make Home a timed return after inactivity, stated plainly on screen.

Worked example (hypothetical)

Imagine a showroom kiosk with four buttons showing a finish gallery. Screen 1, Gallery: A next finish, B previous, C open detail, D restart. Screen 2, Detail: A and B inactive, C back to gallery, D restart. Screen 3, Request a callback card: A and B cycle a short preset list, C confirm, D restart with a warning that the entry will be lost. Writing the table reveals a problem: on Screen 3, D discards data silently. The fix could be to make D ask for confirmation using C and D as yes and no.

The exit rehearsal

Walk through each screen with only the buttons, a pen, and the table. For every screen answer: which presses lead out within five presses? Record the count. Then rehearse failure cases: a stuck button, a visitor who walks away mid form, a screen where all buttons are inactive because content failed to load.

Stop conditions

Stop and redesign if any screen needs more than five presses to reach Home, if any screen has no active button, if the same button means different things in different places without an on screen label, or if a rehearsal participant needs to ask what a button does.

Acceptance checks

The map has no blank cells; every screen has a labelled exit; an inactivity return is defined for every screen including error states; someone unfamiliar with the kiosk can leave any screen on their first attempt; and a staff reset path exists that does not depend on the website responding. Treat these as a checklist for your own testing, not a guarantee that visitors will never need help.