How to Design Custom Software for Touchscreen Kiosks
If you are building a kiosk or commissioning one, the hardware is almost never the problem. The screen works, the enclosure looks good, and the printer fires. What kills kiosk deployments is the software, and usually it comes down to decisions that seemed fine on a laptop screen and fell apart the moment a real person stood in front of the machine.
This guide is for designers building kiosk interfaces and for business owners who want to understand what actually goes into one. We are going to get specific, because vague advice does not help you when you are staring at a 32 inch touchscreen trying to figure out why users keep tapping the wrong button.
Why Kiosk Software Is Important?
People think that kiosk software is like a web-app or a mobile app shown on a larger screen. It’s not, and it’s that assumption that leads to so many poor deployments.
The kiosk is unattended. No one’s there when something breaks. The user in front of it may be 70 years old, may be wearing gloves, may be in a hurry, or may not be able to read the primary language that is displayed on screen. It has to meet the needs of all of them, all the time, without intervention.
It affects nearly all your design and engineering decisions.
Touchscreen Specs Requirements
It’s here that designers from a web or mobile background underestimate the differences. The rules are comparable, but tolerances are smaller, and the effects of failure to comply with the rules are more obvious.
How Big Buttons Need to Be
The standard you will hear most often is 44x44px, which comes from Apple’s Human Interface Guidelines and is widely used in mobile. For a kiosk, that is your absolute minimum, and in most cases, it is not enough.
Think about where a kiosk screen usually sits. It is mounted at chest height or slightly below. The user is standing a bit back from it, reaching forward. They might be wearing work gloves. They might have a condition that affects their fine motor control. In those conditions, a 44px button is hard to hit reliably.
For primary actions, the safe target size is 60x60px. For anything the user needs to hit quickly or under pressure (confirm payment, select quantity, print receipt), go to 72px or larger. You will not regret going bigger. You will absolutely regret going smaller once you see real users in the field.
Space Between Buttons
Put at least 16px of space between any two tappable elements. On a mobile phone, a user is holding steady in their hand, 8px is workable. On a kiosk screen they are reaching toward, 8px means a lot of accidental taps on the wrong thing. 16px is the practical minimum. More is better.
How Fast the Screen Needs to Respond
Users expect to see something happen within 100 milliseconds of tapping. That is fast enough that they perceive it as instant. Go beyond that, and they think the screen did not register the tap, so they tap again. Now you have double taps, double submissions, and navigation jumps. On older embedded hardware running stripped down Android or Windows builds, hitting that 100ms threshold requires actual optimization work: preloading assets, keeping animations GPU accelerated, and avoiding anything that blocks the main render thread.
On Gestures
For most kiosk flows, do not use swipe as a primary navigation method. Swipe is invisible to first time users, unreliable with gloved hands, and inaccessible to people with limited arm mobility. Scrolling within a content area is fine, but always pair it with a physical scroll button or arrow, because some users will not figure out the swipe on their own.
Button Labels
This sounds small, but it matters a lot. “Continue,” “Pay Now,” “Print Receipt” tell the user exactly what will happen. “OK,” “Next,” “Submit” force them to hold context from whatever was written above the button. On a kiosk, assume nobody reads the instructions. The button has to stand alone.
ADA Compliance: What It Actually Requires in Software
ADA compliance for kiosks is a legal requirement, not a design preference. The specific standards come from the Access Board guidelines for interactive transaction machines and Section 508. Here is what they mean in practice for the software side.
Where Controls Have to Be on Screen
The Access Board requires operable parts to fall within 15 to 48 inches from the floor for wheelchair access. On a tall portrait display, anything above the midpoint is often out of reach. Build the UI grid around this from the start.
Contrast Ratios
WCAG 2.1 AA requires 4.5:1 contrast for regular text, 3:1 for large text (18pt or 14pt bold). Bright retail lighting or sunlight washes this out fast. Design to AAA (7:1) where possible, and test on the actual hardware in real lighting, not just your design monitor.
The Audio Jack Requirement
Any kiosk handling financial transactions in public needs a 3.5mm headphone jack at an accessible height, for visually impaired users to get audio guidance. The software needs a full audio mode that reads the screen aloud and accepts headphone button input. Not optional.
Text Size
Minimum body text is 18pt. The Access Board’s 3/16 inch character height guideline works out to roughly 18 to 22pt at the typical kiosk viewing distance. No all caps for body text, it’s slower to read and harder for dyslexic users. Sentence case for instructions, title case for buttons.
Session Timeouts
Warn users at least 20 seconds before an idle timeout, with a way to extend without losing progress. The warning needs to show on screen and play in audio mode. The extend button follows the same tap target and contrast rules as everything else.
Reading Level
Write all copy at a Grade 6 to 8 reading level. Short sentences, active voice, one instruction per line. Applies to error messages, button labels, confirmations, everything. Someone distracted, rushed, or not a native speaker needs to get it in under two seconds.
Hardware Integration: What the Software Has to Handle
A kiosk talks to a stack of physical devices, and each one fails differently. If the software doesn’t account for that, the UI crashes or leaves the user stranded.
Card Readers and Payment
Most setups use a built in EMV reader or a standalone terminal (Ingenico, Verifone) over USB or serial. The software sends a request and waits; it never touches card data directly.
The UI handles chip insert, tap, swipe, and manual entry, each with its own timing and failure path. EMV transactions take 3 to 8 seconds, so the waiting state needs to be obvious. A spinner that looks like a freeze makes people tap again or pull their card early, which cancels the transaction.
Receipt Printers
Most run ESC/POS over USB or serial (Epson TM series, Star Micronics). Poll for status before every print job, since out of paper, cover open, and jam all need different on screen messages. Never assume the printer is ready.
Always build a no print fallback: email, SMS, or a scannable QR code. No proof of transaction is a support problem and sometimes a legal one.
Barcode and QR Scanners
USB HID, read by the OS as a keyboard. A hidden input field catches the scanned code for the software to validate. Keep scan to UI response under 500ms. For outdoor or bright installs, use a scanner rated for 100,000+ lux; standard ones struggle in direct sun.
Cameras and ID Verification
Usually, a USB UVC camera plus a vendor SDK (Acuant, Jumio). Handle failed detection or bad lighting without blocking the whole transaction. Always include a staff override for manual approval.
Vending and Label Printers
Thermal printers with OPOS or JavaPOS drivers need registry setup before the app can address them. Script this at deployment; manual setup across a fleet causes configuration drift.
OS Lockdown
Lockdown shapes the whole build, not something added at the end.
Windows: Assigned Access restricts access to the device to a single app; it only functions smoothly with UWP or Edge based kiosk browsers. Shell Launcher replaces the shell completely in most real kiosk apps (Win32), with explorer.exe no longer running. You can specify what happens in the case of a crash: restart, reboot, or execute a recovery script. Considers the cost of required Windows IoT Enterprise (or Enterprise LTSC) licensing; plan accordingly in advance.
Android: Provisioned by Device Policy Controller as Device Owner mode. The DPC sets your app as home, disables back, removes the status bar, and locks the current app in single app mode. Scale up management with an MDM platform (Workspace ONE, SOTI MobiControl, Intune). Manual provisioning is for a 5 unit pilot and not for 50 or 500.
Watchdog Processes
Every kiosk needs a watchdog: a background process that restarts the app if it crashes or hangs. Shell Launcher does this on Windows, the DPC does it on Android. Add a hardware watchdog too, a board level timer that reboots the whole machine if the software watchdog stops checking in. That’s what stops a kiosk from sitting on a black screen all night.
What Else to Lock Down
Disable USB storage automount, turn off automatic Windows Update reboots (schedule them instead), suppress notifications, disable autocorrect on any visible keyboard, and block screenshot APIs on anything handling payment or personal data. Small details, but each one can cause a real field incident.
Pushing Updates Remotely
Needs three things: a management agent on every unit, a delivery system (Intune, SOTI, or custom), and a staged rollout. Never push to the full fleet at once; roll to 5 to 10 percent first, watch for 24 hours, then continue. A bad update on 300 kiosks overnight is an emergency. The same bad update caught on 15 units is a quick fix.
Conclusion
Kiosk software is one of those things where the details are the product. The tap target is being 60px instead of 44px, the printer is being polled before every job, and the lockdown survives a crash and a reboot. None of that is visible to a happy user, but all of it becomes very visible when it is missing.
KioskSys handles kiosk software design and development from hardware spec through deployment and remote management. If you are planning a build or trying to understand what one should actually involve, talk to our team.
Frequently Asked Questions
How long does it take to build and deploy kiosk software?
A single kiosk application usually takes 8 to 16 weeks from design to deployment, though fleet-wide rollouts with MDM setup and OS lockdown configuration can add several more weeks.
How much does kiosk software development typically cost?
Costs vary widely based on hardware integrations, payment processing, and compliance requirements, but most custom kiosk builds range from $30,000 to $150,000+, depending on complexity and the number of unique screens or device integrations involved.
Who is responsible for ADA compliance, the software vendor or the business deploying the kiosk?
Legally, the business deploying the kiosk carries the liability, but a competent kiosk software development company should build ADA and Section 508 compliance into the software by default rather than leaving it to the client to catch.
