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 teams simultaneously.

RIDER TOOLS ON MBTA.COM

On the Rider Tools team (aka Dotcom), I lead the design of MBTA's public website. Rider tools comprise the most popular features of MBTA.com, such as trip planning, interactive schedules, and realtime information. Though also a part of the website, I am less involved with our CMS content like projects, news, and static information.

Roles: Principal UX/UI Designer (current), Senior UX/UI Designer
Responsibilities: UX/UI, Research, Prototyping, Usability-Testing, Department-wide Design Standards

January 2018 - Present

Tools

Sketch
Illustrator
InVision
Zeroheight
Abstract
Zeplin
FullStory
Userlytics

MBTA.com

2015

In 2015, an unrelenting series of blizzards brought the city's transportation system to a halt. In the aftermath, the state decided to reinvest in the entire system, and identified its outdated website as an area of focus for immediate improvement.

The effort to make this mobile-unfriendly, inaccessible website meet modern web standards was the first major project under the nascent Customer Technology Department.

2018 - present day

I joined the team and inherited the project in January 2018 after the beta website was launched (in 2017).

The 'Rider Tools' team for mbta.com now typically consists of:

  • Myself, as UX Designer
  • A Project Manager
  • 2-4 Software Developers

The website is also supported by a team of 2-4 content writers as well, but they operate within their own roadmap and have a dedicated Drupal developer to separately maintain and develop their CMS.



Homepage CURRENT

This is the current version of MBTA's homepage at time of writing. It shows a culmination of improvements I led across navigability, search, content strategy, and optimizations based on user behavior.

It takes inspiration from the original feature-set provided in 2015, while enhancing the information architecture, UI and functionality on a greater diversity of devices. From the early, totally static and difficult to update website, to this dynamic set of rider tools-- this website, like the historic MBTA system itself, has come a long way.

Homepage 2017

This was what MBTA.com looked like before I joined the project. While the new team had made improvements to the website's responsiveness, there was little sense of priority on the new beta site. It was visually underwhelming (a common complaint among the early beta testers), but more concerningly, it proved itself to be quite cumbersome to navigate.

From here is where I joined the web team to perform an audit and complete the original vision of the CTD team. While the frontend may have felt like a step backwards to users at the time, even this more limited beta website was powered by major improvements to the MBTA's transit data, courtesy of this young department.

Homepage 2015

Following a record-breaking blizzard in 2015, the Customer Technology Department was formed to first tackle the redesign of the old website shown here.

Notable issues on this pre-CTD website were the lack of mobile responsiveness, cluttered and outdated interface, and inaccessible markup. However, this website was well-beloved over the years by its longtime users in terms of functionality, and therefore set a helpful foundation of comparison for subsequent redesigns.

REDESIGNING SCHEDULES

HOW BIAS MAKES PEOPLE LATE

In April of 2018, I initiated a long redesign effort to improve the public schedules on our website. Below, I'll describe some of the context for this extensive project, but if you prefer you may:

The redesigned bus schedule page




What is a schedule?

It may come as no surprise that one of the most popular features of MBTA.com is our public-facing schedules. The definition for a 'schedule' depends on who you ask, however:

Generally speaking, a schedule can be thought of as "what ought to happen" in the system.


Internal vs Public Schedules

Operationally, the organization thinks of a schedule in terms of people and vehicles. But the public doesn't care quite who will drive their vehicle so much as when it will show up.

Unfortunately for us, much of the data that undergirds our schedules looks like this:

The Rectigraph

This 'rectigraph' shows how vehicle operators (the run) and their vehicles (the block) intertwine to conduct successive, continuous trips that form the schedule for every route in the system. At peak, thats over 800 vehicles at a time plus many more operators as they trade off shifts throughout the day.

As you can probably tell, the rectigraph is not suited to being a public-facing artifact, but it's fundamental to how we've run our service the last century. In fact, the name itself comes from the name of an early version of the photocopy machine (this information is still distributed in paper form by operations staff across the T).

It was intended to help manage shifts, not purpose-built for public consumption.



The Paper Schedule

The MBTA does publish public schedules, but like the rectigraph, they have also not changed much in the last 100 years. Most people in the area would recognize the paper version of schedules shown below. It's a time-tested design used by many, but truly ill-suited for reading on a mobile phone or by a screenreader. They are still updated manually as hundreds of separate design assets, printed en masse.



Public schedules, the last decade

In the last 10 years, schedules have changed dramatically in nature. A rider's concept of "what ought to happen" is no longer informed by printed matter, but by newer digital countdown clocks, websites like mbta.com, and applications like Google Maps, and other transit apps. And while many of these things are technically "predictions" and not "schedules" – to a rider they are still expectations that we either meet or fail.

What does bias have to do with a schedule/timetable?

I've titled this case study "How bias makes you late". But what does bias have to do with a timetable? Shouldn't a schedule, just a list of times and stops, be a perfectly rational thing?

When I joined the T, if you were a bus rider, your method of transportation was only 69% reliable.


Compared to Subway at 89% reliable, and Commuter Rail at 91%, there were major discrepancies in service delivery. When service is very unreliable (as in, it rarely adheres to what was promised on those paper schedules), riders then need accurate realtime information, especially if their ride is late or worse - not coming at all. Poor reliability, and inaccurate, hard-to-find realtime information spelled awful experiences for bus riders across the system.

What's worse, these riders tend to be more likely to be our most vulnerable populations and the most transit-dependent. Bus riders are more likely than others to be women, elderly, and lower income (or all three), than any of the other riders in the system. They also accounted for our second-largest riding population overall. The combination of these factors can create biased experiences, whether intentional or not.

The Commuter Bias

Shortly after I joined the team, one of the first things I asked to do was perform an audit of the website by feature and mode. I wanted to see how customers may be differently impacted in their experiences on our website as well. Much of what I found reflected that disparity from the real world:

Average

Commuter Rail

Bus

Clicks per session

11

26

Session length

00:32

01:08

Bus riders not only had worse service, but it was also taking them twice as long to find schedule information as Commuter Rail Riders, averaging over two dozen clicks each time. I observed all kinds of troubling trends through a combination of reviewing passive, anonymous session recordings in FullStory, as well as quantitative observations collected in Google Analytics.

Part of what drove the UX discrepancy was that much of the early stakeholders and creators of the website were Commuter Rail riders. Consequently, those members of the team and many of their stakeholders largely believed the schedule work to be "done" from a product perspective. They had already invested two years into the schedules on the beta site, and felt it worked well (and it did - for them). It was difficult, but I set off to challenge that perception with my own research which I presented to my team/stakeholders in April of 2018.

Here are just a few examples of what I originally identified, and how we ultimately addressed that iteratively over the last year plus.

Comparing experiences by modes of transit

While Commuter Rail riders typically landed on a page that immediately displayed train times to them, bus riders were presented long pages of text, with no "times" on screen. If you wanted to know when to expect a bus, you had to dig deeper.

Commuter Rail Timetable (OLD)

Bus Schedule Page (OLD)

EXAMPLE 1 Live predictions

With so many visitors arriving organically by Googling their bus route at really any stage of travel, we didn't have much time to orient users on the website. Just as it worked for the Commuter Rail users, it was important for bus riders in transit to see predicted departures immediately, without additional clicks.

Bus stops are notoriously unremarkable in the real world - often no more than a metal pole by the sidewalk. Having predictions available on the website in this format could potentially put a countdown clock (just like the ones we have at our major stations) in the hands of anyone waiting at a bus stop.

The updated stop card showing live predictions:

Bus schedule page (OLD)



Bus schedule page with redesigned stop cards in context

EXAMPLE 2 Picking a direction

To get a schedule, you need to indicate a direction of travel. For train service running over fixed steel rails, directions are simple and binary, such as heading either north or south.

Bus service, however, is a totally different beast. A single bus route can have trips that service close to a dozen different combinations of stops. Buses on the road can switch up throughout the day by skipping or adding stops, even changing into a completely different bus mid-route. This convolution certainly complicates our backend data, but unchecked in the frontend it created a major usability issue.

A bus route should be a simple circuit, but its more often like a loose collection of spiderwebs.

Picking a direction on the old website

Let's take a look at this example from the old beta website. Route 39 typically goes from Back Bay to Forest Hills, but a small handful of trips operate a little differently along the route. If a visitor to the website wanted to get a schedule for buses going to Forest Hills, this was the multi-part control they had to interact with.

Step 1:
First they were prompted to choose a direction.
In this case, that means clicking to switch from inbound towards the city center to outbound towards Forest Hills.

Step 2:
Below the direction control, they were then prompted to choose a "Route Variation" from a pop-up.

These confusingly similar options presented an impossible choice: which Forest Hills are you going to?

Considering that this is one of the most popular routes in the system, and over half our routes had similar boggling variations - the website ultimately confused many of its bus-riding visitors.

The problem was that for these trips we had no useful data to make them distinguishable. Buses belonging to the same route and headed to the same destination each had the same name, even if they started from two completely different towns.


Redesign

Unfortunately, as a designer not a service planner I couldn't address the root problem: complicated bus service. But I knew that we could help riders avoid unnecessary and confusing choices like this one. Most were unlikely to get on these rare variant buses, yet we were presenting each and every user of bus schedules with the same confusing inputs and options with each visit.

The updated direction input



Now, uncommon trips have been demoted to an "Uncommon destinations" submenu, and the most typical route patterns are selected automatically, greatly reducing unnecessary decision-making.

Descriptive labels in the menu like "Early mornings only" were borrowed from paper schedule information and provide uniformity where we talk about schedules.



Working with our Transit Data team (among other things, they condense our many data sources into our public API), I helped to establish product and design goals that led to new and better ways of describing routes. This new "route pattern" data sat below the hierarchy of the route itself (e.g. Route 39), but above the level of individual trips. With this, my team was able to help distinguish these variant trips from one another, and both explain and prioritize them for users as was sorely needed.


Process

Adding this new data for over 170 bus routes was no small ask to external teams. To accomplish this, I looked to precedents set with our paper schedules; spoke with subject matter experts across Wayfinding, Planning, and Maps; highlighted our most egregious friction points to our team; cited examples drawn from difficult recorded user sessions; and drew upon relevant customer complaints to provide more than enough for both the justification and the direction that led me to this final design.

The subsequent designs were also iterated upon and user-tested via remote usability testing ahead of development, as well as with passive data collection after the feature was launched.

EXAMPLE 3 Choosing a time period

The last piece of information you need to pull up a schedule is the time period that you want to view.

On the old website, choosing a time to view a schedule involved interacting with a large calendar picker, triggered from a button labeled "Schedule for: Today".

For our schedules, Wednesday really shouldn't look that different from Tuesday. While trips based on calendar dates are easy for a computer to fetch from a data endpoint, the simplicity on the technological side comes at the expense of the human side of things.

The implementation I settled upon to address this was deceptively straightforward. Just a standard dropdown containing just a few items: the Weekday schedule, Weekend schedules, and schedules for upcoming holidays.



Before

The over-large calendar picker on the old website was not accessible. A user with good vision may find a calendar easy to use within a couple clicks; but for a user on a screenreader, a poorly implemented calendar picker can be upwards of 30 elements to announce and traverse.

After

The updated schedules replace the calendar with a far simpler dropdown. While hardly beautiful (though it is, in a way, to me), it's much easier to understand and traverse a list of three items on a screenreader than a complex custom calendar component.

Why not use a calendar to pick a date? Ultimately, a real schedule ought to be a repeatable and predictable set of events, not unique to a single day.

Process

Perhaps one of the most important parts of this shift in how we displayed schedules is persistence. Design without execution is not much more than a wish or an intention. Despite the fact that paper schedules have always divided trips by 'Weekday', 'Saturday' and 'Sunday' schedules, to accomplish the simplicity of what I've shown above required serious persistence and cross-team communication.

For example, the an early iteration of this feature looked like this:



If you recall the rectigraph from earlier, the reality of operating a transit system produces some pretty ugly data. And to squash that data into shape in order to simplify it for our riders took a lot of effort.

Here's a snapshot of what that effort sometimes looked like: a combination of persistence, insistence, and asking for help along the way.



Final thoughts

It's no secret that every transit system has its shortcomings. My great pleasure in having done this work for Dotcom is certainly not for the praise. Anyone who follows the MBTA's official Twitter account knows: congratulations is not coming. But wrestling with these challenges is worth it, given how vital this service is to my city. It makes me proud to tough it out and make even small improvements every day. Not every project is a big sweeping redesign of something essential to the website like schedules - sometimes it's enabling small corrections about bike rack locations, or putting a lost and found number somewhere someone might find it a bit easier.

Overall, the existence of digital schedule information and public realtime data is relatively new for the T, and its bringing opportunities to think and drive the direction for much more than the website, also playing into how the organization thinks about its public communications and service delivery changes as well. Whether my work has had a direct impact on that in part or not, it's been some of my proudest work and I look forward to more challenges to come.