Download Not Required: Designing UK Services That Assume No Install
Photo: Arturo Michelena, Public domain, via Wikimedia Commons
UK service design has developed a quiet default: if a journey matters, it belongs in an app. The pattern appears in council waste collections, rail ticketing, parking, workplace onboarding, loyalty schemes and routine banking. The instruction is familiar: scan this code, download our app, create an account, then begin. Each step looks small. Taken together, they form a gate that excludes people who never install.
The problem is not that apps are inherently unwelcoming. It is that app-only design treats the download as a neutral prerequisite rather than a consequential demand on storage, attention, trust and hardware. A service that assumes an install is making a claim about the user's device, confidence and consent. In 2026, that claim is still too often untested.
The assumption baked into onboarding
App-only onboarding often begins as an internal simplification. A product team consolidates identity, notifications and payments into one native container. The business case cites engagement, retention and data quality. The design case cites a cleaner experience, but only for people who complete the install. What disappears from the diagram is the population that never reaches the first screen.
This is not a small population. It includes people on shared or corporate-managed devices who cannot install new software; older users who rely on a browser and a trusted bookmark; disabled users whose assistive technology works better on the web; people with limited storage or data; and privacy-conscious customers who decline another app. A person can own a smartphone and still be a non-downloader. The category is behavioural, not demographic.
Why QR codes and account walls fail quietly
QR-code gateways are especially prone to false assumptions. A code on a table, a parking sign or a rail poster appears to offer convenience. In practice it often resolves to an install prompt, a redirect to an app store, or a registration flow that cannot be completed without an account. The user is standing in a physical context with a task to finish. The digital doorway asks them to stop and become a different kind of customer.
Account walls compound the problem. Asking for an account before a price, a booking or a basic eligibility check turns identity into a toll. Some organisations justify this as necessary for personalisation or security. Often it is a data capture habit inherited from e-commerce, not a genuine service requirement. Progressive accounts, guest journeys and save-later options are well understood. They are simply not applied when the app is treated as the default.
A web-first service blueprint
A web-first blueprint starts with the smallest viable channel: a complete mobile web journey that can search, transact, book, pay and receive confirmation without an install. The app may then be offered as an enhancement for people who want notifications, offline access or faster repeat use. The important shift is structural. The app becomes an optional layer, not the entrance.
Service blueprints should map the non-downloader across frontstage and backstage. Frontstage: what the user sees at the QR code, the account prompt and the fallback route. Backstage: how identity, payments and case management work without a native app. Support processes: what staff do when someone cannot complete the journey, and whether they have the tools to finish it on the user's behalf. A blueprint that only maps the installed user is a partial blueprint.
Three design rules help. First, every QR code should resolve to a web page that can complete the task, not a page that promotes the app. Second, every account wall should have a guest or assisted route that preserves the same outcome, not a degraded second-class service. Third, every app-only feature should have a documented web equivalent or a clear human fallback. These are not compromises. They are the service.
Graceful fallbacks that preserve dignity
Fallback is often treated as a failure state: a phone number buried in an FAQ, a paper form behind a request, a call centre that cannot see the web journey. That approach preserves the system's convenience at the user's expense. A graceful fallback is designed, staffed and measured. It appears at the point of need, explains why it exists and does not punish the user with worse prices, longer delays or repeated verification.
Public sector teams should also consider their legal and policy context. The Equality Act 2010 and public sector accessibility regulations set expectations for inclusive digital services. They do not require every service to be app-free, but they do require teams to think about who is excluded by channel choice. In regulated sectors, treating the app as the only route can create fairness and vulnerability risks that are difficult to defend.
Measuring what the gate excludes
Analytics usually flatter the app. Teams measure installs, activation and in-app completion. They rarely measure the people who abandon at the install prompt, the QR code that fails to resolve, or the customer who calls because the web journey stops short. A useful dashboard includes channel completion, fallback usage, support contacts, accessibility feedback and the rate at which users are asked to download before they can act.
The app can remain a valuable part of the service. It should not be the only door. UK product teams should design for the installed and the uninstalled with the same seriousness, because the non-downloader is not an edge case. They are a mainstream user whose time, device and consent deserve the same respect as anyone else's.
