The Bus Doesn’t Need Your Email: How Login Walls Colonised the Small Stuff

You are standing at a bus stop in the rain. Not torrential, just enough to make you hunch. You open the operator’s site to see when the next 42 is due. Cookie banner. Then: “Create an account to view live departures.”

This is a small absurdity, but it is not a minor one. Across the UK, the mundane interfaces of public life — bus times, council tip bookings, parking payments, school term dates, bin collections — are being folded into account walls. The task hasn’t become more complex. The front door has.

The login reflex

Some of this is deliberate. Some is drift. A council buys a booking module from a vendor; the vendor’s default template assumes a user account because accounts are how software vendors like to count things. A bus operator wants “engagement” and “personalisation,” so the timetable becomes a dashboard. A parking app needs payment, and payment needs identity, and identity quietly becomes a full profile with a marketing consent checkbox.

None of these decisions look sinister in isolation. Stacked together, they form a pattern: the low-stakes lookup is being reclassified as a relationship. And relationships demand data.

What a bus time actually requires

A bus time requires a route identifier, a stop identifier, and a clock. That’s it. It does not require your name, your email, your postcode, your date of birth, or your consent to “partner offers.” A tip booking requires a slot, a vehicle type, and maybe a proof of residency. A parking payment requires a location, a duration, and a payment token. These are small, bounded transactions. They are not accounts.

When you force an account onto them, you introduce three costs.

Privacy. A postcode plus a timestamp plus a repeated behaviour is a movement profile. It doesn’t matter that each individual lookup feels harmless. Aggregated, the data tells a story about where you go, when you go, and what you might need next. Public services should be cautious about collecting that story by default. Data minimisation isn’t a bureaucratic nicety; it’s the difference between a service and a surveillance surface.

Accessibility. Account walls assume a smartphone, an email address, a password manager, and the digital confidence to navigate a verification loop. That excludes older residents, people without stable housing, people with cognitive or motor impairments, and anyone who simply doesn’t want another login. The Public Sector Bodies Accessibility Regulations have been in force since 2018. They cover the interface, but they don’t automatically fix the architectural decision to require an account for a read-only task.

Security fatigue. Every unnecessary account is another password to reuse, another reset flow to fumble, another place your email address can leak. Users respond by making bad choices. Services respond by adding more friction. The cycle is predictable and pointless.

Identity for entitlement, not for convenience

There is a real distinction here, and product teams should name it explicitly. Some tasks genuinely need identity: applying for a parking permit, booking a bulky waste collection tied to a specific property, accessing NHS records, managing benefits. Those are entitlement checks. They require proof that you are who you say you are, and that you are entitled to the thing.

A bus time is not an entitlement check. A tip slot is borderline — it may need residency verification, but that can happen at the point of booking with a postcode and a licence check, not a permanent account. Parking payment needs a payment instrument, not a profile.

The mistake is letting the account become the default container for everything. Once the account exists, teams start bolting things onto it: saved vehicles, notification preferences, “your dashboard.” The small task becomes a product surface. The product surface needs engagement metrics. The metrics need reasons to bring you back. And suddenly the bus timetable is sending you push notifications about “travel inspiration.”

Designing for the drive-by

What would better look like? It would treat the public as passers-by, not members.

• Anonymous-first sessions. Let people complete the task without an account. If they want to save a booking or receive a reminder, offer a lightweight, optional account at the end — not the beginning.
• Device-local state. Store a parking session or a tip booking in the browser or on the device, with a short-lived token. No server-side profile required.
• Magic links instead of passwords. If identity is genuinely needed, use email or SMS one-time links. Don’t make people invent a password for a council tip.
• Public data, public interfaces. Bus timetables and bin collection schedules should be readable without authentication. Publish them as open data and let third parties build better front ends.
• Procurement pressure. Ask vendors for an anonymous mode. Make data minimisation a scoring criterion, not an afterthought. The GDS Service Standard already pushes teams to understand user needs and remove unnecessary steps; apply that to the login form.

The signal is the bus time

The account wall is a tax on curiosity. It punishes the person who just wants to know whether they have time for a coffee before the next bus. It punishes the resident who wants to check the tip’s opening hours without creating a “MyCouncil” profile. It punishes everyone who has learned, rightly, to be suspicious of yet another form asking for their details.

Public services are not social networks. They don’t need a relationship. They need to answer a question, take a payment, or confirm a slot — and then get out of the way. The bus doesn’t need your email. The tip doesn’t need your marketing consent. The parking app doesn’t need your date of birth.

Keep the signal. Drop the noise. That’s the whole brief.