Implementing an AR wayfinder is much more than putting a map inside an app. Most of the quality of the final result comes from two things: the work done before any visitor opens the application, and the refinement that continues once real people start using it.
Eureka Use Case
This article covers why we do each step, and how it impacts what a visitor experiences. We use the McGill University Health Centre Glen site in Montréal, where we built the Eurêka wayfinder, as a concrete example throughout.
This is the first of two articles. The second is a deep dive into the part that is specific to AR: capturing and calibrating the 360 images that drive the augmented reality directions, and the technical constraints we design around.
This is the first of two articles. The second is a deep dive into the part that is specific to AR: capturing and calibrating the 360 images that drive the augmented reality directions, and the technical constraints we design around.
Why we start by understanding the site
Each campus is unique
A wayfinder is only as good as its understanding of the building. If our model of the site is incomplete or wrong, no amount of polish in the app will fix it. So we begin by walking the site the way a first time visitor would, and by mapping the parts that are easy to get wrong.
Large campuses get complex for understandable reasons, often because several institutions have been brought together into shared infrastructure. The MUHC Glen site is a good example. It opened in 2015 and brought several institutions onto one campus, including the Royal Victoria Hospital, the Montreal Chest Institute, the Cedar Cancer Centre, the Montreal Children's Hospital, and the MUHC Research Institute. The building is recent, and the complexity that comes with consolidation is exactly what we set out to map. On top of that, more than half the people who arrive at the Glen site have never set foot there before, so they do not know any of the logic or naming conventions. They may not know, for example, that the campus has two separate children's hospitals sitting next to each other.
Large campuses get complex for understandable reasons, often because several institutions have been brought together into shared infrastructure. The MUHC Glen site is a good example. It opened in 2015 and brought several institutions onto one campus, including the Royal Victoria Hospital, the Montreal Chest Institute, the Cedar Cancer Centre, the Montreal Children's Hospital, and the MUHC Research Institute. The building is recent, and the complexity that comes with consolidation is exactly what we set out to map. On top of that, more than half the people who arrive at the Glen site have never set foot there before, so they do not know any of the logic or naming conventions. They may not know, for example, that the campus has two separate children's hospitals sitting next to each other.
A few of the things we analyze, with Glen site examples:
How the existing signage already works
We analyze the static maps printed on site and the conventions they already rely on: colours used to separate areas, the glyphs in use, and naming conventions such as floor levels. Reusing what people already see on the walls keeps the app consistent with the building. At the Glen site, a colour scheme was already in use to separate the institutions.
How the addressing works
This is key for the directory, and it differs from one hospital to the next. We sometimes find several address conventions on the same site. A typical case is when a new building or pavilion is added and the existing buildings are not re-addressed to match.
Because the Glen site is recent, it uses a single unified address system. Each location has a three part address: Area, Floor, and Room number, for example D RC.3114. On a campus this size, room numbers follow the building's construction logic rather than the path a visitor walks. We don't expect a visitor to decode that. We map the numbering ourselves so the app guides them to the exact door regardless of how the numbers are arranged. We also add relevant intermediary addresses as references along the route, for example "turn right at door C 02.1024".
Because the Glen site is recent, it uses a single unified address system. Each location has a three part address: Area, Floor, and Room number, for example D RC.3114. On a campus this size, room numbers follow the building's construction logic rather than the path a visitor walks. We don't expect a visitor to decode that. We map the numbering ourselves so the app guides them to the exact door regardless of how the numbers are arranged. We also add relevant intermediary addresses as references along the route, for example "turn right at door C 02.1024".
How areas relate to institutions
The Glen site is divided into five areas, A through E. Because several institutions share the same building, an area does not map one to one to a single institution. We map this carefully so the app always knows which institution a visitor is actually heading to, even when the area letter alone does not say so.
Where visitors actually arrive
People often start somewhere other than the main entrance. At the Glen site, many arrive from the S1 and parking levels. We study these arrival flows so the app is useful from where people actually begin their trip. They also tell us where to advertise the application, with large QR codes and kiosks where possible.
Which paths a visitor can actually use
Not every corridor is open to everyone, and some destinations are reached through one specific elevator group. We map which paths are available to a visitor, so the route we give only uses corridors and elevators they can take.
"The visitor never has to understand the building's internal logic, because we have already absorbed it into the system."
Example of customization of the directory based on on-site analysis
Smart directory
Building a directory that matches how people search
Once we understand the site, we build the directory, which is the backbone of search. A map is not helpful if a visitor cannot find their destination by the name they have in their head.
We compare the provided directory against the information available online to find destinations that are missing or do not match. We then complete each entry so we know which services it provides, and we add keywords for abbreviations, nicknames, and the services offered.
This matters because the same place is often called several things. At the Glen site, the McConnell Resources Centre is referred to most of the time as "the library." What matters is that the visitor finds it no matter which name they use. When we find a gap like this, we share it with the hospital's project manager so the on site signage can be aligned too if useful.
We compare the provided directory against the information available online to find destinations that are missing or do not match. We then complete each entry so we know which services it provides, and we add keywords for abbreviations, nicknames, and the services offered.
This matters because the same place is often called several things. At the Glen site, the McConnell Resources Centre is referred to most of the time as "the library." What matters is that the visitor finds it no matter which name they use. When we find a gap like this, we share it with the hospital's project manager so the on site signage can be aligned too if useful.
Important
One important rule while building the directory: two destinations cannot share the same name. If two locations are called the same thing, something has to distinguish them, otherwise a visitor cannot be sure they are going to the right place.
The power of keywords
Keywords do more than catch nicknames and abbreviations. They are also where we capture what a location is actually about, which is often the part a visitor cannot guess from a name.
This matters most for the abstract destinations that hospitals are full of: intermediary points a visitor has to reach first, even though it is not where they think they are going. A patient with a gastroenterology appointment may need to report to a general ambulatory services wicket before anything else. Searching "gastroenterology" is the natural thing to do, but the place they actually need is "Clinics," and nothing about that name would tell them so. So we make "gastroenterology" a keyword on the Clinics destination, and the search sends the visitor to the right first stop.
Getting the right result is only half of it. The visitor also has to trust it, and a result that looks unrelated to what they typed is easy to dismiss. So our search does not just return the destination. It shows the matching keywords alongside it, with the part that matched the query highlighted. When someone searches "gastroenterology" and lands on Clinics, they can see exactly why, and that visible link between what they typed and what we recommend is what gives them the confidence to follow it.
This matters most for the abstract destinations that hospitals are full of: intermediary points a visitor has to reach first, even though it is not where they think they are going. A patient with a gastroenterology appointment may need to report to a general ambulatory services wicket before anything else. Searching "gastroenterology" is the natural thing to do, but the place they actually need is "Clinics," and nothing about that name would tell them so. So we make "gastroenterology" a keyword on the Clinics destination, and the search sends the visitor to the right first stop.
Getting the right result is only half of it. The visitor also has to trust it, and a result that looks unrelated to what they typed is easy to dismiss. So our search does not just return the destination. It shows the matching keywords alongside it, with the part that matched the query highlighted. When someone searches "gastroenterology" and lands on Clinics, they can see exactly why, and that visible link between what they typed and what we recommend is what gives them the confidence to follow it.
Review and validation
We also give the customer access to the directory through a dedicated review tool that lets them check every item and compare or edit the multilingual texts easily. The whole directory was built 100% bilingual at the Glen site, from the ground up, with attention to precise translation since medical terms are highly specific.
This is the most important part of the experience: a visitor has to find the right destination, in either language, no matter what information they start with.
This is the most important part of the experience: a visitor has to find the right destination, in either language, no matter what information they start with.
creating the interactive map
Preparing the map foundation
With the directory in place, we prepare the interactive maps. The source material is rarely ready to use as is. The maps often arrive as static PDFs, sometimes split by area and floor. When that happens, we combine the submaps into full, detailed floor maps that we use as a data layer in our map editor. We then create a simplified vector version of the map at real scale, which also includes public transit, external parking, and external clinics, so the picture does not stop at the building entrance.
This matters because the real starting point is often a metro platform or a parking spot, not the front door. At the Glen site, the map covers the three main floors and two parking levels, and the directory covers all floors. In total we have already covered 100 health destinations (more will be added in a later phase), 40 parking lot sections, and 22 types of amenity such as restrooms, entrances, stairs, and parking.
The impact: a continuous, real scale map that can route someone from where they truly start, across transit and parking, all the way to the exact door.
This matters because the real starting point is often a metro platform or a parking spot, not the front door. At the Glen site, the map covers the three main floors and two parking levels, and the directory covers all floors. In total we have already covered 100 health destinations (more will be added in a later phase), 40 parking lot sections, and 22 types of amenity such as restrooms, entrances, stairs, and parking.
The impact: a continuous, real scale map that can route someone from where they truly start, across transit and parking, all the way to the exact door.
A working version from day one
Our wayfinding applications are functional from day one. We don't wait until the end and hope all the pieces fit together. We put a real, working version in place early and improve it from there.
Part of what makes this possible is our own CMS and map editor. We reuse the same core across projects, then customize it in depth for each customer with their colours, branding, and requirements. That lets us stand up a working, customized application quickly instead of rebuilding from scratch each time.
The benefit of building this way is that the application becomes something we can test with real people early, while we keep refining the foundation underneath it.
Part of what makes this possible is our own CMS and map editor. We reuse the same core across projects, then customize it in depth for each customer with their colours, branding, and requirements. That lets us stand up a working, customized application quickly instead of rebuilding from scratch each time.
The benefit of building this way is that the application becomes something we can test with real people early, while we keep refining the foundation underneath it.
Testing, feedback, and continuous fine-tuning
A wayfinder is not finished when it launches. The site keeps changing, and real visitors use the app in ways no one fully predicts, so we treat testing and refinement as part of the build, not an afterthought.
We start by testing on site with volunteers and gathering their feedback. At the Glen site, most of the feedback was about keywords and destination names, the actual words people use to search. That makes sense: this kind of information can only come from the people working in the building every day. The feedback feeds straight back into the directory, where we add the missing terms so the next visitor finds the location on the first try. We also use this stage to fine tune the UX based on where we see people struggle.
We then ran a wider test phase with employees, with a small contest to encourage people to send feedback. People who know the building well notice different things than first time visitors, and both perspectives matter.
Thanks to the dedication of employees and volunteers, we collected more than 50 comments in just a few days. That feedback let us add concrete fixes to remove confusion between similar destinations. The pharmacies are a good example: there are three at the Glen, a general pharmacy for external visitors and prescriptions, one specialized in oncology, and one for internal patients only that was often confused with the external pharmacy. We also added other destinations that visitors were looking for.
The impact is a system that gets sharper with use. Listening to real searches is how the directory stops reflecting the official names and starts reflecting how people actually talk.
A dedicated article will be published soon on this matter, if you are interested, we recommend watching the following video : Unlock the potential of interactive navigation solutions with Data-Driven KPIs
We start by testing on site with volunteers and gathering their feedback. At the Glen site, most of the feedback was about keywords and destination names, the actual words people use to search. That makes sense: this kind of information can only come from the people working in the building every day. The feedback feeds straight back into the directory, where we add the missing terms so the next visitor finds the location on the first try. We also use this stage to fine tune the UX based on where we see people struggle.
We then ran a wider test phase with employees, with a small contest to encourage people to send feedback. People who know the building well notice different things than first time visitors, and both perspectives matter.
Thanks to the dedication of employees and volunteers, we collected more than 50 comments in just a few days. That feedback let us add concrete fixes to remove confusion between similar destinations. The pharmacies are a good example: there are three at the Glen, a general pharmacy for external visitors and prescriptions, one specialized in oncology, and one for internal patients only that was often confused with the external pharmacy. We also added other destinations that visitors were looking for.
The impact is a system that gets sharper with use. Listening to real searches is how the directory stops reflecting the official names and starts reflecting how people actually talk.
A dedicated article will be published soon on this matter, if you are interested, we recommend watching the following video : Unlock the potential of interactive navigation solutions with Data-Driven KPIs
Multi-phase implementation
Not everything has to be mapped for the initial launch. A wayfinder is an evolving tool. We can start with the main floors and buildings and add the rest later. There are many ways to reduce the initial scope while still delivering real value to visitors and employees.
Here, the first phase focused on three institutions and the three main floors plus the parking levels. Another institution is under discussion to be added in the near future, and other floors can follow. The system also has built-in features for progressive deployment, with fallbacks for destinations that are not mapped yet.
Here, the first phase focused on three institutions and the three main floors plus the parking levels. Another institution is under discussion to be added in the near future, and other floors can follow. The system also has built-in features for progressive deployment, with fallbacks for destinations that are not mapped yet.
What makes us different
The philosophy behind the process
A few principles guide every step above, and they are the reason the process produces good results rather than just a lot of data.
We complement existing systems, we do not replace them. Signage stays, and volunteers stay. The wayfinder is one layer added on top.
There is no single entry door into the application. Different people arrive differently, so we use multiple entry points: a QR code, an easy domain name to type, digital signage kiosks, and clear links on the hospital's own website.
There is no perfect solution that works for everyone. Disabilities, language barriers, and personal preferences all vary, so combining several solutions, and building fully multilingual, is the only way to reach almost everyone.
The intake point is validated on site, destination by destination. We do not pin the general department location. We validate where the visitor actually has to go, which is often a specific window wicket and sometimes a different place from where you would expect the department to be.
We complement existing systems, we do not replace them. Signage stays, and volunteers stay. The wayfinder is one layer added on top.
There is no single entry door into the application. Different people arrive differently, so we use multiple entry points: a QR code, an easy domain name to type, digital signage kiosks, and clear links on the hospital's own website.
There is no perfect solution that works for everyone. Disabilities, language barriers, and personal preferences all vary, so combining several solutions, and building fully multilingual, is the only way to reach almost everyone.
The intake point is validated on site, destination by destination. We do not pin the general department location. We validate where the visitor actually has to go, which is often a specific window wicket and sometimes a different place from where you would expect the department to be.
What comes next
In the second article, we will cover the part that is specific to AR: capturing 360 images at every intersection and door, the constraints we design around such as weak GPS and no signal at all inside the parking, and how we calibrate each image so the AR instruction points precisely at the right door or elevator.
