Redesigning the Bridj Traveler App
Bridj runs shuttles throughout cities that can quickly establish new routes to adapt to the area's transportation needs, complimenting it where demand is high or fill in gaps that exist in the public transit infrastructure. The traveler app was originally built to search for and purchase passes to ride Bridj, track your vehicle, and get directions to your stop, with a long term goal of eventually being able to dynamically create bus stops based on the aggregate of its booked riders. Some screens from the old app design can be seen below.
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. We wanted to improve on that system further by better catering each vehicle's trips to the riders final destination. Once the dynamic algorithm was built and ready to plug into the backend, we needed to be able to sell passes for a dynamically generated route. But since the system had to wait until every rider had boarded the vehicle in order to calculate the dynamic stop, an exact drop off location couldn't be presented to the riders during the purchasing flow or the beginning of the ride. This left us with two primary problems: How do we make users comfortable with purchasing a trip without the precise location of their drop off? And once they've purchased a trip, how do we make the trip experience from their origin to their destination comfortable and anxiety-free without the precise location of their drop off?
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.
Sketches: Given the size of our small team and my being the only designer, we had significant flexibility to rapidly iterate and test. I could quickly sketch flows and design concepts for immediate discussion and prototyping. Depending on the feature and complexity of the mechanisms being tested, more refined digital wireframes were pulled together for low fidelity prototyping in either Invision or a quick and dirty iOS app. More formal design reviews with the product team would soon follow to determine a concept's feasibility and garner additional feedback. 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.
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.
Another big change came in the means by which a user was informed on how to board their vehicle, as well as how it tied into the driver’s ability to quickly check each pass. In trying to streamline the entire Bridj experience during a prior design change, boarding instructions and a verification gif were combined into the main flow navigation, always visible alongside each other and ultimately detracting from each other. During the dynamic drop-off design process, I decided to divorce the two from each other due to their distinctly different purposes, resulting in a greatly improved experience for both customers and drivers.
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 (navigate through each stage of the trip by tapping the left or right sections of the screen. This is to simulate the screen transitions that would normally occur automatically upon arriving at certain trip checkpoints).
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.