Digital Wayfinding: The Map Is the Easy Part
Wayfinding is a maintained information service. Build the destination list first, decide what survives a network failure, and check the terminal on site.
An assumed scenario, constructed to show the decision. It describes no named customer and reports no measured result.
A hospital installs a wayfinding terminal in the main lobby. It works perfectly for four months. Then the cardiology department moves to the second floor, the terminal keeps sending people to the third, and within a fortnight the staff at reception have stopped mentioning it to visitors.
The terminal did nothing wrong. Nobody owned the information inside it. Wayfinding is not a screen project with a map on it; it is a maintained information service that happens to be displayed on a screen, and the maintenance is the part that decides whether it still works in year two.
Build the destination list before you design anything
The interface is downstream of the data. If the destination list is wrong, no amount of design fixes it.
Start with a controlled list, one row per destination, containing:
- the official name, spelled the way the building spells it;
- the names people actually use — "X-ray" and "Radiology" are the same place to different visitors;
- the floor or zone, and where it sits relative to a landmark somebody can see;
- who owns the record, by name, and when it was last checked.
Then reconcile it against reality. Walk the building with the list and check three things: that the physical signs use the same words, that staff use the same words, and that the route the screen will draw is actually walkable — not through a staff door, not across a construction hoarding, not up a staircase that is closed after six.
A directory built from an internal department chart is a common way this goes wrong, because visitors do not know what "Ancillary Services" means and will not search for it.
Test the list with outsiders before you build the interface. Ask three people who have never been in the building to find five destinations using the list on paper. Write down every name they could not find. Those names are the interface requirement. If the building also has screens, the retail placement guide covers where a terminal should stand and what it needs for servicing.
Choose how much guidance the visitor needs
| What the visitor needs | What suits it | What has to be maintained |
|---|---|---|
| To know which floor | A passive directory board | Names and floor assignments |
| To find one place among many | An interactive directory with search | The destination records and their search terms |
| To follow a route | A map with a marked path and a "you are here" | The floor plan and the landmark positions |
| To be told in words | A printed direction slip | The printer, the paper, and the route logic |
Two decisions sit inside that table and both are worth making deliberately.
Passive or interactive. The question is not how many destinations the building has but what the visitor has to do with them. Test it on the list you actually maintain: how many entries, in how many languages, at what reading level, and how often it changes. If a visitor who has never been in the building can find three destinations from a printed list within a minute, a passive board will do the same job with fewer dependencies. As the list grows, gains names a visitor would not guess, or needs to be searchable in a second language, search starts to earn its place. Search also adds things to maintain — software, a data source, a screen — and that cost is part of the answer.
Where the route starts. If the terminal is in the lobby, "you are here" is the lobby. If there are terminals on four floors, each one needs its own starting point, and a route that begins from the wrong floor is worse than no route.
Treat the starting point as part of the content
This is the detail most often missed, and it produces confidently wrong directions.
Every route the system draws begins somewhere. That somewhere has to be a real, named, unambiguous position: `Main lobby, facing the reception desk`, not `Level 1`. And it has to match where the visitor is actually standing, which means the terminal's own position is part of the data.
Then check the drawn route against the building:
- does it use a corridor a visitor is allowed to use;
- does it avoid doors that need a pass;
- does it account for the lift that only serves some floors;
- does it survive a temporary closure, and who updates that.
Test it by following the screen's own directions, at walking pace, with somebody who does not know the building. If they hesitate at a junction, the map is missing a landmark.
Make updating a routine, not a project
The terminal will need updating as soon as something in the building moves. The useful question is how quickly somebody fixes it.
Decide, in advance:
Who tells the system. A named person in facilities, or a shared inbox, or the department itself. Somebody needs to be able to report "we moved" without raising a ticket.
How fast. A department move, a temporary closure and a new tenant have different urgency. Decide which changes must be live within a day and which can wait for the next scheduled review.
Who checks. Decide the interval rather than inheriting one. A walk through the building with the destination list in hand is a reasonable starting point, and it catches the drift that nobody reported; shorten it if your own inspections keep finding changes that went unrecorded. Inspect after any fit-out or move, because that is when a wayfinding list goes wrong.
What happens in the meantime. If a destination is wrong and the fix takes a week, what does the screen say? A simple "check at reception for the latest" line is honest and better than a confident wrong route.
Decide what still works when the network does not
A wayfinding terminal that shows nothing is a wall. Plan the degraded states deliberately.
- Network down, terminal running. Does it show the last cached map and destination list? It should, and you should know how old that cache can be before it becomes misleading.
- Terminal restarting. What appears on screen during the restart, and how long does it take? A visitor standing in front of a booting screen will give up after a few seconds.
- Data source down. If the map comes from a live system, what shows when it fails? A static floor plan is a better fallback than an error.
- Power failure. Does the terminal come back by itself? Test it on a unit that is not in service, or in an agreed maintenance window, by switching its circuit off and on, rather than by assuming.
Print a fallback too. A laminated floor plan and a list of the ten most requested destinations, kept at reception, costs very little and covers every failure above.
Validate the terminal where it will stand
The last step is physical, and it is not the same as testing the software.
Stand at the terminal and check: can somebody in a wheelchair reach the interactive area; can a child; is the screen readable with the light that falls on it at the times the building is busy; is there room for a person to stand without blocking the corridor; and does a queue form in a place where a queue is acceptable.
Then check the cleaning and service routine, because a public terminal needs both, and confirm how the unit is reached if it stops responding.
For placement and standing space, see the retail placement guide, which covers the same decisions in a store context.
What this guide does not cover
It covers no accessibility requirements, which vary by building type and market. It recommends no software, terminal or screen size, publishes no usage or staff-saving figure, and does not cover outdoor wayfinding.
Send the destination list, get a terminal view
Send us the destination list, the number of terminals and their positions, and the software you intend to run. We will tell you which terminal configurations suit each position, what the installation and servicing need, and what has to be confirmed for the specific model.
Send the floor plan and the destination list →
Sources
- No external source is cited. This guide describes an information-maintenance method assembled from wayfinding deployment practice, and it makes no factual claim that requires a citation.
Compiled September 29, 2026. The method is the author's; the external sources are listed above, and the opening scenario is constructed rather than reported.
