Your systems work. But do they work together?
Service design is frequently confused with customer service, branding, or UX design. It's related to all three, but it's not any of them. Service design is concerned with the end-to-end experience of a service: how it's delivered, not just how it looks or feels at any single touchpoint.
In transit, that means looking at the whole system: how a rider decides to take the trip, plans their route, pays their fare, navigates the physical environment, handles disruptions, and makes sense of what just happened when things go wrong. It means understanding not just the rider-facing interfaces, but the operational decisions, organizational boundaries, and technology integrations that shape what the rider actually encounters.
A service designer's job is to make the invisible visible: tracing how a rider's experience is actually produced, and identifying where the gaps are between what agencies intend to deliver and what riders experience.
"We kept improving individual pieces: the app, the signage, the customer service scripts. Ridership still wasn't moving. We weren't looking at the system. We were looking at the parts."
Why transit is a particularly difficult service to design
Most service industries are organized around a relatively contained customer journey. You buy a product, use it, return it if needed. Transit is different in a few important ways that make service design both more important and more difficult.
The delivery of transit service is distributed across departments that rarely coordinate around shared outcomes. Operations controls the vehicles and operators. IT owns the real-time data infrastructure. Communications manages alerts and passenger information. Planning shapes the network. Accessibility governs ADA compliance. Finance controls fare policy. Each of these functions affects the rider experience every day. But they're optimized independently, measured independently, and budgeted independently. No single department owns the experience of getting somewhere reliably. That job belongs to all of them, which means it effectively belongs to none of them.
The physical and digital are deeply intertwined. A rider's ability to understand their options depends simultaneously on signage, a mobile app, a real-time data feed, an operator announcement, and whether the vehicle is running on time. When the experience fails, it's rarely because one of those things broke in isolation. It's because they didn't work together when it mattered.
The stakes are higher than in consumer services. Riders aren't choosing transit the way they choose a restaurant. Many riders depend on transit to get to work, medical appointments, school. An unreliable or confusing experience isn't just a satisfaction problem. It's a barrier to access. For agencies with equity mandates, that's a mission failure, not just a service quality gap.
The measurement problem that makes this worse
Most transit agencies measure what they can easily count: on-time performance, complaint volumes, app downloads, satisfaction survey scores. These metrics are real and useful for some purposes. But they describe outputs, not outcomes. They tell you whether something happened (the train arrived, the app was downloaded, the survey was completed) without telling you whether the service is working for riders in the ways that would actually influence their decision to keep riding.
The problem with output metrics is that they can all look fine (on-time performance within target, app ratings acceptable, satisfaction scores holding steady) while the experience is still failing at the outcomes that matter. A trip planner can have strong ratings while being consistently wrong for riders with accessibility needs. On-time performance can meet targets while disruption communication is so poor that riders give up and drive instead.
Service design reframes the measurement question. Instead of asking "did we deliver the service?" it asks "can riders accomplish what they came here to accomplish?" Those are different questions, and they lead to different investments.
What a service design lens changes about technology decisions
Transit agencies are making substantial technology investments: fare payment modernization, real-time information platforms, trip planning applications, paratransit or on-demand management systems. The procurement processes for these investments are typically organized around feature compliance and technical integration requirements. They're rarely organized around rider outcomes.
The result is expensive technology that technically works. The API integrates, the data flows, the vendor met their contractual requirements. But it doesn't deliver the experience it was meant to deliver, often because the procurement process never clearly defined what that experience should be, whose job it was to produce it, or how you'd know whether it was working.
| Technology First Framing | Service Design Framing |
|---|---|
| Does this system integrate with out existing infrastructure? | Can a rider with limited Engish complete a fare transaction without assistance? |
| Does the vendor meet our technical requirements? | When a trip is disrupted, how quickly can a rider understand their alternatives? |
| How many features does the platform include? | Which rider jobs does this system support, and which does it leave unaddressed? |
| What are the uptime guarantees? | What happens to the rider experience when this system fails? |
This isn't an argument against technical due diligence. Integration requirements matter, uptime matters. But technical compliance is a floor, not a success condition. Service design gives you the additional frame for evaluating whether a technology investment will actually deliver on the rider experience outcomes you're trying to achieve.
Where service design sits in the organization
One of the more common questions I hear from transit leaders is where service design belongs organizationally. The answer depends on the agency, but the more useful question is: who has the mandate and the cross-departmental access to use it?
Service design methodology is most valuable when it can inform decisions across operations, technology, communications, and planning simultaneously. In practice, that means it needs to be located (or at minimum connected) where those decisions are made. CX leaders are natural candidates when they have genuine cross-departmental convening authority. Technology leaders can use it to organize roadmaps and procurement. Operations leaders can use it to make the case that their investments have measurable experience impacts. Planning leaders can use it to evaluate where experience investments complement traditional service expansion.
The organizational location matters less than the practice: systematic research into what riders are actually trying to accomplish, a shared framework for connecting those outcomes to investments across departments, and measurement that tracks whether those investments worked.
That practice doesn't require a special org chart. It requires a different way of framing the problem, and leaders at any level of a transit agency can start using it.
Kristin Taylor is a service design and UX research leader with experience building and applying this methodology inside one of North America's most complex transit systems. Her work focuses on rider outcomes mapping, technology roadmapping, and outcomes-based measurement.