MBTA Customer Technology
As principal designer, I act as design lead to set direction, corral scope, and provide guidance inside and outside of my project teams, and I also work directly as a UX designer in daily practice. In my role I've established innovative projects that have improved the delivery of service, while defining digital tools to better serve millions of riders navigating our transit system.
The MBTA possesses all the complexity and limitations one might expect of the nation's oldest transportation system. Surprisingly, within this large and occasionally challenging agency sits a relatively new and agile Customer Technology Department. CTD is a team of designers, engineers, content, and product specialists assembled like a tech startup within the agency. We're tasked with solving problems and building both internal and customer tools with modern, rider-centered approaches.
Currently, in this role I'm embedded in two agile project teams simultaneously.
Skate for Bus Dispatch
On the Bus Realtime team, I helped to design "Skate", a mobile application for field operations staff managing the movement of vehicles and operators.
Roles: Principal UX/UI Designer (current), Senior UX/UI Designer
Responsibilities: UX/UI, Research, Prototyping, Usability-Testing, Department-wide Design Standards
April 2018 - Present
SKATE, Bus Dispatch
Building a better dispatch app
At the T, we have over 150 bus inspectors, 170+ bus lines, and over 1000 buses in our fleet. Along with other bus officials they make bus service happen.
Bus inspectors have among the hardest jobs at the T because they have to coordinate vehicles in traffic, rather than over fixed rails. They're given the monumental task of helping maintain even spacing along their routes, and handling the nearly infinite variables that come with managing bus service for millions of riders.
A journey from analog to digital tools
Until recently, inspectors relied on paper and technology that was built for other uses — tools that work, and are safe to use, but are also pretty cumbersome.
In April of 2019, MBTA CTD started building "Skate", a web-based dispatching tool for MBTA bus inspectors to use on off-the-shelf Android tablets (though it is commonly used on a variety of devices, from personal phones to stationary desktops).
My role on Skate
The Skate team consists of:
- Myself, as UX designer
- A user research designer
- A project manager/owner
- Two software developers
Our user research designer, Maeg Keane, conducted our in-person field research and interviews with external staff. My role on the team was to design the application from scratch, provide QA for features in development, and collaborate with the product manager to define the roadmap and feature requirements. We had an excellent feedback channel for this project, allowing me to synthesize Maeg's feedback from her in-depth interviews, the continuous input we received from bus supervisors, as well as feedback coming directly from our users via async chat within the application.
In this role, like others I've held, I enjoyed close collaboration with our developers as well. It is not possible to build Skate without alignment on the complex chain of data sources that feed the application, and with engineering help and many subject matter experts across the organization, we were able to navigate many challenges to make it possible to connect vehicles physically on the road to their digital representation in the app.
Unlike my work on MBTA.com, this tool would replace some older software in the field, but it mostly provided a totally new tool to the many, many inspectors who were essentially 'flying blind' without live vehicle tracking on the job.
Where once riders had better apps than our inspectors to see where buses were, Skate brought this timely information to our staff.
Most importantly, we built Skate in close personal partnership with its users. Because of this we found incredible traction and adoption with this group. This is sometimes an under-appreciated workforce in the transit sector, and were enthusiastic partners throughout the design and build process to this day. Though their levels of technical savvy and individual workflows varied greatly, we saw massive engagement and vocal appreciation across the cohort. I'm proud to look at this work and say confidently that we aimed to improve the working lives of our staff as much as we wanted to improve the delivery of bus service.
Although it looks slightly odd from a rider's perspective, a "ladder" is a great way for operations staff to see the status of many bus routes at once. It's based upon a classic route visualization in which each "rung" on the ladder represents a major stop like Harvard’s Holyoke Gate or “HHGAT”, or my personal favorite, Coolidge Corner in Brookline or "COOL".
When managing a route over complex geography, this simplification is much more handy for operations staff than a map of the route itself.
Each triangle represents a real bus in our system drawn beside its closest stop. As befits the color-coding established by the staff themselves: early buses show up in red (AKA 'hot'), late buses in blue (AKA 'cold'), and on-time buses in green. The thin line stemming from the bus to the ladder shows where each bus ought to be based on the current schedule. Incoming buses (in a list on the bottom) represent the buses incoming onto the route from a different part of the system.
The vertical nature of the route ladder may seem counter intuitive, but it helps dispatch staff (many of whom are managing a dozen or more routes at once), see more routes on screen, and enables them to easily swipe or scroll sideways as felt most natural to them.
An early wireframe displaying the route as a two-lane road, rather than the classic ladder, was eliminated by staff in our user tests. Deemed too hard to scan quickly for vehicle positions, it also felt too foreign to their mental model of how routes are organized.
Having more experience myself building consumer apps rather than internal tools, I found my background building friendly, jovial interfaces did come in handy even for this tailor-made application.
Early on, while testing different color themes for the application, word had spread among inspectors that I had created a Pacman-themed route ladder for a bit of fun. The inspectors frequently deal with "ghost" buses, which is what we call a scheduled bus that gets dropped for various reasons (diverted to other work, flat tire, traffic, etc.). The 'secret' Pacman theme, was inspired by the presence of ghosts and the similar simplistic line/dot interface of the Pacman games.
I was worried that these decade-plus veterans of the service would, in my worst imaginings, misunderstand this to mean that I was making light of their work - which I respected a great deal.
The Pacman inspired theme for Skate's Route Ladders
Surprisingly the inspectors loved the idea. But while I couldn't bear to see those eye-searing 8-bit colors make their way into the final interface, the Pacman inspired ghosts stayed in by popular demand.
A ghost bus is worse than a late or early bus, because it can mean not only losing a trip, but an entire vehicle needed for consecutive shifts. By having ghost buses take on a special appearance and not simply another color, not only did it make some inspectors pleased to see, it also genuinely helped them prioritize problems in the field.
This screenshot shows quite a few ghosts, which is not ideal for the real world. But a very haunted-looking screen may commonly occur during big diversions where buses need to be borrowed to supplement a suspended subway line.
When we set out to include schedules in Skate we began with this main user story: “As an inspector I need to know how different drivers' shifts interlock if they are sharing a vehicle or a piece of work.”
“It’d be great to see the run of work, what they’re doing for the day. Whether they’re swinging on, pulling back, swinging off. And to see what run it’s connected to.”
One of an inspector's main duties is helping bus operators report for duty and sign into their vehicles on time. User interviews conducted by our user researcher showed the difficulties that inspectors had, and their various workarounds this problem.
To understand work shifts and also manage the available vehicles for drivers, some inspectors manually annotated their sign in sheet with the last few digits of the connected shift (aka runs).
This inspector has penciled in the numbers circled in green above on their sign-in sheet to help indicate to themselves who gets their bus next.
While Skate gave inspectors great visibility into what was happening right that moment with their vehicles, it didn't help them fully plan for the next bit of work happening in the near future. We needed to find some way of getting that information into the application.
So far, Skate was primarily using data from our own API, information that we controlled and had access to independently in our department. The next step for Skate would require it to become more reliant upon other departments for their expertise, and also access more protected data about our crew schedules. This was truly a black box for this team, so I did my best with our engineers to get acquainted with how this information was structured so that we could use it in our application.
What you see above is this data as it appears in its source in the Planning & Schedules Department. These details were the foundation of what forms our schedule data, but it's not really meant for quick access or reading by an inspector who might be standing next to a bus platform (and orchestrating the movement of hundreds of people the middle of a rush hour traffic jam).
This was the previous version of vehicle properties, a panel of vehicle information you could access by clicking on a vehicle anywhere within Skate. It contained only a snapshot of what was happening in real time, but not the bigger picture.
The enhanced version expanded that view to provide inspectors with all this new information we now had access to.
Getting cooperation and trust to do this work was essential. By building the rest of the Skate application in true collaboration with staff and their higher-ups, the field staff and other departments could see that we were serious about building them something they could rely upon in the future.
In the image above you can see the current trip for the current operator's shift of work. Above, those seven digit numbers like "123-1073" can quickly tell an inspector the upcoming work performed by someone new coming to the route. While there is a lot of job-specific terminology here, these designs were extremely well-received in testing.
In perhaps one of my favorite quotes from the project, an inspector being shown this new design exclaimed the following:
“But I’m loving this. I ain’t got to be carrying all this sh** under my arm, (gesturing to her piles of reference papers) I’m not trying to carry all this s***!”
At the start, Skate was just an innovative pilot that was probably never intended to last as long as it has. In the end, our team delivered quickly and thoughtfully enough that this tool has been adopted for daily use by the majority of our inspector staff. The tablets we distributed for this tool are even now considered part of an inspector's official uniform. It's relatively cheap to operate, and since it's a responsive web application, devices can be replaced or upgraded with almost anything with a cellular connection if they get damaged in the field.
While the metrics for how much Skate is improving service delivery are still being studied, one of the most interesting metrics of success is a pretty unexpected one (at least to me). A major feature of this in-house application is that it's also completely open source to other transit agencies. Other cities like Baltimore have already begun integrating Skate into their bus operations, many bus rides away from where we began here in Boston.