MBTA Bus Dispatch App

As principal designer, I acted as design lead to set direction, corral scope, and provide guidance inside and outside my project teams. I also worked directly as a UX designer in daily practice. In my role, I established innovative projects that improved the delivery of service while defining digital tools that better served 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. Yet, 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. The MBTA tasked us with solving problems and building internal and customer tools with modern, rider-centered approaches.
‍
In this role, I was embedded in two teams simultaneously.

‘Skate’ for Bus Dispatch

Building a Better Dispatch App

We have over 150 bus inspectors, 170+ bus lines, and over 1000 buses in our fleet at the T. Along with other bus officials, they make bus service happen.

Bus inspectors have among the most challenging 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 built for other uses — tools that work and are safe to use but are also pretty cumbersome.

In April 2019, MBTA CTD started building "Skate," a web-based dispatching tool for MBTA bus inspectors to use on off-the-shelf Android tablets (though commonly used on various devices, from personal phones to stationary desktops).

Where we Started

Once we realized we had this powerful data onboard a good number of our buses our Transit Data team began manually testing and observing APC data throughout service, ensuring accuracy and reliability on a number of important routes. For the most part, they did so by spot-checking security footage aboard vehicles to ensure that the count sent by the APCs matched reality.

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 in-depth interviews, the continuous input we received from bus supervisors, and feedback coming directly from our users via async chat within the application.

In this role, like others I've held, I enjoyed a close collaboration with our developers. It is not possible to build Skate without alignment on the complex chain of data sources that feed the application. 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. Still, it primarily provided a totally new tool to many inspectors who were essentially 'flying blind' without live vehicle tracking on the job.

Before, everyday riders had better apps on their phones to see where buses were than our inspectors did. But 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 was an enthusiastic partner throughout the design and build process. 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 confidently say that we aimed to improve the working lives of our staff as much as we wanted to improve the delivery of bus service.

Drawing our session pitch for TransportationCamp NYC 2019.

An inspector at Arborway using Skate on his tablet.

Although it looks slightly odd from a rider's perspective, a "ladder" is an excellent and familiar 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, aka "COOL."

This simplification is much handier for operations staff when managing a route over complex geography than a map of the route itself.

Each triangle represents a real bus in our system drawn beside its closest stop. The color-coding the staff established included:

• Early buses in red (AKA 'hot').

• Late buses in blue (AKA 'cold').

• On-time buses in green.

The thin line from the bus to the ladder shows where each bus should 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 counterintuitive. Still, 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 quickly swipe or scroll sideways as felt most natural to them.

Ladders for routes 111 and 57:

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 route organization:

Ghosts

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 we call a scheduled bus that gets dropped for various reasons (diverted to other work, flat tire, traffic, etc.). Thus, the 'secret' Pacman theme was inspired by the Pacman games' the ghosts and simplistic line/dot interface.

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 secret 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, 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 unique appearance and not simply another color, not only did it make some inspectors pleased to see, but it also genuinely helped them prioritize problems in the field.

The image below shows quite a few ghosts, which is not ideal for the real world. But a very haunted-looking screen may commonly occur during significant diversions where buses need to be borrowed to supplement a suspended subway line.

Mini-Schedules

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 primary duties is helping bus operators report for duty and sign into their vehicles on time. User interviews conducted by our user researcher showed inspectors' difficulties and their various workarounds for this problem.

To understand work shifts and 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).

Laborious manual annotations on paper sign-in sheet.

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 excellent visibility into what was happening right that moment with their vehicles, it didn't help them fully plan for the next bit of work. So we needed to find some way of getting that information into the application.

So far, Skate was primarily using data from our own department’s API, information that we controlled and had access to independently at CTD. The next step for Skate would require it to become more reliant upon other departments for their expertise and access more secure data about our crew schedules.

Above, you can see this data as it appears in its source in the Planning & Schedules Department. These details were the foundation of our schedule data. But it's not really meant for quick access or reading by an inspector standing next to a bus platform and orchestrating the movement of hundreds of people in the middle of a rush hour.

Below you can see the earlier 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.

V1 version of a vehicle properties panel

Enhanced version of the vehicle properties panel

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 making them something they could rely upon in the future.

In the image above, you can see the current trip for the current operator's work shift. 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 are a lot of job-specific terminologies here, these designs were highly 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***!”

Final Reflections

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 exciting success metrics is a pretty unexpected one (at least to me). An important feature of this in-house application is that it's also entirely open-source for other transit agencies. As a result, other cities like Washington DC and Baltimore have already begun integrating Skate into their bus operations, many bus rides away from where we started here in Boston.