The building data behind the experience
Defining navigation requirements means writing down, in specific and testable terms, what an indoor wayfinding system actually has to do for the people using your space. It sits between the decision that navigation is needed and the selection of a positioning technology. Get this stage wrong and you will either over-specify a system that costs more than necessary, or under-specify one that fails in live operation.
A requirement is not a wish list. It is a statement that can be verified: either the system does it, or it does not. "Visitors should find their way easily" is not a requirement. "A visitor at the main entrance must be able to locate a specific exhibition hall on the lower ground floor within three interactions on their own smartphone" is closer to one, though it still needs tighter constraints around device type and network conditions.
The process has three practical jobs. First, identify who is navigating and what they are trying to reach. Second, describe the journeys those users need to complete, including the conditions under which those journeys happen. Third, state the constraints your building, your operations and your users place on any solution. Only when those three jobs are done should you start talking about accuracy figures or beacon counts.
Who the users are
Different user groups have different needs, and those needs pull the requirements in different directions. A first-time visitor to a museum needs broad orientation and landmark-based directions. A regular visitor at a conference venue needs to find a specific room number quickly. A visually impaired visitor may need turn-by-turn audio guidance with a much tighter accuracy requirement than a sighted person reading a map. A member of staff moving equipment needs routes that avoid public areas, possibly with different operating hours.
If you write requirements around only one group, the system will likely underperform for the others. List every distinct user group you can reasonably anticipate, then note which journeys each group needs to complete.
What they are trying to reach
Destinations in an indoor space are not all equal. Some are fixed and permanent: toilets, lifts, exits, reception desks. Others change periodically: exhibition zones that rotate, pop-up retail units, event stages that shift between morning and evening sessions. Some destinations are single points, while others are zones where the user needs to arrive at any edge rather than a precise spot.
Your requirements should distinguish between these categories. A system that handles fixed points well may struggle with frequently reconfigured zones unless that variability is written into the specification from the start.
The conditions of use
Navigation does not happen in a vacuum. Consider whether users will have their phones out and unlocked, or whether they need one-handed operation while carrying bags or pushing a pram. Consider network availability: if your venue has poor mobile signal and no guest Wi-Fi, any system that relies on cloud lookups for each turn will fail at the moment the user needs it most. Consider peak periods: a system tested with fifty people in a hall may behave differently when fifteen hundred are present for a keynote.
Write these conditions into the requirements. "The system must operate without a live internet connection after initial content download" is a concrete constraint that eliminates certain architectures early.
Design zones, paths and instructions together
Museums and galleries
Museum navigation requirements often centre on routes rather than single destinations. Visitors may want a recommended path through a temporary exhibition, an accessible route that avoids stairs, or a themed trail linking related exhibits across multiple rooms. The requirement is not simply "get to room 4B" but "guide the visitor along a sequence of stops in a defined order, with content delivered at each stop."
Multi-floor venues need to handle vertical transitions clearly. A requirement might state that the system must indicate which lift or staircase to use and must confirm when the user has arrived at the correct floor before issuing the next instruction. Without that, users frequently exit at the wrong level, particularly in buildings where floor numbering is inconsistent.
Content delivery at each waypoint is part of the navigation requirement, not a separate concern. If the audio guide triggers at the wrong exhibit because the positioning is imprecise, the navigation has failed even if the user is technically "close enough" on a floor plan.
Retail environments
Retail navigation requirements often start with "find product category X" but quickly expand. Click-and-collect desks, fitting rooms, trolley returns and customer service points all become destinations. In larger stores, users may need to navigate between floors, and the route may need to account for one-way aisles or temporary displays that block direct paths.
A common retail requirement is dynamic destination updating. If a product is moved to a different aisle, the system should reflect that change without a manual update to every individual device. This places a requirement on the backend content management rather than the positioning layer, but it still needs stating here because it affects what the navigation system is asked to do.
Events and conferences
Event navigation has a particular constraint: the layout changes. A hall that is open-plan in the morning may be partitioned into breakout rooms by the afternoon. Stages, registration desks and catering areas may shift between days. Requirements for event navigation must address how quickly the map and route data can be updated and pushed to users, and what happens if a user is mid-route when a change occurs.
Emergency egress is a requirement that is easy to overlook in the excitement of planning wayfinding for sessions and social areas. If the navigation system is available during an evacuation, does it need to show exit routes? If so, those routes may differ from the normal paths and may need to override any ongoing journey immediately.
Accessibility requirements
Accessibility is not a separate requirement to be bolted on at the end. It affects the fundamental specification. A route that is acceptable for a mobile visitor may be impossible for a wheelchair user if it includes a stepped entrance or a narrow corridor. A visually impaired user may need audio instructions at a granularity of metres rather than rooms.
Write accessibility as primary requirements, not as exceptions. "The system must offer route options that avoid stairs and steps" is a core requirement for any multi-level public venue in the UK. "The system must provide audio turn-by-turn instructions with a minimum granularity of [distance to be determined during pilot testing]" is a specific, testable requirement for visually impaired wayfinding.
Acceptance testing in the live venue
Specifying accuracy without a measured environment
One of the most common mistakes is writing an accuracy requirement based on a vendor's datasheet rather than your actual space. "The system must be accurate to 1.5 metres" sounds precise, but in a venue with thick stone walls, metal racking or reflective glass, that figure may be unachievable with any reasonable hardware budget. Accuracy is a property of the environment and the technology combined, not of the technology alone.
Planning note: Range, timing and capacity figures depend on configuration and environment; record the conditions behind any value used for planning.
The practical approach is to state the accuracy your use cases demand, then treat the question of whether it is achievable as a matter for the pilot phase. "The audio guide trigger must fire when the user is within [X] metres of the correct exhibit, where X is to be determined through on-site measurement during the pilot" is an honest requirement that does not lock you into an untested claim.
Treating all zones as identical
Large venues almost always have zones with different characteristics. An open atrium will behave differently from a cluttered stockroom, a glass-walled meeting room from a concrete stairwell. Writing a single accuracy or coverage requirement for the entire site usually means either over-engineering the easy zones or under-delivering in the hard ones.
Break the site into zones and write requirements per zone where the use cases differ. A corridor leading to emergency exits may need higher reliability than a secondary retail aisle, even if the accuracy requirement is the same.
Ignoring content and map maintenance
Navigation requirements frequently focus on the positioning and routing and say nothing about who updates the maps, how often, and what happens when a layout change is not entered promptly. In a museum with rotating exhibitions, a retail unit with seasonal displays, or an event venue with daily reconfigurations, stale map data will make the best positioning system useless.
Include requirements for update workflows: who can change the map, what approval is needed, how quickly changes propagate to users, and whether the system can flag destinations that have not been verified within a defined period.
Not involving operational staff
Requirements written entirely by a digital team or an external integrator often miss practical realities. Front-of-house staff know which areas visitors actually ask about, which signage is confusing, and where people consistently get lost. Facilities teams know which areas are temporarily closed, which doors are locked outside certain hours, and where the Wi-Fi coverage is weakest. If these perspectives are not in the requirements document, the system will be technically compliant but operationally naive.
Key checks before moving to technology selection
- For each user group, is there at least one complete journey defined from entry to destination?
- Have you distinguished between fixed, periodic and temporary destinations?
- Are accessibility routes specified as primary requirements, not add-ons?
- Have you stated the network and device conditions under which the system must work?
- Are accuracy requirements tied to specific use cases rather than applied site-wide?
- Is there a requirement for map and content update workflows, including update frequency?
- Have operational staff reviewed the requirements for gaps?
- Does the document distinguish between what must work at launch and what can be added later?
Once these checks are satisfied, the requirements document gives you a firm basis for the next stage: evaluating which positioning technologies can actually meet them in your specific environment.
