Background
What is GTFS anyway? GTFS is the data standard powering many touchpoints a rider might have with the public transit system: trip planning apps like Google Maps, digital signages at bus stops, etc. Many agencies still maintain this data in Excel and email, or rely on vendors — which makes every service change slow, fragile, and expensive.
Before GTFS Publisher, Remix could ingest GTFS but couldn’t help planners edit or publish it. During COVID, with driver shortages and constant service changes, this gap became especially painful. Our question was: how might we help planners own their data and update their service data confidently, without turning Remix into another dense back‑office tool?
Super duper quick Transit Planning 101
Broadly speaking, there’re two types of transit planning: Strategic (long-term) and Service (short-term) planning.
- Strategic planners think in broad strokes: how the network should evolve in the next 3 to 5 years, which corridors and communities are under‑ or over‑served, and how to balance policy goals, budgets, and public input.
- Service planners live much closer to the calendar: translating those decisions into trips, blocks, and driver duties, and keeping everything running through holidays, detours, and last‑minute changes.
GTFS Publisher sits right between them, helping teams zoom out to see the shape of service and zoom in to make precise operational changes with confidence.
Rooted in research, built for wide impact
From the outset, I pushed back on requests for bespoke, one‑off solutions that wouldn’t scale beyond a single customer so we could serve many agencies, not just the first one in the door. Instead, I led multiple rounds of user research: from early concept tests to structured usability studies, all with agencies of different sizes and levels of technical maturity.
Through this work, we mapped the end‑to‑end GTFS workflow: how service changes are proposed, encoded, validated, and published; who touches the data; and where handoffs and errors occur. This research helped us define a product vision that met immediate customer needs while creating a flexible foundation for future features.
The challenge: design an integrated GTFS editing and publishing tool that fits naturally into Remix, scales across agencies of different sizes and sophistication, and meaningfully reduces the time and friction required to maintain accurate GTFS.
Design goals
- Fit GTFS editing into the existing Remix ecosystem seamlessly, not as a bolt‑on tool.
- Support both small agencies with limited GIS expertise and large agencies with complex service patterns.
- Reduce errors and time spent on validation by making problems visible, navigable, and fixable in context.
Introducing calendaring
Our first release focused on validating a new mental model for representing GTFS inside Remix: Service Periods, which describe weekly recurring service over a specific time range.
Rather than simply mirroring the GTFS service_id, we needed a concept that played well with Remix’s data model. That meant diving deep into both our own data structures and the GTFS schema. Interoperability is crucial when working with transit agencies — they rely on dozens of software and hardware vendors.
I led a series of design explorations on how Service Periods should fit into the existing product model (for example, could we extend our “scenarios” concept from Remix Streets?) and how they should show up in IA and navigation. I kept this work intentionally low‑fidelity so we could quickly stress‑test ideas against real GTFS from agencies across sizes and geographies.
- Data Model: The decision of how to integrate the concept of Service Periods was crucial to the architecture of this product, therefore it was crucial to stress test the the options with real GTFS data from agencies across sizes and geographies.
- Fitting into the product: Once we decided on the definiton of service periods, we started exploring how to integrate it into the existing remix product model.
- Navigation & IA: Explorations of how to navigate between service periods and get a quick sense of the overall service pattern.
After working with my team of engineers and PM, as well we testing with a few pilot customers, we moved quickly to introduce the core functionalities that enable a majority of small and midsize agencies to digitize their service and publish GTFS:
- A calendar view to assign services to specific dates
- A geometry editing mode for more precise and focused route edits
- A new project type dedicated to the service planning use case of GTFS publishing
Usability testing showed that planners responded well to the visual calendar model and integrated editing, but also surfaced a major gap: the timetable experience was too rigid and underpowered, which later informed a separate, large‑scale timetable modernization effort.
Expand to the full workflow
Our research showed that the hardest part wasn’t just entering data — it was maintaining it: handling holiday exceptions, understanding validation errors, and tracing issues back to specific trips and stops.
- Calendar‑based exceptions: Automatically surface oddballs like Sunday service on holidays and let planners adjust them visually.
- In‑context validation: Bring GTFS errors into the UI, then guide users to the exact route, trip, or stop to fix, instead of reading a cryptic text report. A modular, object-oriented solution that extends itself to catch new validation issues beyond this implementation.
- Stop list: A focused view for visualizing stop sequences and diagnosing routing problems, originally prototyped in a hackathon and later prioritized on the roadmap.
These changes turned validation from a dreaded, opaque step into a series of visible, fixable tasks.
Scaling to complex networks
Our first version of Service Periods worked well for smaller, stable networks. As we grew, larger agencies pushed against its limits.
- Because I had already documented the gaps to serving more complex networks and potential solutions during the MVP phase, the team already had a shared language for “what breaks” when service gets complex. When TML in Lisbon wanted to deepen their use of GTFS Publisher, we turned that into a co‑design opportunity.
In partnership with TML in Lisbon, we co‑designed the second generation of calendaring:
- Overlapping Service Periods to support complex service patterns.
- The ability to inspect and adjust service on specific dates.
- More robust handling of seasonal and school-term only variations.
This collaboration required deep immersion in TML’s organizational and emotional context: how planners communicate changes, who signs off on them, and how risk is managed. The result was a calendar system that differentiated Remix among competitors and brought us closer to being the source of truth for agencies of all sizes. This wasn’t just about adding features; it was about giving planners a calendar they could use to explain and defend service decisions to colleagues, leadership, and the public.
Wide-ranging impact
Business impact
- Securing one of the largest deals in Remix history through a statewide partnership with Caltrans and Cal‑ITP, onboarding over 70 agencies in California to manage and publish their service to riders.
- Essential in winning a national tender in Estonia; the entire country now uses Remix to manage and publish GTFS. 🎉
- Differentiated Remix in competitive evaluations by offering an integrated, visual, and flexible calendaring model.
User impact
For planners, GTFS Publisher replaced an error‑prone, vendor‑mediated process based on spreadsheet handoffs. With Remix:
- Service Planning now has full visibility and control over what data is live in the journey planner.
- Hundreds of legacy errors have been corrected.
- Planners can finally ensure correct schedules on public holidays and for seasonal or term‑only trips.
- Timetable changes can be scheduled with clear start and end dates, reducing back‑and‑forth with vendors.
“Since switching over to this process, we have been able to fix hundreds of legacy errors and have significantly improved the quality of Local Link data in the journey planner… and for the first time, we are now able to ensure that the correct schedules are showing for every route on public holidays, and that college term only or summer only trips are showing for the correct dates.” Planner at Transport for Ireland.
What makes the experience working on this spectrum of GTFS projects most meaningful for me was that public transit riders, especially the ones in rural areas or don’t own cars, can rely on accurate and timely public transit information on a variety of platforms.