Building a Multi-Modal Transportation Platform with JUMP Bikes

On February 5, 2018, a subset of Uber users in San Francisco were invited to “push a button, and ride a bike.” This pilot program (enabled by a partnership between Uber and JUMP Bikes), marked the first step of Uber’s evolution into a multi-modal transportation platform. That initial group could locate an electric bike within the Uber app, reserve one, and ride anywhere in the city.

JUMP Bikes, a product and technology leader in the growing bikeshare industry, offers bikes to rent by the minute that are both electric and dockless. The electric pedal-assist makes the bikes suitable for a broad range of people over more difficult terrain, such as hilly San Francisco. Dockless means that instead of requiring bikes be returned to a specified station, they can be locked to any public bike rack within a prescribed service area, greatly enhancing transportation flexibility for our users, while helping to prevent reckless, unsafe or inconsiderate behavior from riders.

JUMP builds and distributes its dockless electric bicycles, with current availability in Washington, D.C., San Francisco, and the Sacramento area. Uber made JUMP bikes available for rent through our rider app in a seamless integration for San Francisco riders. Adding the ability to rent electric bikes required engineering teams from both Uber and JUMP to decide how to integrate this functionality on the backend, and what to show users within the app.

After the success of the pilot program, Uber acquired JUMP to help us achieve our shared goal of creating more reliable transportation solutions for cities.

For the pilot program, we integrated JUMP Bikes into the Uber rider app. Touching the menu icon in the top left corner of the app reveals a new option, “Bike”. It opens up a map, similar to that used for our ride-hailing service, showing nearby, available bikes.

On first use of the Bike option within the Uber app, riders will have to accept a rental agreement, and then they can simply select a bicycle on the map and reserve it for a given time period. The app walks riders through the process of unlocking and riding the bikes.

Beyond the app, this integration works because of the seamless nature of our shared missions. At Uber, our goal is to help make available “reliable transportation for everyone, everywhere.” Electric bikes provide an excellent complement to ridesharing for inner city short and mid-distance trips where traffic is high, parking is costly, or when public transportation is unavailable.

The flexibility and accessibility of the bikes give people in cities a transportation alternative that may better fit their immediate needs.

Besides being convenient, biking is an environmentally friendly, fun way to get around. It’s already something San Franciscans do all the time, and Uber wants to be part of the adventure.

The research our team conducted in major US and international markets revealed that convenience, price, a smooth app experience, and a bike-friendly city infrastructure matter the most to bike share customers.  

As with many efforts at Uber, development of the bike project proceeded quickly. With a short time frame from inception to a minimum viable product (MVP) that employees could test, we had to rapidly define the project’s scope. We assembled a team made up of members from product, legal, design, engineering, customer relationship management (CRM), content strategy, marketing, data science, and operations. The cross-functional nature of our team enabled us to gather all the required knowledge in one room, iterate through a large number of designs, and converge on the best product decisions in a short period of time.

Uber’s design team worked closely with the Uber and JUMP Bikes’ engineering teams to ensure the workflows they developed could be supported with our technology infrastructure and in the time allotted. With this approach, we avoided the problem of coming in at the end of the design cycle and finding that a particular design would take too long to build or could not be supported.

This process serves as a useful model for future projects, as it leverages the expertise of multiple teams to quickly come up with a high-quality deliverable.

The key elements of the experience we supported in this first iteration of the project were:

The two common flows we had to support were: (a) an Uber user wants to book a JUMP bike within the Uber app, and (b) an Uber user that was previously a JUMP Bikes’ rider wants to do the same. The latter requires showing additional legal consent forms to migrate a JUMP user onto the Uber platform, but we would not know someone is a JUMP user until they went through the sign-up process. We had to design our flows in such a way that the information exchanges between the Uber platform and JUMP Bikes would happen in a very specific order, but at the same time look completely transparent to the user.

While scalability was not an issue so early on, we did not want to optimize prematurely; we wanted to avoid building up technical debt. As such, we needed to assess everything from the perspective of “will it scale when we need it to?”

In addition, we had to plan for possible edge cases that occur in real-life scenarios, such as people using both the Uber and the JUMP Bikes apps interchangeably. Getting any of these wrong would mean unhappy riders, along with increased rates of people calling customer support. Luckily, integration with Uber’s logging and monitoring infrastructure was almost free, letting us keep tabs on our errors and quickly repair any production problems.

One of the most challenging issues we found in building the booking experience was designing a simple mechanism to search for bikes. Our timeline did not allow for clustering algorithms or other elaborate mechanisms to show the available bikes spread over San Francisco.

We came up with an idea based on the fact that JUMP’s permit was for 250 bikes in the city. We would show just the nearest ten bikes in a typical walking radius to a user, and expand the search area if not enough bikes were available. This strategy was simple to implement and ensured that users would see the closest bikes while not getting inundated with results. As the number of bikes grows, we will need to upgrade our search mechanism to something more sophisticated.

For safety, we do not want users looking at their phones while they ride, but we do need them to pay attention to the app at the beginning and end of each trip. We had to show them how to inspect and unlock the bike, and to ride safely with the right gear (helmets!). On the tail end of the trip, we wanted to make sure that users lock the bike, but that they do so in a way that it is not a nuisance to pedestrians.

The flows here were not particularly complex, but we needed to make some key decisions about whether Uber or JUMP Bikes would be the authoritative source of information. We concluded that JUMP Bikes should maintain this responsibility, as the bike states, such as locked, reserved, or on a trip, change frequently, and it would be impossible to maintain an additional consistent view of the whole system.

Figure 1 shows a simplified architecture of the Uber bike system. Mobile clients, the Android and iOS apps, communicate with Uber’s bike services via the gateway. The gateway performs security, validation, logging, and other related features. The bike service acts as an adapter between the Uber mobile clients and the JUMP Bikes’ service. For each call from the mobile clients, it may make one or more calls to the JUMP service and aggregate the results. It has to do some processing to make the information suitable for mobile consumption and also caching, so we avoid unnecessary network calls.

In addition, we made a set of webhooks available to JUMP Bikes. These webhooks come into play when there is updated information about a booking. For example, when a bike has been locked or unlocked, JUMP Bikes’ platform calls those APIs, and then we push this information to the mobile clients to update their display status. Similarly, when a reservation has ended, JUMP notifies us to get payment information for that user, so it can put through the necessary charges.

On the bike service side, we were able to use numerous other services from the Uber infrastructure to rapidly build, such as:

We initially launched the Uber bike flow on our iOS app, then expanded to our Android app within a couple of weeks. Following the launch of this pilot program, we are making improvements to the bike discovery experience, creating a first-class customer support flow, expanding the bike search functionality, and working with the JUMP team to reduce error cases due to firmware, GPS inaccuracy, or inaccurate battery readings.

Both the iOS and Android experiences will soon expand to new cities (Washington, D.C., launched on April 9, was the second market), each of which will exhibit unique challenges. Our engineers will need to replicate and adapt this flow for each of these new environments to give our customers the best possible experience.

As an early catalyst of Uber’s platform vision, the Uber engineers who worked on the JUMP Bikes partnership will work closely with other engineering teams to communicate their experiences and develop best practices for onboarding partners.

To make this happen, we need you! The team is growing fast and won’t stop doing so. Currently a team of eight, there are additional mobile, backend, and full-stack engineer roles available. Apply for a role with us via the Uber Careers page and tell your Uber recruiter that you’d like to work on Uber’s Bike team.

Subscribe to our newsletter to keep up with the latest innovations from Uber Engineering.