Redesigning the Bridj Traveler App

Bridj is a transportation company that runs a fleet of 14-person shuttles throughout cities to fill gaps that exist in the public transit infrastructure. Internally called “the traveler app,” this part of the product allows users to purchase passes to ride Bridj, track their  vehicle, and get directions to their stop. Though originally brought to market relying on set pick-up and drop-off stops for riders, Bridj’s long-term goal was always to dynamically create bus stops based on the aggregate of its booked riders in order to adapt to transportation needs at any given time.  Once this dynamic algorithm was built (after 2 years of ridership and a less-than-perfect third-party app) I was tasked with solving some of the major design challenges associated with that transition.

the challenge

The traveler app was initially designed as a platform to sell passes for transportation in urban areas along a predetermined route with unchanging pickup and dropoff stops. Once the dynamic algorithm was built and ready, passes would be sold for a dynamically generated route and the location and number of riders would determine this route, maximizing efficiency for all aboard. However, this posed an interesting design and user experience challenge.   Because the system had to wait until every rider had boarded the vehicle in order to calculate the stopping points, an exact drop-off location couldn't be presented to riders at their point of purchasing a pass, or even during the beginning of their ride. My main focus in this redesign was answering two questions: How might we make users comfortable purchasing a trip without providing them with the precise location of their drop-off? And once they've purchased a trip, how might we make the trip experience (from their origin to their destination) comfortable and anxiety-free without providing a precise location for their drop off?   

Modifying the Bridj traveler app for dynamic service - part of our company’s mission - required convincing the existing user base to place all of their trust in our “new” service model and minimizing anxiety associated with not immediately knowing a precise drop-off location. I approached the problem from all angles.  

APPROACH

Modifying the Bridj traveler app for dynamic service required building a great experience out of something that is inherently anxiety inducing. I needed to figure out how to erase the anxiety of not immediately knowing their precise drop-off stop, convincing the user to place all of their trust in our service.

Competitive Analysis: Bridj's value is similar to that of other ride-hailing transportation services such as Uber, Lyft, and Fasten: a faster, more comfortable alternative to public transportation that gets people to where they want to go. However it differs in that it doesn't function as a point-to-point service, with an emphasis on driving down costs and urban congestion with its shuttle-driven ride-sharing model. As a result, the service rests more between point-to-point ride hailing and conventional public transportation, which doesn’t require an app to utilize. Third party transit apps and general navigation apps (Google maps, Transit app, Apple maps, Waze, etc.) also proved useful during the research phase. These applications are built to guide users through a traveling experience they’re unfamiliar with, but none exist that achieved what Bridj was aiming to accomplish with a dynamic stop system. 

Qualitative Research: Based on two years of user observation aboard our vehicles, it was decided that a constantly updating visual of the trip route in the app would not be displayed. When providing service on the original unchanging routes, users were already keen to offer their own commentary on which routes they thought the shuttles should be taking. Since our data science team had already determined the most efficient routes through the city (and our dynamic routing system would soon be doing this on the fly in reaction to changing traffic patterns and user requests), displaying fluid route plans would only serve to contribute to users anxiety, confusion, and ultimately be of little value. I wanted users to relax during their trip and to engage only when notifying them of their impending stop. A common behavior in users of other ride sharing services is to compare their trip in progress with the fastest route on Google maps, due to a mistrust in the drivers and the extra amount charged as a result. Since the Bridj service charges a flat price for each trip (static and dynamic), this inclination to double-check routes is greatly minimized, and should hypothetically deter constant verification of the vehicle route.

Prototyping: Given the size of our nimble 9-person  team, I could quickly sketch flows and design concepts for immediate discussion and prototyping. I prefer to sketch first, and then, depending on the feature and complexity of the mechanisms being tested, create more refined digital wireframes  in either Invision or through working with a developer to create a quick and dirty iOS app.

• Map interface: Initially, my design direction leaned toward a map interface to navigate the entire trip, similar to other ride-sharing mobile apps. This lead to a fairly complicated and bloated UI as I tried to include all pieces of required information for every stage of the trip.

• Map-less interface: After a couple of design sprints and testing sessions, I decided to explore the concept of a map-less interface, the idea being that I may be able to distill the most salient information a rider needs without a detailed map to distract from the essential information. By providing a simple progress indicator during the ride (such as a slowly filling progress meter or subway stop styled graphic), a rider could absorb all of the information they need at a glance.

User Testing: Due to the unique nature of our new service, I wanted to get into a cycle of testing and iterating through rapid prototyping. In order to simulate the full trip experience, we scheduled a custom Bridj trip outside of primary service hours. We also recruited testers through the Applause testing platform due to difficulty getting reliable, consistent testers in the past. My latest prototype was sent to their phones as well as a simple test script that established the context of their usability case, at which point we ran through a full trip scenario which entailed: purchasing the trip in the app, navigating to the bus pick-up stop, boarding the bus, riding to the drop-off, and lastly walking to the final destination. I put together a survey that was then sent them to rate their comfort levels with different parts of the service, such as how they felt about not knowing their drop-off stop until all riders had been picked up.  I wanted to observe and question them during the test rides as one would during a normal 1-on-1 usability session, but didn't want to skew the results of the group test with our interruptions. As a result, I took a slightly different approach and asked testers to note their thoughts on paper or digitally as they performed the test, which would be collected later.

User Surveys: Testers were primarily surveyed about their comfort level with different parts of the mobile app without having exact drop-off stop information. The full survey can be found here. Early on, it became apparent that some testers wanted as little information presented to them as possible during their Bridj trip experience, even as first time users. The information being displayed about how the dynamic drop-off system worked, what potential stops existed, and which stops came before their custom stop were considered excessive and confusing. There were some who were less familiar with the city that were comforted by having access to a map, but much of the information being presented to "comfort" users actually ended up being disorienting. 

As I began to collect and analyze the data from each session, I was able to categorize and prioritize the remaining needs of our users based on the most prevalent feedback points. Since I expected to test several loose concepts during early prototyping, I tested a small group of individuals at first, honing in on the largest problems before tackling the smaller usability issues. Through several rounds of testing and iterating, I arrived at a much improved new design.

Visual Design: Due to time constraints and limited resources, the visual design changes to the app had been done in a patchwork fashion up until this point, leading to screens feeling disconnected from other parts of the app. Part of the visual design pass on this update was done to reestablish cohesiveness among every screen in the app for a consistent experience. Red is used to highlight primary CTA's while all other information rests upon white, using negative space to draw focus to the most important pieces of information needed at a glance. An Invision prototype can also be found here (Tap the left or right sections of the screen to simulate the automatic transitions that would normally occur at certain trip checkpoints).

IMPACT

Though this particular feature update is still in progress, I've already learned a great deal about improving the vehicle-boarding process for both riders and drivers, what information is most valuable to riders during their commute, how to visualize this information, and even how to improve other parts of the app: in exploring how we could reduce friction in the app to simplify the unfamiliar concept of dynamic drop-off, I was encouraged to dig deeper in pushing our one-tap trip search feature beyond the common saved-location conventions found in other travel apps. As we move forward, I'll continue to focus on providing concise, easily digested trip information while reducing anxiety associated with the somewhat nebulous nature of dynamically generated drop-off stops.