A transit app for the rider who has three minutes

Why a transit app is hard

Transit apps get designed by people who are planning trips at a desk. Transit apps get used by riders who are standing on a platform in the rain with one hand free, a partially charged battery, and a toddler who wants to know when the bus is coming. Every design decision has to survive the second context, not the first.

The incumbent app had ten years of accumulated features, trip planning, fare purchase, route maps, service alerts, station amenities, accessibility info, lost and found, service commendations. All of those features are useful. None of them answer the question the rider on the platform is asking, which is “when is the next bus at this stop”.

What we learned from actually riding

Fieldwork matters more in civic design than anywhere else. We spent the first two weeks riding the system, at peak, off-peak, in the rain, in the dark, on the weekend. Some observations that made it into the design:

Riders do not launch the app until they are close to their stop. The app needs to assume “I’m near a stop right now” as the default state, not “I’m at home planning a trip”.

Riders check the app more than once per minute while waiting. Every launch needs to feel instant. The app cannot load a spinner. If we don’t have fresh data, we show the stale data with a “last updated” timestamp and fetch in the background.

Riders trust the arrival board at the stop more than the app, when there is one. The app needs to match the arrival board exactly, not calculate its own estimate. We rebuilt the backend to consume the same GTFS-RT feed the arrival boards use.

The home screen decision

The old home screen had thirteen interactive elements above the fold. The new home screen has three, the stop name, the three arrival times, and a “change stop” link. Everything else moved behind a tap.

This was the decision leadership pushed back on hardest. The concern was that moving features behind a tap would make them feel buried. We tested both versions in an A/B with 40,000 riders. The stripped-down home had higher engagement on every secondary feature the leadership was worried about. Simpler surfaces make secondary features more findable, not less.

Accessibility as a first-class concern

The old app had failed a WCAG audit in 2022. The contract required us to ship AA-compliant at launch, which we did. More interesting was what happened when we invested in accessibility beyond compliance.

The high-contrast mode, a single toggle in settings, shipped as an experiment. We expected accessibility-identified users to adopt it. What we did not expect was that 14% of daily active users would turn it on within the first month, including riders who did not self-identify as having a visual impairment. The mode turned out to be useful for riders in bright sunlight, on low-battery screens, and for riders over 55. Accessibility built in turned into usability for everyone.

Outcomes

On-time arrival rate, self-reported in the annual rider survey, improved 11% year over year. Telemetry confirmed the mechanism: riders were arriving at stops more accurately because the arrival times in the app were more trustworthy. App store rating climbed from 3.2 to 4.6 over six months. The agency commissioned a follow-on contract to redesign the fare purchase flow.

What I think about

Civic design has a bias toward comprehensive. Every agency wants their app to “do everything a rider could need”. The most useful civic tools I have worked on do one thing the user came for, correctly, every time. Everything else can be a tap away.