MBTA - In Station Communication

Product design from discovery through implementation

Project Introduction

At the MBTA, I redesigned the application that enabled employees to communicate with riders at subway stations via the public address and digital visual messaging systems.

What user problem did this project solve?

As a UX Designer, I focused on improving the experience for two user groups: MBTA staff (Operation Information Officers, or OIOs) and MBTA riders.

It is the OIO's job to communicate service - including any disruptions to service - to riders

For the OIOs, our goal was to design a more integrated and streamlined UI for communicating service disruptions.

For riders, our goal was to deliver more accurate, timely service disruption messages more often by improving the user experience for the OIOs.

What business problem did this project solve?

From a business perspective, a major project goal was to enable the MBTA to save a significant amount of money. The existing communication application was proprietary third-party software that the MBTA could not update. Rebuilding the functionality into an application that the MBTA could fully control enabled the MBTA to affordably and competitively bid for other parts of the in-station software and hardware, including new digital screens.

Design Approach

As a designer, I took this project from discovery research through implementation.

Discovery

A main discovery method for this project was contextual inquiry, which consists of carefully observing a user in their environment.

I find contextual inquiry indispensable for learning what users may not tell you during interviews. The OIOs work in the MBTA's Rail Operations Control Center (OCC) - a dark room dominated by a large screen displaying the current state of rail service on the Red, Blue, Orange, and Green lines. The OCC is where dispatchers and their supervisors manage rail service, making sure it runs as smoothly as possible, and the OIOs communicate that service to riders. The environment can at times be noisy and chaotic, as OIOs overhear important service information from dispatchers, field phone calls, and manage multiple applications.

The MBTA Rail Operational Control Center where the OIOs work

Among the key discovery research findings were:

OIOs had to duplicate actions across applications to communicate the same service disruptions to riders across MBTA touchpoints.
OIOs were not able to preview service disruption messaging on digital screens before they posted it to riders
The system to create service disruption messages across all rider touchpoints was slow, labor-intensive, and error-prone.

I shared these findings with stakeholders via a presentation. I also created detailed experience maps of how OIOs currently operate, which were invaluable for identifying their pain points and developing a long-term strategy to improve their workflow.

Experience Map of how planned subway service dispuptions are handled. I also created experience maps for the handling of unplanned service disruptions, and delays.

Ideation

Based on the discovery work, I created low-fidelity wireframes of new workflows and UIs which I concept tested, with the OIOs and prioritized what we should focus on.

I used the same wireframes to review and brainstorm possible easier solutions with the engineers and the Product Manager.

Low fidelity wireframes of workflows and UI that I concept tested with the OIOs

Refinement: Prototyping and Usability Testing

Once we had a focus on what areas we wanted to improve for the MVP, and a rough idea of the approach we would take to get there, I refined and tested those concepts by creating prototypes and conducting multiple rounds of usability testing with the OIOs.

Results and notes from conducting usability testing on a prototype

Visual Design & Delivery

For delivery, I closely partnered with engineers, creating detailed specifications of functionality, reviewed final visual designs, held impromptu meetings as needed, and provided feedback on implementation during QA.

A sample of the final visual design

Design System

Summary

For this project, I created a design system in Figma that defined colors, text, components, and page layout, working from the principles of layout in Atomic Design.

Deep dive

From my experience working at organizations with strong design systems in Figma, I know how much design time it saves to have a solid design system in place with components that can be assembled like building blocks.

At the MBTA, a patchwork of design systems and frontend frameworks was in use. At the start of my time at the MBTA, the lead engineer on my team and I evaluated multiple frontend frameworks to use going forward. Some of these frameworks included Figma design systems; some didn’t.

Together, we decided to use Bootstrap as the frontend framework, because Bootstrap was the framework most teams in the MBTA’s Technology and Innovation Department used. In addition, some of the other frontend frameworks we were exploring would cost extra money.

A downside to using Bootstrap is that, unlike some other frameworks, it doesn’t offer an official Figma component library. There are free Figma Bootstrap libraries that community-minded designers have shared online, but they weren’t as easy to use or modify as some of the other front-end frameworks we explored.

This meant that, from a design perspective, quite a bit of work was needed to either modify Figma components from free component libraries or create them from scratch.

To give a specific example of a Bootstrap limitation: The OIOs work in a dark environment, and they much preferred dark mode applications so they wouldn’t strain their eyes. At the time the project was implemented, Bootstrap didn’t have a dark mode. To create dark mode for the Figma components, I used the newly released variables feature to convert components from light to dark mode.