Product Designer
onetaptripsearchthumbnail.png

One Tap Trip Search

Simplifying the Bridj experience for our regular users.

One Tap Trip Search

PROBLEM

Like many transportation apps, Bridj’s primary method of inputting a user’s starting point and destination entailed dragging pins on a map or typing in the origin and destination locations.  This was a frustrating and superfluous experience for anyone that used the service somewhat regularly though. Since Bridj is primarily used as a commuting service in the morning and evening, people commonly use it to get between the same home and work addresses everyday.

Additionally, once users learned how to use Bridj and where the pick-up stops were, many would drag their origin and destination pins to the general areas that they knew their regular stops to be. This was a somewhat reliable method of users adapting to quickly request a trip, but lead to a couple of problems. Occasionally this approach would result in users accidentally getting an incorrect trip at stops near their normally requested ones, which in some cases lead to them boarding a vehicle that wasn’t heading near their desired destination. Furthermore, this skewed our own data on our users' travel patterns, making it difficult to generate data-driven changes to our service. 

Original trip search screen. Setting your origin.

Original trip search screen. Setting your origin.

Setting your destination.

Setting your destination.

Select a trip to purchase.

Select a trip to purchase.


APPROACH

User Surveys/Interviews: Before tackling this problem, I surveyed users at our stops as they waited for their vehicles to pick them up, as well as online with questions about our app and service overall. One of the dominant points of feedback was the desire to be able to save their home and work addresses. 

Competitive Analysis: Many navigation and taxi service apps incorporate saved work and home addresses into their interfaces, such as Google Maps, Transit App, Apple Maps, Uber, Lyft, and more. Each of these had some variation on saving a home and work address for future use, but still entailed tapping the address field, selecting the preset, and confirming the request before progressing. Given our hypothesis that users were regularly traveling between the same locations every day, I wanted to explore expediting the trip request process even further.

Data Analytics: By digging into our riders travel patterns through Localytics, it was found that about 80% of the time users were definitely traveling between their home and work places, and 90% of the time users were traveling between their current location and their destination, regardless of whether it was during their morning or evening commute. This distinction between current location and home/work address is important because a user's current location booking was still within a block of their home or work locations, further solidifying our hypothesis on users travel habits and needs. I needed to be sure that a large portion of our user base wasn't regularly planning trips miles away from their assumed work/home locations, leading my redesign to erroneously alienate a substantial portion of our user base. 

Sketches: With such consistent travel patterns found in our users, I began to explore designs beyond that of the typical saved address conventions (where the locations appear in a dropdown above the user’s travel history). I believed that the experience could be simplified even further, down to a one or two button trip search experience, bypassing the multiple taps involved with the original experience.

Sketching and brainstorming different interfaces and interactions. 

Sketching and brainstorming different interfaces and interactions. 

Early concept flow of the app predicting your origin & destination without a map element present.

Early concept flow of the app predicting your origin & destination without a map element present.

Sketch of what would come to be the final design to start the trip search flow.

Sketch of what would come to be the final design to start the trip search flow.


Wireframes: After sketching and evaluating different options, I put together low fidelity wireframes to get a better grasp on each concept's screen composition and button accessibility. Below are some examples of the different approaches.

Wireframe pop-up to select destination.

Wireframe pop-up to select destination.

Concept for accessing home address from the default trip search screen.

Concept for accessing home address from the default trip search screen.

Greyscale wireframe of the eventual final design.

Greyscale wireframe of the eventual final design.

Rapid Prototyping: Some of these wireframes were then pulled into low fidelity prototypes built in Invision, simulating the text field dropdowns and one-tap trip search. This was useful in tweaking button sizes and locations for optimal mobile usability, as well as making sure navigation between the newly default work/home screen and manual trip search screens was seamless. An Invision link to one of them can be found here. It's been given a visual design pass that replaced the low fidelity wireframes but the concept's functionality can still be tested.

Visual Design: This design change came about around the time that we were looking to do a brief color palette update for the entire app to address some visual design consistency issues, emphasizing a clean, easily digestible white layout with subtle coloring used for the UI elements. In addition, the buttons were sized according to estimated usage based on the Localytics data, making the contextual work/home button large and easy to tap on-screen. 

Screen Shot 2016-11-07 at 5.09.10 PM.png

IMPACT

The Work/Home design update improved the majority of our user's Bridj experience by reducing their trip search experience from several screen taps (or typing addresses into multiple fields) to a single button. Ensuing usage of the feature also lead to more accurate travel data, which subsequently informed future company route expansion decisions. It also set the stage for the impending dynamic drop-off changes by streamlining the new, unfamiliar process  as well as amended users' imprecise address inputs.