Interactive kiosk in a public space: software to installation

What is an interactive kiosk in a public space#

An interactive kiosk in a public space is a touchscreen placed at a specific location, giving visitors self-service access to information or services without staff involvement. It combines two layers: software, which defines the content and how it is managed, and hardware, meaning the screen, housing and connectivity on site. The solution makes sense wherever a client wants to offer information or a service in one fixed place, without a staff member permanently present at the device.

A concrete example is our project for the Municipality of Sevnica, called Zdravo Jem. We developed a software solution and interactive content for the public space, displayed on a 55-inch touchscreen. The work covered configuring the kiosk environment, integrating software and hardware, on-site installation, and preparing documentation and support after launch. The project shows that a kiosk always comes down to linking digital content with a physical device at a specific place.

An interactive kiosk differs from a website or app in that it runs in a locked kiosk mode on a single device, in a single place. The user cannot leave the app, open other programs, or reach the device's settings. The screen is often installed in a publicly accessible area, which adds requirements around durability, security and physical protection of the equipment that an ordinary web solution never has to deal with.

What needs to be defined before starting#

Before development begins, we need to define the kiosk's purpose, its target users and the installation location. These decisions shape what content the kiosk shows, how demanding the user experience needs to be, and what requirements the physical space places on the device. A public-sector purpose, such as informing residents or education, differs in content and flow from a kiosk built for an event or a business space. A clear definition at the start reduces the number of changes during development and installation.

It is equally important to define who prepares and updates the kiosk's content after launch, whether this is a single installation or a network of several locations, and what data the system needs to collect or display in real time. These decisions affect the architecture of the software solution and whether remote administration is needed. In the public sector, it is also common to account for documentation, educational content and an agreed level of support after the solution launches.

Answers to these questions come together in a short requirements summary that becomes the basis for developing the software and choosing the hardware. We took the same step on the project for the Municipality of Sevnica, aligning the kiosk's purpose, content and installation location before development started. This avoids later changes in scope that would otherwise lengthen the path from concept to a working solution on site.

• the kiosk's purpose and target user group
• installation location and the physical conditions of the space
• scope of content: informational, educational or interactive
• how content is edited after launch and who is responsible
• the need to connect with existing systems via APIs
• the required level of support and maintenance after installation

Software and the kiosk environment#

At the core of the solution is software running in a configured kiosk environment. This means the device is restricted to a single purpose: the user only sees and uses the content prepared for them, with no access to any other function of the screen. Configuring the kiosk environment includes setting the app to launch on power-up, disabling any way to exit it, and connecting it to the appropriate hardware. On the Sevnica project, we carried out this configuration together with integrating the software and hardware on the 55-inch touchscreen.

Content shown on a public-space kiosk is typically interactive: the user operates it by touch, moves between sections, and receives information tailored to their choices. For the Zdravo Jem project we prepared interactive content for the public space, aimed at municipal visitors. The content layer needs to be designed separately from the device's technical configuration, since content changes more often than hardware. This lets the client update content without touching the kiosk's base setup.

For the public sector we also frequently build information systems and portals that a kiosk can display or connect to, as well as interactive solutions aimed at educating and informing visitors. A kiosk can stand on its own or act as an entry point into a broader information system belonging to the public client. Either way, system documentation and content-editing instructions remain part of the handover, giving the client full insight into how the solution works once the project ends.

Hardware and on-site installation#

Choosing the hardware depends on the kiosk's location and purpose. On the Sevnica project this was a 55-inch touchscreen, suited to a public space with several visitors at once. Screen size, mounting method and the housing's durability are decided based on whether the device sits indoors or outdoors, how close it is to visitors, and how often it gets used. We make these decisions together with the client before installation, since they are difficult to change once the device is mounted.

On-site installation covers physically mounting the screen, connecting power and connectivity, and launching the software on the device. On the Zdravo Jem project, on-site installation was carried out together with integrating the software and hardware, so the kiosk was ready to use as soon as the work was finished. The physical space needs to be reviewed in advance: access to power, lighting, room for wall or stand mounting, and protection against damage or vandalism.

After installation comes the handover of documentation describing how the device works, how to edit content, and what to do if something breaks. In the public sector, documentation is often a condition for accepting a project, since it lets the client maintain the system even without direct involvement from the contractor. On the Zdravo Jem project we provided post-installation support as part of the agreed scope of work, together with documentation for ongoing use.

Testing and acceptance#

Before a kiosk goes into a public space, we verify the solution through testing that simulates real use on the device. We check how touch behaves, how responsive the content is, what happens when connectivity drops, and how the device restarts after a power interruption. The point of testing is to find problems before a visitor does, at a location where a fix isn't as simple as on a website. Testing is carried out in a separate test environment, without real personal data, which applies to all our projects.

We adapt the QA process to the nature of a kiosk: it is a device at a fixed location, where a fault can't be fixed as quickly as on a web app, so pre-installation checks are thorough. We combine manual review of the user interface with automated tests, depending on which parts of the solution are most critical to smooth operation on site. Testing runs in stages, so every content or software change goes through the same verification process before it reaches the kiosk's production environment.

Acceptance testing follows criteria agreed with the client before development even starts, so it is clear in advance when the kiosk is ready for public use. In the public sector, successful acceptance testing is often a condition for formally accepting the project and signing off the handover. Only after acceptance testing succeeds do we install the solution at its final location and hand it over for regular use, together with documentation describing how it works.

• manual testing of the user interface and touch on the device
• automated testing (Playwright, Cypress)
• API and regression testing on every content change
• testing in CI/CD before an update is released
• acceptance testing against criteria agreed in advance
• an independent QA function, separate from the development team, where needed

Maintenance and SLA after installation#

Once a kiosk is installed in a public space, maintenance doesn't end at launch. The device needs to be monitored, faults need fixing, technical and security updates need applying, and content sometimes needs upgrading. We can take on this work under a support agreement, so the client doesn't have to manage the device's technical condition on site themselves. The scope of support is set according to how critical the device is to the public service and how often its content changes.

We classify post-installation support into four severity levels, telling the client how quickly and with what priority we handle each case. This classification lets us deal first with whatever actually stops the kiosk working on site, while minor issues wait for the next scheduled release. We use the same system across every support engagement, whether it's a kiosk, an information system or another piece of software, because it gives a clear, verifiable, agreed way of handling issues.

Response times for each level aren't universal, and we don't publish them in advance in hours or days, since they depend on how critical the device is to the client and on what's agreed in the support contract. For a kiosk that is the only source of information at a given location, it makes sense to agree faster handling of outages than for a device that merely supplements other communication channels. That agreement is always part of the support contract and is worked out separately for each project.

• level 1 – outage: the system or a key part isn't working, handled with the highest priority
• level 2 – disruption: the system works, but a specific function doesn't work correctly
• level 3 – defect: a minor fault with no impact on operations, scheduled into the next release
• level 4 – request: a change or upgrade, with scope and timing agreed separately

How collaboration with Epix works#

We can take on an interactive kiosk project in full, from software design through to on-site installation, or as a single segment, such as content development alone or hardware integration alone. On larger projects, such as the Sevnica installation, we appoint a project lead, define each team's responsibilities, set deadlines, and agree how communication with the client will run. This approach lets the client know at every point which phase the project is in and who is responsible for each part of the work.

We build our way of working on a handful of fixed principles that apply to every project regardless of scope, including a single kiosk at a single location. These principles guarantee that the client keeps ownership of their code and data, that development runs in separate environments, and that test data is never mixed with real data. The same rules apply whether it's a brand-new project or taking over an existing, partly built solution.

If a client already has a partly built solution or an existing device they want upgraded, we can take it over after reviewing the source code, architecture, infrastructure and data. This is common in the public sector, where a kiosk or information system tends to grow new requirements over time. Either way, the source code and data remain the client's property, and documentation, access and passwords are part of the handover at the end of the project.

• we take on a project in full or as a single project segment
• on larger projects we appoint a project lead and define team responsibilities, deadlines and communication
• we can take over an existing or unfinished system after reviewing its code, architecture and data
• source code and data belong to the client; documentation and access are part of the handover
• development, test and production environments are separate; the test environment never uses real personal data

What this means for scope and price#

We don't publish prices for individual kiosk projects, since the price depends on the scope each case actually requires. A single-location kiosk with simple content is a different project from a kiosk connected to a public client's existing information system and built into a wider network of devices. Instead of a general price, we first break down which parts of the work make up the specific project.

Several factors affect scope, and therefore how demanding execution is, and we check them before estimating a specific kiosk project. Some are visible from the start, such as screen size or installation location; others only emerge during analysis of the client's existing systems. That's why, before any estimate, we suggest a short requirements review that splits the scope into clearly defined segments, so each one can be assessed on its own.

Price is set after reviewing the requirements, scope and technical complexity of the project. Before that, we suggest a short analysis that breaks the scope into segments, so each one can be estimated and delivered separately. This applies just as much to a small, single-location kiosk, like the Sevnica project, as to a larger installation across several locations. The approach stays the same regardless of project size, since only a broken-down scope allows for a realistic, verifiable estimate.

• scope of functionality and content the kiosk displays
• whether it's a new kiosk or taking over and upgrading an existing device
• how many existing systems need to be connected via APIs
• security and compliance requirements, especially in the public sector
• hardware, installation and physical-space requirements
• the level of post-installation support and agreed response times

The team behind the project#

Epix has operated since 2020, headquartered in Novo mesto, and delivers projects in Slovenia, Serbia and the US. Together with our partner network, we have delivered more than 950 projects to date, involving more than 190 team members. Interactive kiosks for public spaces are one segment where software development and on-site technical installation meet, requiring several different disciplines to work together on the same project.

For a kiosk project, we put together a team from Epix and its specialist partner network, depending on which experts the specific project needs. A smaller, single-location installation is fine with a leaner development and installation team, while a larger project tied to several existing systems brings in additional roles for integration and support. We adjust the team's composition each time to fit the actual scope of work, not the other way round.

For the public sector, Epix and its partner network bring experience with information systems, portals, interactive solutions, documentation, educational content and agreed levels of support. The Sevnica project grew out of exactly this framework: from the software solution and content through to installing the touchscreen and providing support after launch. We apply the same approach to every subsequent public-space kiosk, adapted to the specific location and client.

• project leads and business analysts to define requirements
• full-stack and backend/frontend developers for the software
• UX/UI designers for content and the touch user experience
• DevOps and cloud engineers to connect with existing systems
• QA and test automation engineers for testing before acceptance