Start with the visitor's first question
A wayfinding kiosk should help someone reach a destination, not require them to learn the building's internal terminology. Collect the questions people ask reception staff and compare them with the official room or tenant list. Visitors may search for a service rather than a department name. Define a small set of entry choices and a clear way to return to the beginning. Use the venue's actual destinations in the prototype. A visually polished map with incomplete naming can still leave users unable to find the place they need.
Make map orientation explicit
Mark the kiosk's position and ensure the displayed map corresponds to the direction a visitor faces. Test instructions by walking the suggested route from the installed location. Include changes of floor and the correct lift or stair destination where appropriate. Do not assume a route that is shortest on a drawing is suitable for every user. The venue team should verify accessible routes and local requirements. Decide who owns map revisions when a tenant moves, a corridor closes or a room name changes after launch.
Build a short and forgiving interaction
Use clearly labelled controls and maintain a consistent navigation pattern. Keep important actions visible rather than placing them behind several unexplained icons. Test search with abbreviations, common misspellings and long names. Provide useful feedback when there is no result. An idle timeout should clear the previous journey and return to a neutral starting state after an appropriate interval. Confirm how the interface behaves on the actual screen dimensions and touch system. A desktop prototype is useful, but it does not reveal every issue with standing interaction.
Plan for network and data failures
Identify which parts of the directory can work locally and which need live services. If a network connection is lost, decide whether the kiosk can display an approved static map or a clear service notice. Avoid leaving a broken browser error or an endless loading animation in a public space. Test recovery when the service returns. Keep a process for urgent corrections that does not depend on the original developer being present. Hardware support, application maintenance and destination data ownership should be written as separate responsibilities.
Accept routes with real users and staff
Select representative tasks such as locating a service, finding an accessible path and returning to the home screen after a mistake. Observe first-time users without leading them through the interface. Record where they hesitate or stop. Ask reception staff to correct a destination and confirm it appears as expected. RSXD can confirm the proposed touchscreen kiosk hardware, operating system and interfaces; mapping software and venue data need their own agreed scope. Acceptance should prove a complete visitor journey, not merely that a tap produces a response.
A practical record to keep
Maintain a destination data sheet with public name, searchable alternatives, floor, map position and last verification date. Nominate a venue owner for that sheet. When the building changes, update both the underlying data and any static map assets. A reliable directory needs an ongoing information process as well as an attractive first-release interface.
Common questions
Does kiosk hardware include a complete wayfinding map?
Do not assume it does. Confirm map creation, application licensing, data updates and ongoing support explicitly in the proposal.
How should a kiosk handle an unavailable destination?
Show a clear result and useful next step, such as a verified alternative name or reception location, rather than presenting an empty page.
Further product information
This article is a project planning guide. Available features and performance depend on the exact quoted configuration. Confirm model details, site requirements and integration scope with RSXD.