Grounded

Week 18

Why I decided to investigate apps separately

After looking at wider airport accessibility programmes and collecting visual references, I wanted a more focused review of digital applications. My project currently aims to connect three things: changing journey information, relevant environmental or sensory options, and assistance that travellers can choose to use. An app could be one way of presenting these functions, but I have not established that it is the best or fairest medium. I therefore wanted to see what existing apps already do and how other designers have approached comparable communication problems.

For this scan I distinguish operating products and services, documented on official sites or app listings, from Behance portfolio projects, which may be student exercises, design concepts or unverified proposals. The first group helps me understand existing functions and service dependencies. The second gives me visual and interaction-design precedents, including how designers present research, wireframes, states and choices. Neither kind of source, by itself, establishes usability or effectiveness with autistic adults in airports.

GoodMaps — accessible indoor navigation and connected touchpoints

Status: operating product; direct airport-relevant comparator.

GoodMaps — Indoor Navigation Platform | GoodMaps — Airports | App Store listing

GoodMaps is one of the closest functional precedents to my developing idea. Its platform links indoor mapping and navigation across app, web and venue interfaces. The provider describes visual routes, written and audio directions, accessibility preferences and a shared map source. It also explicitly identifies airports among its deployment environments. This matters because it demonstrates that connecting wayfinding across multiple touchpoints is not, by itself, an original concept.

From a graphic-design perspective, I am interested in the relationship between an overview map and the current instruction, and in how one underlying system can maintain a consistent visual language across different displays. I also want to investigate the difference between an accessible route and a sensory-preferred route. Avoiding stairs is not equivalent to knowing whether an area is crowded or noisy, and the available material does not establish that GoodMaps predicts autistic sensory needs. Its airport deployments and reported capabilities are provider descriptions, not independent evidence of effectiveness for my population.

MagnusCards — staged airport-process guidance

Status: operating app; direct neurodivergence-related airport precedent.

Toronto Pearson — MagnusCards | Pearson — Travel tools for autism and diverse needs

MagnusCards offers step-by-step digital guidance for familiar tasks, with 26 Toronto Pearson card decks covering airport processes such as check-in and boarding. Travellers can review a process before travelling and consult it again in the terminal. I see this as a strong example of reducing a complex activity to a sequence of understandable actions without requiring a sophisticated sensing system.

The design question for my project is how far this staged approach should go. A simple current step might make an immediate action clearer, but it could also hide necessary orientation or alternatives if the interface is too linear. The Pearson material primarily describes prepared process guidance; it does not show that the app independently verifies a new gate or manages live sensory and assistance information. I would like to compare its approach to sequential instructions with an interface that preserves a full journey overview and optional choices.

NaviLens and NaviLens GO — linking physical codes to app information

Status: operating accessibility app and signage system; cross-disability precedent.

NaviLens — Official site | NaviLens — Case studies

NaviLens uses distinctive colour-coded visual markers that phones can recognise at a distance, with audio and haptic guidance in the NaviLens app and visual or augmented-reality information in NaviLens GO. The official deployment list includes airport environments. Unlike a fully phone-centred concept, the system makes a physical sign the entry point to digital information.

For my project, this suggests an interesting way of thinking about continuity between an airport environment and an individual's device. It also raises practical concerns: whether scanning a sign adds work, whether someone has a compatible device, how the information is maintained and what happens if a scan is unavailable. NaviLens was developed especially around blind and low-vision navigation, so I must not assume that the same presentation choices are preferred by autistic adult travellers.

Aira Explorer — live human guidance through an app

Status: operating app and airport service; cross-disability human-assistance precedent.

Aira connects a person who is blind or has low vision with a trained visual interpreter through their phone camera. Pearson's airport page explains that the service offers guidance but does not replace airline accessibility assistance. This is a useful boundary for my concept: an interface can make a support route visible, but a live service must actually exist behind the button.

I am interested in how the traveller actively initiates the connection, how clearly the service's scope is explained and how an app might route someone to the correct human support. I would not generalise its usefulness to all autistic adults, because the target population and assistance purpose differ. The example nevertheless challenges the idea that automation is always more independent than chosen human assistance.

Be My Eyes — one interface, different ways to ask for help

Status: operating accessibility app; airport use documented; cross-disability precedent.

Be My Eyes — App and features | Be My Eyes — Airports

Be My Eyes brings together volunteer video assistance, AI image descriptions and access to specialist organisations. The company also describes airport partnerships, including support at Rome Fiumicino. What interests me is the presence of different types of help within one familiar access point, rather than the assumption that a user should receive one automatic response.

This is relevant to the distinction I want to make between checking information, requesting staff support and accessing an optional assistive feature. Be My Eyes serves blind and low-vision users, and its AI functions should not be treated as guaranteed substitutes for authoritative airport information. The design lesson is about deliberate help-seeking, routes to appropriate people and transparent service limitations.

Brain in Hand — personalised strategies with human support

Status: operating neurodiversity support app; not airport-specific.

Brain in Hand — Official platform | Brain in Hand — App Store

Brain in Hand combines digital planning, personalised strategies and on-demand human support for autistic and ADHD users. This is particularly relevant to my research theme of independence as control rather than self-sufficiency. The app is not an airport navigation system, but it provides an example of assistance being available by choice alongside personal strategies.

The important limitation is contextual. A service designed for everyday planning and support cannot be assumed to deliver confirmed flight information, sensory maps or operational airport assistance. I would also need to examine the access and funding arrangements, privacy implications and effort required to set up personal preferences before using this as inspiration for a travel system.

AccessNow — finding places through accessibility details

Status: operating accessibility information app; not airport-specific.

AccessNow — App update and interface examples | AccessNow — App Store

AccessNow lets users search and contribute information about the accessibility of places. Its interface uses map browsing, features, ratings and photographs. I find it useful as a precedent for describing environmental conditions rather than presenting a location as simply 'accessible' or 'not accessible' without explanation.

However, much of this information is contributed by users. The distinction between a community description and a verified, current operational fact would be crucial in my proposed system. It would be risky to interpret a crowd-sourced place rating as proof that a quiet space is available now or that a route will have a predictable sensory environment. This example gives me ideas about environmental information architecture while exposing the importance of accuracy and uncertainty labels.

WelcoMe — communicating assistance needs to a service provider

Status: documented service/app platform; current availability at a specific airport not established here.

Neatebox WelcoMe — Product development case study | World Summit Award — WelcoMe

WelcoMe is a particularly relevant service-design precedent because it allows a disabled visitor to communicate support requirements to a participating organisation in advance, so staff can prepare for the visit. Unlike most wayfinding apps, the central interaction is the relationship between a person's request and the organisation expected to respond.

This connects strongly with my idea of chosen airport assistance. However, preparing staff is not equivalent to proving that assistance will be available at a particular time, and the cited materials do not establish a current integration with a particular airport. For my project I would need to define which requests the airport could genuinely receive, how the traveller would know their status, and how to withdraw or change a request.

What the operating apps already cover

Reviewing these services suggests that many of the functions I initially associated with my idea already exist separately or in some combinations. GoodMaps joins physical and digital navigation; MagnusCards provides prepared process instructions; Heathrow supplies live journey information; NaviLens connects signs with phone-based guidance; Aira and Be My Eyes provide routes to human assistance; Brain in Hand combines chosen support with personal strategies; and AccessNow communicates location-based accessibility information.

I therefore cannot claim that one new app containing a map, alerts and help buttons would automatically be an original Master's contribution. The opportunity may instead be to examine a particular missing relationship between verified flight changes, current instructions, environmental choices and assistance, or to demonstrate why those functions should remain available across existing channels rather than within a new app.

Behance: why I also examined portfolio concepts

Official product sites are useful for identifying services but are not always the clearest record of the graphic-design process. Behance projects can show how another designer approached a brief through mapping, wireframing, typographic decisions, colour systems and prototype states. I am therefore using Behance as a visual and process reference, not treating the presence of a polished case study or a self-reported test as independent validation of real-world use.

ThisWay — airport navigation app (Brandon Muchenje, 2025)

Status: Behance UX case study; not verified as a deployed airport product.

ThisWay explores airport navigation for people with visual impairments and travellers facing language barriers, using speech, visible directional information and alternative presentation modes. The creator shows research, wireframes, mock-ups and a description of usability-study feedback. I find the contrast between visual maps and separate directional cues especially useful for developing information hierarchy.

The creator reports preferences arising from project testing; those accounts are not independently verified here and concern a different audience. I want to take forward the question of what belongs on a map versus what deserves a prominent current-step message, without assuming that audio or dark mode is automatically preferred by autistic adults.

AeroAssist — airport assistance app (Fahim Ahmed and collaborators, 2025)

Status: Behance design case study; deployment unverified.

AeroAssist combines flight status, service booking and live airport-support chat in a single proposed interface. Of the Behance examples, this overlaps closely with my interests in journey information and deliberate assistance. Its case-study presentation includes an interaction flow, interface work and a claimed research/testing process.

The overlap creates a useful challenge: my design cannot rely on 'putting everything in one app' as its defining contribution. I need a reasoned distinction such as verified update states, sensory/environmental choices, a route back to the full journey, or reliable access to help without requiring constant phone use. Those remain hypotheses requiring comparison.

Catania Airport — integrated website, app and design system (The Wave and collaborators, 2025)

Status: agency portfolio describing a developed client ecosystem; accessibility claims are agency-reported.

This is one of the most directly relevant graphic-design system precedents. The studio describes a shared 'Terminal' design system across the airport website, mobile app and other organisational platforms, with consistent components and real-time passenger information. Unlike a mock-up of a standalone phone screen, it places visual identity and interaction patterns within a wider service infrastructure.

I am interested in the underlying design-system logic: how type, states, navigation and communication rules work together across several touchpoints. Its accessibility and performance claims are presented by the creators, so I should not treat them as independently measured outcomes. The case does demonstrate that a coherent multi-platform visual system has already been pursued by airport designers.

WayBetter — joined public-transport app and signage (Tommaso Marchiori and collaborators, 2023)

Status: Behance thesis concept; public transport, not an airport deployment.

WayBetter explicitly explores linking physical wayfinding and a transport app through a shared visual communication approach. Although it concerns Milan public transport, it mirrors the method I am considering: graphic design as the connection between the built environment and personal digital guidance.

It reminds me that the strongest visual work may be a system of information rules rather than a branded app alone. The transfer to airports is an inference, however, and I would need to account for aviation-specific constraints such as confirmed gate updates, security processes and operational staff responsibilities.

Unspoken Needs — communicating choices without speech (Gabriela da Silva, 2025)

Status: Behance mobile-app case study; deployed product and validation not established.

Unspoken Needs is described as a communication app for autistic adults to express needs, limits and emotional states without relying solely on verbal communication. This is particularly relevant to the assistance part of my project, which should not assume that a traveller always wants to explain a difficult situation verbally.

I am interested in how a user can specify their own preference and how a request might be understood by another person. At the same time, I must not turn the presence of an emotion or 'overwhelm' control into a claim that an app can infer someone's state. For airport use, staff would need to receive, interpret and be able to act on the request.

Airport Accessibility App (Sayan Goon, 2024)

Status: Behance visual/case-study reference; functions and deployment not verified from the available text.

The project is directly relevant by title and category. However, the accessible text provides limited detail about its exact interactions and evaluation. I am keeping it as a candidate for closer visual inspection rather than inventing specific features or claiming that it addresses my research problem. Before using it as a major comparison I would need to examine the project boards and identify the actual screen flows.

ARPORT — AR airport wayfinding (Mushfika Iffat and Ali Hasnain, 2026)

Status: Behance UX concept; real deployment not established.

ARPORT explores augmented-reality directions for complex terminals. Its relevance lies in the distinction between showing a route as a map and placing directions in the visual environment. However, AR would create its own attention, device-use and implementation demands; my research does not justify assuming that camera-based navigation would be preferable in a crowded airport. I would treat this as an option to compare, not a predetermined next step.

WING IT — airport assistance and planning app (Suhani Baweja and Diya Pansuriya, 2025)

Status: Behance concept/prototype; not confirmed as an operating airport service.

WING IT explores navigation, time management and document handling, progressing from research and low-fidelity sketches to a high-fidelity Figma prototype. I find it useful as a way to examine design-development documentation: the connection between identified task problems and the interface solutions eventually illustrated.

It also raises a boundary question. Adding document storage, shopping, bookings and other travel functions could make a proposal appear comprehensive while distracting from my particular accessibility purpose. I should only add functions where I can show a clear route from research evidence to user task.

Wayfind Heathrow — physical landmarks with app clips (Charles Yao, 2024)

Status: conceptual design project, not verified as a Heathrow deployment.

Wayfind Heathrow combines spatial and multisensory interventions with lightweight app clips. It is especially relevant because it does not assume that a full downloaded app must carry the journey. Instead, mobile guidance is secondary to environmental wayfinding.

I should not generalise its suggested scents, sound treatments or 'calming' intentions to autistic travellers. The value for my project is the hybrid approach: some information belongs in the terminal, while a personal interface may supplement it only when the traveller chooses.

What I am learning from the design comparisons

The comparison is changing my thinking about naming and branding. I originally wanted a strong standalone product identity, but these precedents show that the service architecture must lead the visual identity. If a traveller already uses airport signage, the Heathrow app or staff assistance, introducing another branded product could create an additional layer to understand instead of reducing fragmentation.

At this stage I am more interested in prototyping a clear interaction sequence than creating a large number of finished screens. A defensible sequence might show a confirmed change, a clearly labelled next action, access to the entire journey, optional environmental details and a genuine staff-help request. I would also need to show that declining an offer or pausing any optional monitoring does not remove ordinary guidance. Importantly, this is a proposed design requirement, not a tested interaction.