We keep investing in better trip planners, better apps, better predictions, better tools. And riders are still calling customer service, missing trips, or switching to Uber.
The problem isn't that our trip planners are bad. It's that we think of "trip planning" as a product. But when you actually map out the jobs riders are trying to do across their entire journey, trip planning isn't one thing. It's a series of connected jobs that need to work together across many channels and touchpoints.
Jobs to Be Done meets transit reality
If you're familiar with the Jobs to Be Done framework, you know that people don't want a trip planner, they want to get somewhere with confidence. The job isn't "use our app." It's "arrive on time without stress."
The problem is we've optimized for product outcomes (app downloads, feature usage, prediction accuracy) without designing for the rider outcome: completing the entire trip planning job successfully.
When you map the actual jobs across journey phases, you start to see the gaps. And the jobs look different depending on who's taking the trip.
Take two riders. The first is navigating an unfamiliar route:
The rider navigating an unfamiliar route needs to:
- Compare trips to find the best mode and route
- Decide on the route of the trip
- Decide when to start the trip
- Get to the right place to catch the vehicle
- Seek out alerts and updates
- Decide whether to change plans based on service
- Get information about an upcoming transfer
The second rider is on a familiar route, but something has gone wrong
The rider adjusting plans mid trip because of a disruption needs to:
- Seek out alerts and updates (from the moment they sense something is off)
- Decide whether to change plans based on service
- Get to the right place to catch their vehicle (which may now be somewhere different)
- Get information about an upcoming transfer they're now at risk of missing
- Orient themselves to a physical space they didn't expect to be in
These aren't the same job. The unfamiliar-route rider needs confidence and orientation from the start. The disrupted rider needs to recover a plan that was already working. But look at what both jobs have in common: alerts, service status, transfer information, and the ability to re-route. Those are the exact handoffs that break when systems don't share context.
Each job might be served by different touchpoints: trip planner app, website stops page, digital screens, PA announcements, real-time predictions, countdown clocks, vehicle screens, alerts, social media, call center. As TransitCenter notes, "Riders interact with these apps multiple times daily, making open data the most important customer communication channel agencies offer to the public."
Here's where it breaks
A rider checks the trip planner app the night before. Route 23, every 15 minutes, 35-minute trip. Good. Next morning, they show up at the stop. The countdown clock says "Route 23 - 8 minutes."
Twelve minutes later, still no bus. Clock still says "8 minutes." They check their app which shows the next bus in 3 minutes. They call customer service: "There was an incident, buses are running about 20 minutes behind." Your Twitter account posted about it half an hour ago.
Every single touchpoint technically worked. But the job chain broke because those touchpoints didn't share context.
Your bank would never do this
Check your balance on the mobile app: $1,247. Walk up to the ATM: $1,189. Log into the website: $1,305. Call customer service: "Which balance do you mean, available or current?"
You'd switch banks immediately. Because when different channels show different information about the same thing, you can't make decisions. You lose trust. You go elsewhere.
Banks solved this in the 1990s, not because they have better technology than transit agencies, but because inconsistent information makes their service both unusable and untrustworthy. One database. Real-time updates. Every channel shows the same numbers.
Transit has the same requirement. And TransitCenter's 2018 report The Data Transit Riders Want makes clear that data quality is inseparable from data infrastructure. Comprehensive and widely available data is only valuable if it is accurate, timely, and consistent across channels.
TransitCenter's research shows exactly what happens when we don't provide quality data: "Riders lose faith in real-time information and shift to other modes if they have one-too-many experiences where agency data say the bus will arrive in two minutes and it does not show up for ten."
The cost is real
Look at the quotes directly from riders: "I use different apps depending on what I'm doing. Trip planner for unfamiliar routes, and realtime app to decide when to leave my house and catch a bus." That's not a user choosing the best tool for the job. That's a user working around the fact that we built separate tools for jobs that are actually connected.
Or this one: "I feel forced into calling an Uber when my expected wait unexpectedly jumps up by 30 minutes." We invested in real-time predictions. We gave them the information. But the outcome failed because by the time they got that information, they couldn't adjust their plan anymore.
Mobility Lab's research found that inaccurate real-time information sparked frustration with transit among riders, and the consequences were concrete: some switched to other modes entirely, while others simply stopped trusting real-time information and stopped seeking it out.
Those aren't edge cases. They're the normal experience of riders who have learned to work around us. Every workaround, the second app, the Uber, is a data point telling us exactly where the job chain broke. We just haven't been reading it that way.
What actually needs to change
TransitCenter frames this as three interconnected problems, and each one maps directly onto where the job chain breaks for riders.
The first is data management and policy. Producing high-quality, publicly available data has to be a leadership priority, not a technical one. When it isn't, data infrastructure stagnates while everything built on top of it (apps, countdown clocks, predictions) drifts further out of alignment with each other.
The second is data quality. The same delay information needs to surface everywhere trip planning happens. It can't just be on Twitter or delivered to riders who opt into alerts. It has to be everywhere. When CAD/AVL knows about an incident, that context should flow to trip planners, countdown clocks, apps, the website, everything. TransitCenter puts it plainly: "Inaccurate GPS stop coordinates can cause frustration as a would-be rider watches their bus drive by as they scramble to find a stop they haven't visited before, a bad first impression rather than a warm welcome to transit."
The third is data specifications. Disruption information needs to appear where trip planning happens, not where we wish riders would look for it. GTFS was built for schedule data. GTFS-realtime extended it for vehicle locations and alerts. But the specification still has gaps: in-station routing, temporary service changes, last-mile connections. Those gaps are where jobs fail silently. Agencies and developers need to keep pushing these standards forward rather than treating today's spec as a ceiling.
And honestly, we need to recognize that operators announcing delays over the PA is part of the trip planning infrastructure. Often that's the most reliable real-time information riders get, because it's the only touchpoint that adapts to what's actually happening right now.
We keep trying to solve trip planning with better products. But the problem is we're designing products when we should be designing for a connected series of jobs that riders need to complete to get from A to B with confidence.
Good data builds trust, which builds ridership. Good data means accurate, present where people look for it, and structured to support the things they actually need to accomplish. Those aren't nice-to-haves. They're the condition under which every other investment we make in the rider experience either pays off or doesn't.