So trip planning to me is a process, not a tool. Stop Requested. This is Stop Requested. by ETA. I’m Christian.
And I’m Levi. These are real conversations with the innovators, operators, and advocates driving improvements in public transportation. Today, we’re talking about what it. takes to design transit technology around the full journey, not just the tool on the screen.
Our guest is Kristin Taylor, Senior Director of UX at the MBTA, and Chief Experience Officer for Transit Ops™. Kristin’s work focuses on making technology work for transit agencies, riders, and frontline teams, instead of forcing agencies to work around tools that only partially fit their needs. We’ talk about trip planning as a full experience, not just an app, and why accurate data, service alerts, audio announcements, signage, and staff communication all shape whether riders can trust the system. Here’s our conversation with Kristin Taylor.
Welcome back to Stop Requested. Today, we’re joined by Kristin Taylor, Chief Experience Officer for Transit Ops™, and Senior Director of UX at MBTA, in’ Boston. Kristin, how are you today? I’m good. Thanks.
Thanks for having me. Absolutely. This is really our pleasure. It’s gonna be a fun conversation. Uh, your, your work online has, you know, r- really strikes, uh, an interesting tone, and I’d like to dig into that more. But first, for those of our listeners who don’t know you, uh, and what you do at either MBTA or with your, uh, organization, Transit Ops™, can you introduce yourself? Yeah. Uh, so like Levi said, I’m Kristin Taylor. I am most interested in making sure technology works for transit agencies, instead of transit agencies, having to move around technology that only half works for them.
Um, and so to do that, I, you know, um, practice UX, I practice research, service design, and work with really talented technologists who understand technology’s capabilities so that transit agencies, f- primarily the MBTA, but in, through Transit
Ops, others, um, are able to have technology that supports them, uh, the transit agency needs, and the riders. So it’s, it is an interesting title, uh, UX.
Uh, so user experience. Um, you don’t typically see that at a transit agency. I, I, I’m curious how that came about, and what does that actually cover inside of a transit agency? It’s, it’s more of a, a technology position- Yeah … uh, at least in my experience.
Yeah. Yeah, it is. You’re correct. Um, so I was fortunate enough to join the MBTA’s customer technology department that works as like a product development team in-house.
Um, and so the team is comprised of engineers who build products, product managers who, you know, manage the roadmaps and help prioritize what goes on the roadmaps, and UX designers who do user research and design to make sure those products, you know, work in concert with the users themselves, and also solve the business problem. And so you’re right, there, I’ve never come across somebody with a senior director title of UX in any transit agency. There are some people who work as individual contributors who have backgrounds in
UX. Um, but I think it’s because the MBTA really invested in technology, because of that, needed somebody who can lead UX and make sure that team had the skillset to build products that work for people.
Well, you know, that’s, that’s an interesting background to the position and, and to that department. Uh, you know, interesting for you and your interests, which seems like civic design, you know, transit service design, um, you know, and also from the technology side. How, how did you find that nexus between all those topics? Where, where do you, where do you learn this and then, uh, kind of land in a role like
MBTA? Yeah. So unfortunately, I’ve always been a person who is, when I see a barrier, um, a lot of people go around it, and I’ve always asked like, “Why is that barrier there?” Um, and so that’s how I got into design as a practice. I’m not necessarily an interface designer, but really a systems designer, so understand what’s going on in the system, um, whether it’s people, process, policies, technology, or something else, uh, it could be culture, that drives, like pre- prevents us from achieving our goals. Um, so with that, you know, I started, I entered the internet age, um, where I could pick up designing websites and things like that for any kind of business.
But quickly learned about this growing field of civic technology or civic design that piqued my interest. And so I was fortunate enough to join a team in Austin, at the city of
Austin, that led civic design initiatives, meaning we tackled, um, different programs and policies and processes, um, not necessarily just the interface. It was like we would clean up how people got permitting or clean up how they accessed a service, meaning, um, make it more user friendly, and then make it digital, so put it on the internet so it was, you know, open and accessible for people. And so that was my foray into civic design and service design.
Um, during COVID, I had to take a little break from that, and my family was relocating to Massachusetts, and I was fortunate enough to land a position in transit. And so that’s how I got into transit tech at that point. Um, I used my skillset of service design and civic design in the role in transit tech, but I was really, it was like a fortunate accident that I moved to a place that had this team, and they were, were tackling these transit problems. And I’ve always been a transit lover. Um, I took transit as a kid to get around. I lived in New York City for nearly a decade. Uh, transit is like part of my life, and so it was super exciting to be able to apply my skillset to transit. And since then, I’ve really seen how much transit benefits from those tools that I bring to the table. That, that’s absolutely amazing how you just happened to land in Boston when, when you have this exact skill set that was gonna benefit them, um, in, in that department. It, it’s really incredible.
I love the backstory. So you also serve as the chief experience, officer at Transit Ops™. Uh, can you tell us exactly what that is and, you know, how, how that came about? Yeah. So, uh, Transit
Ops is a nonprofit formed by members who have worked in technology at the MBTA. Transit
Ops, um, grew out of this kind of thing we were seeing in the market where m- the MBTA, because we have this technology team that could build products, we also had these open values.
Um, you know, transit is, has a backbone now of open data, and we were building open products, which is called open source, so products that anybody could potentially use.
Um, but as we s- started talking about those products being open and available to everybody, we saw that other agencies didn’t have the technology skill set to even use the open products we have.
So the MBTA built a product for bus dispatch called Skate that’s open to any transit agency to use. It’s a basic view of where buses are in real time and helps dispatchers know, understand service as it’s happening. Any transit agency could use it, but we experienced that transit agencies were looking for help to establish those products in their ecosystem. So they, they were missing the technical skill set to even utilize open source. And so from that opportunity, Transit Ops™ grew.
It’s developed more in maturity, um, recently. Um, and I was able to join the team about two and a half years ago, so I’m, like, the last addition to that leadership team. Um, and we have a great group of people who work on making transit technology more accessible for agencies.
Kristen, that, that’s very impressive. And, and you guys have worked with assisting those agencies. And, and you see that, uh, you know, very often, uh, at transit agencies and the IT teams, is that a lot of people, and, you know, I hope those listening that might be the exception, don’t get mad at me.
But a lot of the folks, the, those IT professionals, they, sometimes they’re not, uh, transit people and, and they don’t even understand what options they have out there when it comes to technology. And then a lot of the transit professionals that are in operations or. in planning, they also don’t understand what are some of the possibilities and the options when it comes to technology. So the work that you guys are, are, are doing in, in finding that opportunity to, um, help agencies navigate those, uh, options of how they can enhance, uh, their, you know, the IT department and, and, you know, capitalize on. the opportunities out there, like what’s trending and what could enhance, more importantly, the riders’ experiences is paramount. I, I wanna ask you, you, you’ve written that a trip planner can work technically while the broader trip planning experience still breaks down. What do you mean by that? Yeah. Yeah. I, I con- the con- concept of trip planning to me. is not a digital tool, right? Mm-hmm. So we all know, I’ve … You know, if you imagine the last time you planned a trip, you don’t just focus on the tool, and then it’ outputs a trip, and you take it.
There’s things that happen along the way where you have to, like, you may arrive at the stop a little late and have to reroute yourself. You may choose to take another, um, trip throughout. You know, you might transfer to another line if you’re transferring at a s- a rail station or something like that. Mm-hmm. So trip planning to me is a process, not a tool. And if that tool doesn’t have the right data for it, and that data isn’t shared across channels, meaning digital signs or if it’s SMS or audio announcements, that experience breaks down. So a, a transit agency can’t just put out a trip planner and say, “Great, everybody can now, plan their trip.”
They have to make sure that data is accurate behind the scenes and that it’s consistent across the system so that people have confidence in their planning experience.
Um, yeah. And so the trip planner itself could work technically, but it won’t actually solve the problem that users need, or riders need to, um, take the system. Wow. I, I really like how you, described it because i- in essence, anybody traveling, y- you’re trip planning, right? Like, you’re trying to figure out the information and where do you start, where you go, a- and that is the process. Right now, now there’s tools that you can use for it that hopefully will help facilitate that process. And, and I think what’s paramount that you just mentioned is, is accurate information, like the, the real-time information. You know, because a lot of the times the, the experience breaks where they’re looking at things that is not accurate. Maybe there’s a detour, but, like, all the tools are not reflecting the detour, and now you’re waiting for a service that is never gonna show up. That’s the most aggravating thing, uh, a- as an user, right? Like, when, when your, expectation is not matching what is actually happening.
So where do riders feel often, uh, those gaps between the digital tools and the service information operation, um, a- a- and is different to what’s happening in the street? Uh, c- could you tell me a, a, a little bit more about that? Yeah. I think you hit the nail on, the head there, Christian. I think the
… I’ve done a lot of research with riders, and my team has, and the time that the breakdown happens, and these moments sit with our riders for a long time, is when there is a detour or. something that changes substantially in service, and the recovery of the agency is hard. Meaning they can’t just, it’s not just, like, um, you know, a bus that goes out of service, and you can replace it with another bus. It might be a rail, a c- train car that’s going out of service, and it’s preventing other train cars come, from coming through. So those major disruptions can leave riders stranded.
And what I’ve heard from riders is that they value quick and accurate information In the physical space that they’re in. Um, and so sometimes that’s through a digital tool, like a trip planner, but sometimes it’s through audio announcements or even a person being there to make sure, like a, a, somebody from operations or customer service being there, getting there in the moment to make sure people know, what’s happening and what they should do in, real time. You know, I, I think all transit professionals, it- it’s, sad sometimes, some transit professionals, they, they don’t ride transit or their own transit system. And I understand certain communities are not, like the transit system are, is not like the best choice to move around.
You know? Like the- there’s almost three times the travel time that if you were to drive. But I, I always encourage people to be a rider and wait at a stop, because when you wait at a stop, then, then now you can, um, you know, correlate with that rider that, that is experiencing that anxiety of being there waiting. Uh, so, so in your opinion, what does a better trip planning experience. require beyond just a better app for the rider, you know, to, to make sure that that experience is, is kinda like a good, a positive experience?
Yeah. Yeah, I mean, it, there’s some technical like usability things a trip planner can account for, like knowing where you are in location, knowing the history of your trips, or if you have favorites, like knowing what those are so it remembers you, right? It’s, personalized to you. Those are pretty important. But really where trip planning succeeds is. when transit agencies have control of their data, they know the data is accurate, and they put it in places where riders are. So they put it at the stops at the stations. Um, they put it in their hands in the app, right? Or on a website.
Ju- it doesn’t even have to be a mobile app, but somewhere that’s easy to find and that people can navigate to that information easily. The stops in a station are the easiest because they don’t have to wade through other data. You’ know, hopefully your signs and digital screens at stations prioritize rider, uh, infor- information for riders, like real-time data. If they don’t, that’s a place to improve. If we’re showing ads more frequently than real-time data, then I would suggest reconsidering that so that riders are getting the information that they need to make them confident and comfortable taking the transit service.
This episode is brought to you by ETA. Too many agencies are still operating critical transit systems on legacy software that is costly to maintain and difficult to evolve. ETA offers a clean break. As a fully web-based CAD/AVL platform, ETA replaces closed aging systems with an open architecture designed for real world operations.
It integrates with what you already have and delivers a clear map first command center your staff can trust on day one. Modern CAD/AVL without the baggage.
Visit etatransit.com. So
Kristen, Christian and I, we, we both worked at transit agencies and in our work at ETA, we’re heavily involved in technology, but the problems that transit agencies experience are not just the technological problems. Uh, a lot of it has to do with the people and the processes that they develop around using the technology. It, you know, for example, you know, no one is updating the GTFS, then you know, your riders are not going to know when a service change is or, you know, what’s, what’s happening in that particular service change. How, how can agencies ensure that they build the, the right people, the right processes and, and policies around the use. of technology so it, it benefits the, the riders of the system?
Yeah. I think this is a great question and, and if the, the agency had more capacity to bring in a service designer, I would recommend that, but I realize that that is not often a top priority, um, for an agency. What a service designer can do is look at the people process technology, policies, and even culture to help the agency achieve a goal. So my assumption is that they can’t do that specifically, but what they can do is figure out core problems that they need to solve, usually by focusing on either frontline staff or riders and rider experience. And in my experience, those two, if frontline staff is having exper- uh, challenges with doing their job, riders will have challenges accessing the service. Um, so really focus on the right problems and you do this by, you know, talking to people who have the lived experience of the thing.
Um, and then also, I would always recommend figuring out what you can cut down and simplify. Um, so I have a, a prime example of this. A lot of times is transit data, you brought up this example, Levi, is that transit data moves from one team to another, to another, and maybe another, and then it goes out into the hands of riders, right? So it starts as a schedule, then it maybe has a little disruption, and then that schedule isn’t accurate or, you know, there’s planned service changes and that schedule needs to be updated, and then it goes to real-time data, and then it goes out into the hands of riders.
And a lot of times we assume that we’re handing off the right thing to the next team. Um, and I think as people, we do this all the time. I’m like, “I’m gonna package it up and make it nice and kinda change these things and hand it over.” And then that next team has to like undo that thing. And so I have an article in my, uh, website about this, about like, you know, how to, um, remove processes from the, or steps from processes so that you can end up with like a smoother transition to the end result. And it does take conversations, right? You can’t avoid talking to people. You can’t avoid digging into process or questioning whether the policy is a good one or a bad one. Um, and so I think, yeah, if, if you can do those things, which I, I acknowledge they’re hard, that’s my full-time job- Um, then you can help the transit agency overcome the problems that technology won’t solve.
And I think the other thing to add here is I’ve seen a lot of people in transit assume that technology will solve these problems. And so before even looking at technology, figuring out if it’s a technology problem, a people problem, a policy problem, or a process problem, or a little bit of all of them, is better to slow down and ask yourself those questions as opposed to pursuing technology as a solution first, ’cause it’s not a magical answer. Yeah, I completely agree with that, Kristen.
Um, th- that to me seems spot on with what we hear from transit agencies all the time. Uh, you know, there, there are some assumptions that are made that technology will come in and it’s just going to be, you know, snap of the fingers and y- all of a sudden things are different. But that’s just not how it works, and that’s not how it works in your home. Why would that h- happen that way at work, you know? Uh, things are gradual and you have to kind of find the underlying causes before you just put a blanket solution out there like a, a, you know, technology, for example. Uh, ju- just to use some of the, uh, the vernacular from the technology world, would it benefit the agency to have some sort of designated product owner, uh, someone who kind of oversees the work of, you know, let’s just call it like GTFS, for example- Hmm … or a service change. Could you have that designated person? And maybe that’s the service design person. Yeah. I … Actually this is a really in- I’m working with an agency right now, who’s, who’s struggling with this w- same thing. Um, I did, uh, some interviews within that agency, and we were talking about their app specifically, but you know, as I said before, if you’re gonna have me look at an app, I’m also gonna look at your data, um, because I don’t think the app can, can stand alone in a transit context. And so I was talking to, you know, people in IT, people in customer service, people in operations, trying to figure out who their real time owner was. Who’s in charge of real time being accurate? And everybody said somebody else or said nobody, and really that was my key takeaway for that team, um, is that, that they need an owner to own the GTFS real time. They had schedule taken care of, and that, to me, that’s easier generally, is like making sure the schedule, GTFS schedule gets, you know, gets, uh, communicated.
Um, but when it comes to real time, there’s a lot of things that can go wrong, and it’s a more challenging problem. So having somebody who’s the owner is important there, but knowing that they can’t solve everything. It’s actually a very much a cross-functional problem. It relies on dispatch, operations, customer experience,
IT. All these teams need to be involved, but they do need somebody who can lead the charge. Um, and so if, if that is a strong recommendation to have a owner, whether it’s a product manager, whether it’s, you know, somebody else, um, I actually don’t care about the title that much. Yeah. It’s, it’s about the ownership, right? And, and, and actively being, uh, monitoring what, you know, the information that is being, uh, communicated to the public, right? Because GTFS real time, you know, having GTFS real time i- is the ability to actually have, um, the most accurate information for the riding public. And, and I see agencies, they’re like, “Oh, you know, I purchased, uh, GTFS RT from my vendor. Like, I have GTFS
RT, so my stuff is in real time.” And that sounds like on the surface okay, that’s good, but like when you have a detour or when you have accidents or when you have, do you do anything to use those tools to communicate immediately to the public and give them all the assistance that is needed for them to overcome that situation? Either, either make other, you know, planning, uh, for, for their trip and, and, and try to take a, a different service, or at least, I don’t know, like call an Uber if nothing’s gonna show up for them. But are you really using it owning up to, you know, your tools and the ability to communicate to the public?
And I, I think that’s definitely key. Uh, uh, you know, like there’s not just one person, but different people are participating on, you know, keeping the information the most accurate. Um, Kristen, I wanna, uh, ask you about something that, uh, you presented on, th- this idea, uh, that transit tech is civic tech. Mm-hmm. And you know, to me, I, like I don’t have the clear distinction in my mind. Uh, for me and for our listeners, could you tell us how does that, uh, differentiate and which one is which?
Yeah. Yeah. So transit tech, I think you all work in transit tech, Levi and Christian, a lot of other individuals work in transit tech. It’s really like the technology that runs a transit agency. So it’s not Microsoft, right? It’s the, your CAD/AVL system, it’s like you said, the GTFS, the trip planner, um, anything that makes the system run, I would call that transit tech, or enables the systems run or commu- us communicate about what the system is. I, this concept came out of me working in our technology department and really seeing a lack of understanding of how to center problems that the technology team tackles on users, right?
So there was a lot of assumptions or even like ego-driven priorities coming through, and so this was my way of saying, “Wait, halt. Transit tech is civic tech.” And I’ll tell you, when I think of civic tech, you s- the civic part has to do with people, right? The residents, the individuals, the people who live and breathe and use the service.
And so by focusing transit tech on civic tech, we, we put some power back into our rider’s hands or our frontline staff hand by doing research, by understanding their context, and making sure the things that technology tackles works for them and understands what they need. So that’s what I mean. It was a really in a response to me seeing some challenges of doing good technology work in my context at the time.
So, so i- it’s making it user-centric, right? Yes. It’s thinking about how they would use the technology and how the technology needs to work for them, versus like, okay, well, you know, we get this technology, and this technology does this and that, and then, uh, here, user, use it because, you know, this technology has the ability to give you, like to help you out.
But then it was just pushing to them versus, you know, thinking of them first to see if maybe we have to have multiple languages or like, you know, where, where, how, how can we make it accessible for them so they can actually benefit from it? Yeah. Is it too complicated to use? Or like, what’s their feedback, right- Mm-hmm … when they’ve been using it? Um, so- Yeah. Can I share an example about that one real quick?
Yeah, please, please. I would… That, that, that’s interesting. I think ’cause examples would be good. So, uh, many years ago, and, and this was like post-COVID where there was a lot of service that was being cut, right? Because we didn’t have… Many agencies didn’t have enough operators for their vehicles. So service was getting cut, and I think a lot of agencies then sent out what is called an alert. So this is like open text data that, um, you know, we send with our GTFS. It’s an alert, piece of, you know, a sentence or something, so it’s unstructured data. And we were seeing, uh, sending a lot of alerts, and at the MBTA, these were all SMS alerts, so then the cost went up because we were sending more of them, and they were going to people’s phones. And so what we, what I, I led was a team that, um, we led a group of people who tried to understand what riders needed from service alerts and what was challenging about it. And so we went and talked to many riders and said, “What do you understand from seeing the service alert in context?” So they saw it with a prediction, and they saw it with, um, you know, if you’re in, in Google Maps and planning a trip, you’ll see like a, a sentence or something that says,
“Trains are delayed by 20 minutes,” or, “Buses are delayed by 20 minutes.” And then you also see a prediction. Then we also went and talked to operators in dispatch and said, “Well, what happens in here when you have to send out an alert?” And they described it to us, um, and you know, we used some structured tools that a service designer might use there. And what we saw really was that the service alert creation in dispatch was initiated when there was one bus that had a headway longer than 15 minutes, ’cause that was what the planned headways were or something. You know, they had like, this is what our headways should be, and then if it exceeded that, they’d send out a service alert. But that service alert would go to everybody who was taking any bus or wanting any bus on that route.
Um, and so some people might, their bus might be on time, but then they’d also get that service alert- Hmm … that said, “Your bus is gonna be 20 minutes late.”
And so then they may be like, “Okay, I’m gonna sit at home a little longer ’cause everything’s late,” and then they’d miss their bus, right? So you see here we had a technology implementation and context change because of COVID. We have so many delays or so many dropped trips or whatever. That meant that the technology no longer served the need. And so then we decided to kind of structure our alert data in a way that we could cancel trips instead of send an alert, so now, you’ see canceled trips in GTFS real time.
Um, we decided that we would want to try to target an alert to a bus if possible instead of it be across the whole, um, line.
Um, and so that kind of research helps you understand where technology isn’t supporting both the operations and the user of the service. Uh, Kristen, earlier you mentioned that y- you know, some agencies will, they’ll, they’ll have some staff that kind of make assumptions that, you know, the technology comes in, and it’s gonna be a night and day difference. Um, and, and also you said that, you know, passing along some of the, the, the technological process, being able to, you know, go from one group to another group to another working group, uh, y- you know, balls can be dropped. Where do you see the, the silos forming? And I’m curious if you have any ways to be able to kind of tear those down and, and make sure that teams are communicating. Yeah. So
I, the, the way I focus this always is that, you know, getting designers, engineers, operations planners, customer service executives, whomever it might be, with a shared problem in plain language is key. Not a shared roadmap or a project plan, right? I think my goal is always to start with what is the shared problem?
And then if you get designers, engineers, operations planners, customer service, a clear understanding of what that is, they are smart people, they are creative, resourceful, and they know the tools at their disposal, and I can guarantee you, if you have a shared problem, not a roadmap, not a project plan, not a set of deliverables, that they can come up with the best way to solve that problem in their expertise. Um, and sharing the problem is actually a good way to build allyship, to build alignment, to help people feel like they’re on a team, um, that they’re all working towards the right, the same thing together instead of in competition with each other or despite each other. Yeah, I, I really love the way that you explained that. I’m, I’m curious though, how did, how are you able to tease that out of the group that you’re working with? You know, you’ve got so many people across the organization, and everyone has their own opinion about how something works, and then you have the executive who has the- Yeah
Has the final say. Uh, how do you get everybody on the same page? Yeah. It’s not easy or simple. Uh, I’ll give you a, a-
Specific example, I’ve worked with a paratransit at the MBTA. I love the paratransit team, I love the paratransit initiative, and they’ve also felt or often experience, like, a lack of technology support because it’s a pretty different, um, service to run in a large agency. I think in smaller agencies where you may do on demand, it’s, it’s more similar. But in a large agency, you know, on-demand service or, or individual service versus fixed route service is very different. Um, and the way I got those teams on the same page is, is, and we worked with operations, their customer service desk, executive leadership, and so on and so forth, is I always start with what’s called stakeholder interviews. So anybody who I feel like is gonna have a say in the project, I sit down with them and I ask them, you know, “What’s going on? What are your biggest challenges? Where do you see all the problems?” Um, and then my favorite tool is to get that group together and do what’s called a service blueprint, so a current state service blueprint where they can all advocate for their part in the process and tell you where it sucks, where they hate it, where they’re running into frustration, or where it breaks, or where they feel like they’re just doing a tedious job, and they share, uh, we share it in real time. You know, I have an artifact. Usually it’s like stickies on a big board. Sometimes it’s a digital whiteboard that we use, and we map out the process using a lens of like touch points, systems, pain points.
Um, somebody can share opportunities if they’re like, “If I could solve this, it would, it would save, um, my time,” right? And to me, that’s when you get people who are the people executing the service to kind of align on what is true and really see where there, are opportunities for technology to improve. And so in that instance, what we saw was that the teams managing paratransit were working with all kinds of tools that were not interoperable. And when I’ say interoperable, it means that they’re not talking to each other.
So when something’s interop- not interoperable, you have to copy and paste content from one system to another, and it’s tedious, right? It’s, it’s error prone, has all these challenges.
And so that was the biggest opportunity there, was to be like, oh, if we could get these systems to talk to each other, then it would solve your, your pain points and it would make a- service easier for riders. Um, and so nobody walked away and were like, “That was a stupid idea.”
They were like, “Oh my gosh, thank you. Please, let’s do that.” Um, and so it is a, a little bit of a political and an, um, political conversation, meaning talking to the stakeholders or the decision makers and making sure they’re heard, and then it’s also talking to the people who are delivering service and making sure they’re heard. And I think when you can do both of those, it’s pretty easy to see where the actual problem is. I really love that example. Uh, you know, it reminds me of something that we talk about at ETA quite a lot, which is, you know, how do we, how do we automate some of these manual steps? If we have a reoccurring item where we’re, like you said, copy-pasting from this to that, uh, how can we facilitate that so we’re, we don’t have to remember, oh, I need to copy this part, or I need to change this little thing over here.
Uh, that is very laborious, uh, as you mentioned, but, uh, as you said, a- again, you know, it’s error prone and humans are going to make mistakes, so you need to reduce that chance, that probability that people are going to miss something or copy something incorrectly.
Hmm. I, you know, just a, a last question on some of the, uh, kind of silos that, that we see building up in agencies.
Uh, how, how do you reduce complexity without necessarily adding another tool? I, I think, you know, I’m guilty of this. Like, sometimes
I’ll think, you know, this would be so much easier if we were to just buy X, and s- sometimes that’s not always the case. In fact, a lot of the times it’s not always the case. I’m going right to like, oh, let’s just get another thing and that’ll help, and that, that’s the problem that we’ve been talking about during the podcast here. Uh, but how, how do you reduce that complexity, um, wi- without just automatically, you know, grabbing another tool off the shelf? Yeah, I think that’s a really hard, uh, well, it depends on the context. So I’ll share the place where I think complexity shows up, and then where we have to do a lot of tool engineering to make it happen.
Um, and it might get a little political, but, like, fare policy is pretty complex in certain agencies. Some agencies it’s quite straightforward and simple. And to me, the complexity in that policy shows up in the rider’s experience, and it shows up in technology implementation. It makes technology very hard to implement. Um, it makes it cost more. It makes it prone to breaking, and then if you change one thing in the policy, it, like, has trickle-down effects. So Christine, uh, I, I really appreciate how you share your process for root cause analysis. And, you know, it, it, a lot of the times you hear at agencies and organizations, we always done it this way, and they never take the time to evaluate processes and, and find opportunities to trim things. Like you said, you know, even, even, um, you know, if it’s a fare policy or if it’s whatever process that is creating all these additional steps and complexity, and then nobody stops and says like,
“Do we have to continue doing it this way, or can we simplify this?” So those things sometimes is, is efficiencies through, uh, process versus necessarily buying or, you know, getting, uh, more technology.
Um, you know, Christine, it, it, we’re coming towards the end of our podcast episode, and we wanted to jump to one of our, uh, recurring segments, which is a quick fire segment. We’re gonna ask some very, you know, short, simple questions and, um, we hope you can answer kinda like with the first that comes to your mind. Are you ready for it? Yep,
I’m ready. Awesome. Bus or rail? Bus Okay. Love that. Uh, most, uh, most underrated, uh, part of the rider experience?
Um, audio announcements that have a screen equivalent. Ooh, I like that. I love the audio piece. I think it’s, you know, makes such a big difference when it comes to the rider experience. Uh, one transit technology mistake agencies should stop making? This one’s simple, and we’ve said it before, stop trying to solve a problem that you don’t know. So define the problem first or the need first.
Yes. I like that. Uh, favorite MBTA rider tool or feature? Um, tap to pay. Tap to pay. Oh, yeah. Making it easier for them.
Uh, one public service outside transit that transit should learn from? Energy. The energy industry. I think it’s one that has the same amount of touch points from people, right? We access our energy, our utilities all the time, and when electricity goes out, if you’ve ever lived through that, the communications are really clear. You know it’s affecting you and how.
Hmm. I like that. Uh, advice for someone who wants to work at the intersection of UX, civic tech, and transit?
Um, I would say understand transit data and operations process and how it impacts the service. Excellent. I really love all those answers, and you’re very enthusiastic about the bus. We’ve had several people who just, they’re like, “Bus all the way.” Yes. I’m like, “Oh, okay. All right,” you know?
I feel like bus, uh, bus always gets the bad rap, and my … The reason I say that, and I’ll take a second, is because my favorite way to experience a city is by riding a bus through it. Rail is great. It’s fast, and it’s, you know, kind of feels more reliable, but you’re underground- Hmm … often. Not all the time, but you’re often underground, and you don’t get to experience the city. Yeah. Th- that is true. Yeah, you lose the context of where you are, and if you’re not familiar with it, then a, a bus really puts you right in the middle of, of the city, being at service level. So, uh, you know, uh, great answers all around. Really appreciated those.
Uh, another recurring segment that we have, Kristen, is our key takeaway. So I wrote down quite a few, probably too many to even, uh, read off here, but, uh, you know, you tell me if I got anything wrong or if you would add anything.
Uh, so trip planning is a process, not a specific tool. That one’s beautiful. That’s a quotable. Uh, riders value quick and accurate information in the physical environment they’re already in, so that could be in the form of an app. It could be wayside signage. It could be a customer service employee.
Uh, the, all technology and the processes surrounding the use of that technology needs some sort of owner. Uh, transit tech is civic tech. I think that one’s very clear, but, you know, it should be focused on the end user, the community, and this, in the end, is a public benefit. And one thing I, I really like that you said is, before you start any project, you need to develop a shared problem and put that in plain language.
Uh, that was, th- that’s amazing, um, and I love the way that you stated it. Uh, then you also followed that up with a current state service blueprint. So y- if I understood you correctly, you’re advocating for your position and kind of arguing what could be better. Mm-hmm. Did I miss anything or say anything slightly off there that you would correct?
No. It’s beautiful. I think you said it better than I could have myself, Levi. Thank you. I di- I just restated it, so I don’t wanna take credit for it. Those are your ideas. Well, is there anything that we didn’t cover that you would, you’d like to, you know, leave our audience with? Yeah. One thing that I think is really important is, um, i- if you’re working in transit tech or not, but you rely on technology and work in a transit agency,
I think, um, looking at our history, right? So GTFS didn’t happen by accident. It happened because a transit agency. and a, uh, at, the time Google, a private company, worked together to develop a data standard, and from that, we were able to access OpenTripPlanner, which many transit agencies around the world use. And if that wouldn’t have happened, people. would be relying on homegrown transit data, right, not the standard data spec, and, they would be relying on a homegrown or, or some kind of vendor-built trip planner. And now, because of that, we have a little bit of a easier and more interoperable way to deliver transit information.
The same thing is happening now, with other types of transit data, and that is transit operations data, um, and things like that, so TODS is the data spec. And that, I believe, will open the fields for open source or more accessible tooling for operating service and make it so that transit technology can be, um, kind of more get back to its roots and be more supportive of the agency and the user. Uh, I know, our vendors are really important. They help us run the service, but I also think it’s important to kind of assess, like, where, we as transit agencies can work in collaboration to build tools that are shared across us. Um, so if one transit agency is building an alert CMS manager, we should share it with each other, um, and learn from each other. And that’s, you, know, we’ve talked a little bit about open source, and that’s, like, where I land in open source. Not the dogma, but really that it’s, like, shared learnings that you can apply across agencies. Our civic tech teams and government do that really well, and I would hope that as we grow and develop more open data, that we can also grow and develop shared tooling and shared resourcing about problems and technology across agencies. So I’m looking forward to, um, enabling that more through working at TR- with TRB, through working with other agencies, just to understand their context and their problems.
Very well said. Uh, really, you know, love your approach to, uh, you know, civic tech and that, uh, responsibility that you have as an agency to, uh, make sure that the public is benefiting from the service, that, you know, things are open and transparent. Uh, that’s right where my mind is as well. And I know you write online. Will you share your website and, and also where people can, you know, learn more about you and about Transit Ops™ and some of the other things that you’re involved in? Yeah. So you can find me at kristentaylor.io. It’s my website. Um, I post there periodically, and then, you can subscribe for free if you just want it, to, you know, anything I’ write to come to your inbox.
Um, and then, uh, you can also reach me at ktaylor@transitops™.co. Um, and I would love to know what’ you’re working on and how we can collaborate. Um, or if it’s something you’ve been trying to move the needle on and need support on also, please reach out. Um, and then transitops™.co is the Transit Ops™ website.
Uh, we recently launched a Pathways modeling tool that helps you model Pathways, GTFS Pathways from the desktop. Um, and that’s open source, so any transit agency, if you have a technology, team who can set it up, can use it. Um, and so, you know, look there to see what other inno-innovative things we’re doing in transit. And then if you need, you know, any kind of consulting support, you can reach out to us there too. Excellent. Well, thank you for sharing that, Kristen.
And, you know, thank you so much for being a guest on the podcast. This was really a pleasure speaking with you today and, you know, learning more about what you do, your background, what you’re working on with Transit Ops™. You’re, you’re definitely busy, but in, you know, in a good way. You have, um, I th-
I think are… You and Transit Ops™ are kind of trailblazing in the industry and really wanna make sure to highlight that. So thank you so much again for your time. Really appreciate it. And thank you to our listeners for tuning in to Stop Requested again this week. We’ll be back next Monday with another episode.