Touch Kiosk Software Requirements: Structure and Acceptance

A good technical task for touch-sensitive kiosk software does not describe a set of screens, but a full cycle of work: who approaches the device, what task it performs, what happens without the Internet, how the application recovers after a failure and according to what tests the customer accepts the result.

Short answer: the ToR requires seven mandatory parts: user scenarios, hardware and OS, touch interface, data and integrations, offline mode, kiosk mode with recovery, measurable acceptance criteria. Layouts without these conditions are not enough for a reliable public terminal.

Why the usual TK to the site is not enough

The site works in the user's browser, and the kiosk works on a specific device in the physical environment. It has a preset screen size, enclosure, installation method, peripherals, and limited service access. The visitor can tap the screen several times, interrupt the script, or leave the form unfinished.

Therefore, the project has requirements that a corporate website usually does not have:

• automatic launch of the application after switching on;
• prohibition of access to the operating system;
• restoration after loss of network and power supply;
• local storage of critical materials;
• data cleansing between user sessions;
• management of the connected periphery;
• remote updating and diagnostics;
• testing on an accurate equipment model.

If these conditions are clarified after the interface is developed, you have to change the architecture, not just the layout.

1. Project Data Sheet and System Boundaries

Start the ToR with a short table. It protects the project from different interpretations of the words "panel", "application" and "admin panel".

Parameter	What to fix
Purpose	Navigation, catalog, registration, queue, presentation, payment or other scenario
Place of employment	Exhibition, street, office, sales area, airport, medical organization
Users	Visitor, operator, content administrator, technician
Equipment	Model, diagonal, resolution, orientation, sensor type, computer
OS	Windows, Android, Linux, version and update policy
Net	Permanent, unstable, closed circuit or complete lack of Internet
Peripherals	Printer, camera, scanner, NFC, payment terminal, sensors
Governance	On-premises admin, cloud dashboard, API, or file upload

Specify what is not included in the first version. For example: online payment, document recognition or centralized management of a fleet of devices can be separate stages. This helps not to turn the pilot into an endless list of possibilities.

Custom Scripts

For each user type, describe the goal, entry point, and completion. Instead of "the user looks at the catalog", you need a sequence:

1. The kiosk shows the start screen.
2. The visitor selects a category.
3. Opens the object card.
4. Watching a gallery or video.
5. Leaves a contact or returns to the list.
6. After completion or inactivity, the application clears the session and returns to the start.

Next, describe the exceptions: the network disappeared, the video did not load, the user closed the form, the server returned an error, the device restarted. For each exception, you need the expected result, not just the error text.

Scenario table for ToR

Field	Example wording
trigger	User clicked “Find Object”
Precondition	Loaded local object directory
Main path	Filter → list → card → route
Error	Serveur indisponible
Behaviors	Show local data and mark the time of the last synchronization
Conclusion	Return to start after a specified period of inactivity

Such a table can be checked by a test. The phrase "the interface should be convenient" does not create an acceptance criterion.

3. Requirements for the touch interface

The touch interface is designed for the finger, not for the cursor. It can't rely on hover, small icons, or hitting a text link exactly.

In WCAG 2.2, the minimum target for the web interface is described as an area of 24 by 24 CSS pixels or a sufficient distance from neighboring targets. The reinforced criterion uses 44 by 44 CSS pixels. These numbers are useful as a starting point, but do not replace verification on a physical device: a kiosk can stand at an angle, use a large screen, or serve people with different capabilities.

In the Tor, record:

• minimum size and distance between the active elements;
• allowed gestures: single touch, scroll, zoom, drag;
• lack of functions available only on hover;
• the position of the main navigation and the return button;
• on-screen keyboard, masks and field validation;
• inactivity timeout and session clearing;
• availability of basic actions at the selected installation height;
• behavior with multiple simultaneous touches.

Acceptance is carried out on the target diagonal. Even the correct layout can be inconvenient if the button is outside the comfort zone of the hand.

4. Kiosk mode and recovery

Kiosk mode should limit the public user to the application and provide predictable device startup.

Microsoft separates Windows configurations into a single-app kiosk and a limited multi-app script. In single-app mode, the assigned application runs fullscreen, and the user does not receive the usual desktop. Different mechanisms are used for desktop applications and UWP/Edge, so the mode is selected after determining the type of application and Windows edition.

On Android, Lock Task Mode is used for dedicated devices. It requires a managed device configuration and a list of allowed applications; a simple full-screen mode does not give the same level of restriction.

In the ToR, answer the following questions:

• who and how enters the service mode;
• does the app start automatically?
• what happens after the emergency termination;
• is it possible to open system settings;
• how updates are installed
• where logs are stored;
• who receives a notice of unavailability;
• how to return the previous version.

Do not link the solution to the word "kiosk" without checking the OS and the type of application. The setting available on one version of the system may not be available on the other.

5. Offline mode and synchronization

The requirement "should work without the Internet" should be decomposed into functions. Not all transactions need to be available offline.

Function	Possible mode without network	What to define in the ToR
Directory & Media	local copy	Scope, format and rules of update
Search	Local Index	What fields are available, how often it is updated
Application form	Submission queue	Encrypt, resend, delete
Card	Preloaded data	Scale, routes, relevance
Payment	Usually requires a separate scenario	Behavior when the provider is unavailable
Analytics	Local event buffer	Limit, deduplication, synchronization time

Be sure to describe the data conflict. If the content is updated on the server, and the kiosk sends a pending request, the system should understand what can be combined and what requires manual verification.

B airport interactive map case you can see an example of a project where a full-screen touch interface, a map, multimedia content and data management are important. For the road project we used local and cloud application logic for the touch panel.

6. Integrations and data

For each integration, list the system, protocol, exchange direction, and responsible owner. The wording "integration with CRM" does not explain what data is transmitted and at what point.

The minimum integration description includes:

• source and recipient;
• Authorization method
• the composition of the fields and the mandatory nature;
• frequency or exchange event;
• timeout and retries;
• an identifier for protection against duplicates;
• error log
• test loop and API owner contacts.

If the terminal collects personal data, separately define the consent, local storage period, transfer, post-session cleaning and access of technical personnel. Do not leave these decisions only at the level of policy text: they affect the architecture of the application.

7. Administration and Updates

The content of the public kiosk changes after launch. In the ToR, specify in advance who can:

• change texts, images, and videos
• publish changes to one or more devices.
• see the sync status;
• roll back an erroneous publication;
• manage the display schedule;
• receive logs and technical notifications.

Local import of the prepared package may be enough for one device. A network of kiosks typically requires centralized management, content versions, and the status of each terminal.

Acceptance criteria

Turn every important requirement into an observable test. Example of an acceptance unit:

1. After power is supplied, the application opens without operator action.
2. The user cannot exit to the desktop using standard gestures or keys.
3. If the network is unavailable, the catalog and search continue to work with local data.
4. The request is stored in a local queue and sent once after the connection is restored.
5. After a period of inactivity, the application clears entered data and returns to the start screen.
6. After an unexpected shutdown, the application recovers automatically.
7. The administrator can see the content version and the time of the last synchronization.

Add a matrix of devices, permissions, and peripherals. An application tested only in the developer's browser cannot be considered accepted for use in a specific panel.

What to give to the developer before the evaluation

For the initial assessment, it is enough to collect:

1. Description of the task and place of operation.
2. Photo or exact model of the equipment.
3. One main and several secondary scenarios.
4. Draft list of screens.
5. Requirements for offline and kiosk mode.
6. List of integrations and contacts of API owners.
7. Content formats and sample data volume.
8. Pilot term and success criteria.

After that, the team will be able to assess the architecture, prototype and risks. If the equipment has not yet been selected, it is better to develop and select the device together. Separately available for temporary event rent of interactive panels.

FAQ

Do I need a prototype before developing kiosk software

Yes. A clickable prototype allows you to check the sequence of screens and the location of actions before programming. But the final touch-UX is still checked on the device of the right size.

What to choose for the kiosk: web application or desktop application

The web application is convenient for updates and integrations, the desktop application gives more control over the device and local resources. The choice depends on the OS, offline requirements, peripherals and the method of centralized management, and not on the fashion for the stack.

Is it possible to make a kiosk on a regular website

It is possible for a simple catalog if the site is adapted to touch, full-screen mode and an unstable network. For peripherals, local storage, reliable recovery, and a closed loop, a separate software shell or application is usually required.

Whether it is necessary to describe a specific panel model in the ToR

Yes, if it is already selected. Resolution, orientation, OS, ports, touch transmission method, and peripherals affect implementation and acceptance. If the model is unknown, specify a range of characteristics and a mandatory check after selection.

How to check offline mode

Don't imitate it just by setting it up in your browser. Disconnect the real network on the device, go through all the allowed scenarios, create pending data, restart the terminal and then check the correct synchronization without duplicates.

What has the strongest impact on the cost of development

Number of scenarios, integrations, offline logic, peripherals, centralized management and fault tolerance requirements. One showcase without integrations and a network of terminals with remote monitoring are projects of different architectures.

Useful on the topic

• Software development for touch panels and kiosks
• How to Choose an Interactive Panel for an Exhibition
• Case Study - Interactive Airport Map
• Case Study: Road Project Touch panel App

Sources

• Microsoft Learn: Windows kiosk customization options
• Android Developers: Lock Task Mode
• W3C WCAG 2.2: minimum touch target size
• W3C WCAG 2.2: extended touch target size