--- title: The Boarding Pass That Wouldn't Load at the Airport description: Discover why apps fail users at critical moments and how designing for offline use from the start creates more reliable, stress-tested digital experiences. image: https://weareaffective.com/hubfs/learning-centre-images/the-boarding-pass-that-wouldnt-load-at-the-airport.webp --- [Skip to content](https://weareaffective.com/learning-centre/the-boarding-pass-that-wouldnt-load-at-the-airport#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # The Boarding Pass That Wouldn't Load at the Airport Table of Contents At a small regional airport with patchy Wi-Fi and a gate about to close, Simon pulled up his flight app to retrieve his boarding pass. The ticket had already been downloaded. The data was sitting on the device. But the app presented a "no connectivity" error and locked him out entirely, as though the ticket itself existed somewhere on a distant server rather than in the phone in his hand. What followed was a stressful manual verification process, proving payment at the gate, waiting while staff wrote out a ticket by hand, and boarding last with the kind of frazzled energy that no traveller wants at the start of a trip. > Static data that is already on the device should never require a live connection to display. That experience is worth dwelling on because it was not a connectivity problem. The data was there. The app simply had not been designed to show it without a live signal, and nobody building the product had apparently asked what should happen when the signal was gone. The result was a blocked user, a missed opportunity, and a person who would think twice before trusting that app again. This is the kind of failure that feels small in a product roadmap and enormous in real life. Travel is a high-stakes category emotionally. People are running late, managing luggage, navigating unfamiliar places, and operating under time pressure. When a product fails at exactly that moment, the damage runs deeper than a bug report. ## What Actually Happened at the Gate The flight app in question had almost certainly been built and tested in an office with a strong Wi-Fi connection. The boarding pass flow worked perfectly in that environment. A developer opened the app, the pass appeared, the test passed. What nobody had simulated was a user at a crowded gate with one bar of signal, or no signal at all, holding a phone showing nothing but a spinner and an error message. When Simon was locked out, the boarding pass was not missing. It had been retrieved during an earlier session and was resident on the device. The [app's architecture simply routed every screen load](https://weareaffective.com/app-ux-design) through a server call, and when that call failed, the screen failed with it. There was no cached fallback, no graceful degradation, no message explaining what had gone wrong or what the user could do. Just a blank screen and a wall of anxiety. The manual process that followed involved proving payment, waiting for staff to write a physical ticket, and joining the gate queue late. A journey that should have been straightforward became a test of patience and composure. The experience itself was fine in the end, but the memory attached to that app is not a positive one. This is how one-star reviews begin. Not with catastrophic product failures, but with moments where a product that should have worked simply did not, at the precise moment a user needed it most. ## The Boarding Pass Problem Is Not a Connectivity Problem The distinction matters enormously for how teams think about offline design. A boarding pass is static data. Once it has been issued, it does not change. The departure gate changes, occasionally. The seat assignment changes, rarely. But the core ticket, the thing you show to get on a plane, is fixed. Retrieving it does not require a round trip to a server. It requires reading data that is already on the device. When an app blocks access to that data because of a missing signal, the failure is architectural, not situational. The product has been built on the assumption that connectivity is always available, and every screen has been wired to confirm that assumption before doing anything. Remove the signal and the whole product stops working, including the parts that do not need the signal at all. The fix is not complicated in principle. Identify which data is static and cache it locally after the first retrieval. Build the rendering layer for those screens to read from local storage first, and only fall back to a network request if the local copy is absent or stale. The boarding pass appears because it is on the device, not because a server said it was allowed to appear. The complication is that this requires the [offline behaviour to be designed in from the start](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-). Retrofitting it once the architecture is set can be genuinely difficult, as the travel products we have worked on have made clear. ## UX/UI design built around *real* psychology We design app interfaces around how people actually think and behave. User research, psychology-driven UX/UI design and technical specs delivered as one complete package. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Designing for the User You Have, Not the User You Imagined There is a version of every user that product teams unconsciously design for: patient, calm, connected, with time to read error messages and retry failed actions. That user does not exist in airports. The user who actually exists is running slightly late, has one hand on a bag, is reading a screen in bright light, and is experiencing a low-level hum of travel anxiety that makes everything harder to process. We saw this dynamic clearly on a pitch we ran for a BMW fleet vehicle app. The app asked accident victims to record damage and fill in forms while standing at the scene of a collision. The interface said "upload your photos" and left users to work out what angles to capture, what details to record, and how to complete multi-field forms while they were in a highly distressed state. Completion rates were poor and the quality of submissions was inconsistent. The interface had been built for a calm, focused user in a controlled setting, not for someone running on adrenaline at the side of a road. > Stress compresses cognitive capacity, and the product has to meet users where they are. The same principle applies to travel. A person trying to board a flight is not in the best state to read a detailed error message, troubleshoot connectivity, or find an alternative. They need the product to work, simply and immediately. Designing for the calm, connected version of that user and then deploying to the stressed, disconnected version is a design gap that shows up in real situations. [Map the emotional state of your user](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you) at each step of the journey, not just the information they need. A screen that works technically can still fail if it asks too much of someone who is already overwhelmed. ## When We Built for Off-Grid From the Start On a travel product we worked on for younger backpackers visiting off-grid locations, unreliable connectivity was not an edge case, it was the core use case. The users were heading to places with sporadic signal at best, and the app had to work in those conditions or it had no reason to exist. We [rethought the architecture around four questions](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one): what information can be stored offline, what information must remain online, how do we queue actions taken without a connection and replay them once the signal returns, and how do we minimise the data exchanged between the app and server to get the most out of limited bandwidth. Anything that could be baked into the product was. Everything else was kept as lightweight as possible. The result was a product that functioned where its users actually were, not where a developer's office network had assumed they would be. Maps, itineraries, saved locations, and tickets were all available without a connection. Transactional features such as booking changes were queued locally and synced when connectivity returned, with clear messaging so users understood what state their request was in. Building this way from the start is significantly easier than adding it later. The architecture supports offline from the first decision, rather than having to unpick assumptions baked into every layer of a product that was built for permanent connectivity. Decide at architecture stage, not at retrofit stage, which data is static and should live on the device. Moving that decision later costs multiples of what it would have cost early. ## When Offline Was an Afterthought: The Retrofit Problem We also worked with a travel app used for exotic holidays and backpacking in remote wilderness areas that had not started with offline in mind. When the product expanded into a new type of trip, users were heading to locations where connectivity was genuinely absent for stretches of hours or days. The app, built for always-on use, would simply display a "not connected" error on launch and become completely unusable. The problem was not a missing feature. It was a foundational assumption threaded through every part of the product. Map search, saved pins, itineraries, tickets, and location times all required a server call to render. There was no local data layer to fall back on because none had ever been planned for. Adding offline capability at this stage meant working against the grain of the existing architecture at every turn. For users in the field, this was not a minor inconvenience. Someone relying on the app for navigation or ticket retrieval in a remote location, with no connectivity and no fallback, was left with nothing. An absolute disaster, in Simon's words, and the kind of experience that generates the worst possible reviews and the sharpest drop in trust. The lesson from both projects, the one built for off-grid from day one and the one retrofitted under pressure, is that [offline capability is an architectural decision](https://weareaffective.com/learning-centre/what-offline-features-do-users-actually-want-in-mobile-apps) that becomes dramatically more expensive the later it is made. ## Stress Changes What Users Can Do When someone is anxious, their ability to process information drops noticeably. Working memory narrows. The bandwidth available for reading instructions, interpreting error messages, and making decisions shrinks. This is a predictable consequence of how the brain allocates resources under perceived threat, and it applies to the low-level stress of travel as much as to more acute situations. What this means practically is that the interface that works well in a calm usability session may fail in real use, not because it changed, but because the user did. We have seen this in the context of financial data: users reviewing checkout flows in a test session assess them rationally because they are not genuinely parting with money. [Live analytics tell a different story](https://weareaffective.com/learning-centre/how-to-read-a-user-session-recording-for-emotional-signal-rather-than-task-compl), where [elements that looked fine in testing erode trust](https://weareaffective.com/learning-centre/what-makes-users-trust-a-product-enough-to-enter-their-card-details) just enough to push someone out of the flow at the moment of commitment. The emotional state of the real moment is absent from the test. Airport stress is similar. A user who navigated the app easily at home will struggle with the same interface at the gate, because their cognitive state is different. Error messages need to be shorter. Actions need to be more obvious. And the most critical information, the boarding pass, the itinerary, the booking reference, needs to be available without requiring any navigation at all. Building for stressed users means stripping back, not adding. Fewer decisions, shorter copy, immediate access to what matters most. The simpler the interface, the more of it survives the conditions of real use. ## What Good Offline Handling Actually Looks Like The contrast with poor offline handling is clearest in mapping products. Google Maps and Apple Maps handle degraded connectivity in a way that is worth studying in detail. Both apps use clear mode signposting so users always know whether they are looking at downloaded or live data. Both cache frequently visited areas behind the scenes, so users often have local data without having consciously downloaded anything. Both degrade gracefully with zoom level: zooming out always shows a usable overview, even when street-level detail has not been saved. A user is never left staring at a blank, unloaded map with no idea where they are. The principle behind this is straightforward. Show the user something useful at every state, including the offline state. Never leave them with nothing. If the live data is unavailable, show the cached version and label it clearly. If no cache exists, show a clear explanation and an actionable suggestion. A blank screen with a spinner is the failure mode; a partial view with honest labelling is the floor below which the product should not fall. - Show cached data immediately and label it as such - Explain the connectivity state in plain language, not error codes - Give users one clear action they can take from an offline state - Never display a blank screen where a cached version could appear instead For travel apps specifically, the stakes are higher than for most categories because the moments of use are high-pressure and the fallback options are limited. A map user who goes offline can find a landmark to orient themselves. A traveller who cannot access their boarding pass has no equivalent fallback. ## How to Decide What Must Work Without a Signal Not every feature in a travel app needs offline support, and trying to build it for everything is a path to a product that does nothing particularly well. The decision of where to invest comes down to two things: how much stress the user is under at that moment, and whether the feature actually requires a server or can work with local data. The highest-stress moments in a travel journey are the ones to protect first. Check-in, boarding, ticket retrieval, navigation at a destination, and accessing a booking reference when something has gone wrong are all moments where the user is under pressure and failure is most damaging. These are also, frequently, the moments where the data required is static and does not need a live connection to retrieve. | Feature type | Requires server? | Offline approach | | --- | --- | --- | | Boarding pass / ticket | No, once retrieved | Cache locally, display from device | | Itinerary / saved places | No | Offline-first by default | | Map data | Partially | Cache tiles, degrade gracefully at detail | | New booking | Yes | Fail gracefully with a clear message | | Booking changes | Yes | Queue locally, sync on reconnection | The dependency test is simple: does this feature require a round trip to a server, or can it render from data already on the device? If it can use local data, build it to do so. If it genuinely needs the server, decide whether to fail gracefully with a clear message or queue the action for later. Most travel apps would not need to go as far as action queuing, but they all need to handle the offline state for static content, and almost none of them do. [Run a dependency audit for your highest-stress user moments](https://weareaffective.com/learning-centre/5-user-testing-methods-that-will-save-your-app-from-failure) before deciding where to invest in offline capability. Static data that already exists on the device is the lowest-cost place to start. ## The Cost of Getting This Wrong There is a strong and direct relationship between offline failures in travel apps and the worst outcomes in any app's lifetime. When a product blocks a user from accessing their boarding pass, or leaves them staring at a blank screen in a remote location where they needed the map to navigate, the emotional response is the specific, memorable kind of anger that produces one-star reviews and does not soften with time. According to [Appwrk](https://appwrk.com/insights/app-crash), approximately 20% of mobile app crashes are correlated with network problems, including unstable connections and server timeouts. For a travel app, those crashes cluster disproportionately in the moments of highest use: at airports, in transit, in unfamiliar cities with limited signal. The crashes and failures do not distribute evenly across low-stakes and high-stakes moments. They land hardest where the user is already under pressure. The retention consequence is substantial. A user who could not access their boarding pass is likely to leave a review that shapes the decision of everyone who looks at the app store page before downloading. One failure at the gate can reach dozens of potential users through a single angry review, and there is no mechanism to retract it once the emotional moment has passed. Getting offline handling right for static content costs a fraction of what the negative reviews and user loss will cost over time. The economics are clear, even if the priority is not always reflected in roadmaps. ## Conclusion The boarding pass that would not load was not a dramatic product failure. The app worked in every situation except the one that mattered most. That is precisely what makes it worth examining, because it represents the gap between a product that has been tested and a product that has been designed for real use. Travel sits at the intersection of high emotional stakes and variable connectivity. Users are stressed, often in unfamiliar places, operating under time pressure, and relying on their devices to carry information they cannot easily access elsewhere. When a product fails in those conditions, the damage to trust is disproportionate to the technical size of the failure. A boarding pass that would not display because of a missing server call is a small architectural decision with a very large human cost. The answer is not to build offline support for every feature in every travel product. It is to identify, clearly and early, which moments carry the most stress and which data is already on the device, and to make those combinations work without a signal. That is a scoped, achievable piece of work that the products we have seen get right had all made as an architectural decision from the start. If your travel product, or any product used in moments of genuine pressure, has not been designed for the offline state, the question is not whether users will eventually encounter that state. They will. The question is what they will find when they do. [Let's talk about your offline experience](https://weareaffective.com/get-started) ## Frequently Asked Questions Why did the boarding pass app fail if the ticket was already downloaded? The app had been built to route every screen load through a server call, meaning it needed a live connection before displaying anything, even data already stored on the device. When the signal failed, the app failed with it, despite the boarding pass being fully available locally. Is this kind of failure caused by poor connectivity or poor app design? It is a design and architecture problem, not a connectivity problem. The app had simply been built on the assumption that a live signal would always be available, which meant removing that signal broke the entire product, including parts that had no need for it. What is offline-first design and why does it matter for travel apps? Offline-first design means building a product so that core functionality works without a live connection, using locally stored data wherever possible. For travel apps in particular, this matters enormously because airports, aircraft, and transit routes are common places where signal is unreliable or absent entirely. What should a well-designed boarding pass app do when there is no signal? It should display the cached boarding pass immediately from local storage, without attempting a server call first. A clear message explaining the offline state is helpful, but the ticket itself should never be hidden behind a connectivity check. How does a moment like this affect a user's long-term trust in an app? Failures during high-stress moments, such as rushing for a flight, create strongly negative memories that are difficult to overwrite. Even if the journey ends successfully, the user is likely to distrust that app in future and may actively avoid relying on it when it matters most. Why are travel apps particularly vulnerable to this kind of failure? Travel is an emotionally high-stakes category where users are often under time pressure, managing luggage, and navigating unfamiliar environments. A product failure at that moment feels far more significant than the same failure would in a lower-pressure context. How can development teams avoid building apps that fail without connectivity? Teams should test their products in realistic conditions, including environments with no signal or a very weak connection, rather than only in well-connected offices. Asking what should happen when the signal disappears should be a standard part of the design process, not an afterthought. Is fixing this kind of offline problem technically complicated? For static data such as a boarding pass, the fix is relatively straightforward in principle. It involves caching the data locally when it is first retrieved and reading from that cache when a live connection is unavailable, rather than blocking the user entirely. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.