Building a More Seamless Web Booking Flow for Uber

Email

Uber is committed to making our transportation platform accessible to everyone, everywhere. Our rider app is a familiar entry point, but Uber’s Rider Web team expands access through browser-based solutions that enable people to request a ride irrespective of platform, network speed, or device by leveraging m.uber.com , our progressive web app.

In 2017, we released our original web-based booking flow for Uber to let riders request a ride online without an app. Since then, we’ve looked at usage patterns, conducted user surveys, and analyzed how best to serve the needs of an Uber rider using our mobile web, desktop, and Windows 10 app. Riders voted through their clicks and made their voices heard through their responses to many site-based and in-person surveys over the past year.

We looked at all the data and user feedback to understand what was working and what was not. We also learned from the design updates on our main app and Uber Lite app , and brought the best practices to the web to make the experience better for our riders.

In early 2019, we introduced the new desktop-friendly web-based booking flow at m.uber.com , rebuilt from the ground up using our latest Fusion.js framework. We designed and engineered it as a primary entry point for users who prefer to book their rides through a browser.

Figure 1: The booking flow for the newest iteration of our m.uber.com web site lets a rider select a destination, shows them available product options, then lets them choose their preferred mode of transport. The site can be accessed using web browsers on most devices, such as a desktop computer or phone, and is designed for areas with low bandwidth.

What’s new

We redesigned our entire user experience and optimized the web booking flow for speed and performance. While there were many changes, the three most important ones involved designing specifically for desktop computers, making the experience understandable for new users, and optimizing the site for speed. 

Desktop first

When we redesigned Uber’s web booking flow, we decided to give the desktop computer the same attention as we would for mobile devices. This is perhaps the biggest change in our design philosophy for the web. In our previous iterations, we focused on optimizing our mobile experience. Our desktop experience was a responsive version of the mobile site stretched across users’ screens, making it less aesthetic and more difficult to use. 

Since rolling out m.uber.com , we observed that 30 percent of riders primarily request trips on a desktop computer as opposed to on a mobile device. According to our research, riders who wanted to plan their travel in advance also tended to use and appreciate the desktop experience.  

In order to better serve these users, we built the new version of our web booking flow with desktop as a priority. On the desktop experience, users also get an interactive map to see their routes, pick-up points, and rides in as much detail as the mobile version of our app, as depicted in Figure 2, below: 

Figure 2: The desktop version of our booking flow lets riders view all nearby pick-up points on a map and select the one they prefer.

Targeted to new users

While the updated web booking flow continues to serve riders on older and unsupported devices, we found that new users were particularly interested in using the web flow for their first-ever Uber trips. Our team conducted multiple experiments across all the regions where Uber operates and found that in many regions, if given a choice between downloading an app to take their first ride and requesting a ride on the web, riders typically preferred using the web flow. 

This trend became apparent by observing user behavior. For example, when we gave riders the option to book their first trips on Uber’s homepage rather than downloading the app, we saw a 10 percent increase in first trip conversions globally and an approximate 60 percent increase in first trip conversions in regions such as India and Brazil.

Based on these insights, we built a new version of the web booking flow with first-time users in mind. For example, instead of assuming a rider’s pick-up location we ask them, “Where would you like to be picked up?” while suggesting popular nearby pick-up points. This option improves riders’ pick-up experience by reducing reliance on maps. We also redesigned the new web experience to make the user interface more understandable.

We are currently optimizing various rider touchpoints to give riders an option to request their first trips on the web, exposing this option so that a wider range of users can enjoy our services. 

Figure 3: The newUber homepage hosts a link tom.uber.com as the primary call-to-action, encouraging visitors to download the app as a secondary call-to-action.

Enhancing speed 

In addition to adding new features and functions, we remained committed to giving riders a seamless and quick experience with our new web booking flow, regardless of device or connectivity. 

The previous version of m.uber.com was built using our Preact-based framework. Although it gave us the advantage of a small payload size, all of our web properties were moving to the Fusion.js framework . This plugin-based universal framework, developed at Uber and now available as an open source project , focuses on perceived performance through server-side rendering on first load and client-side hydration for further interactions, traits that can significantly improve the rider experience.

We also began aggressively caching resources using service workers so that repeat visitors could get a responsive, app-like experience on the web even when using a  slow and inconsistent network.

The final results are encouraging. Despite increasing the bundle size, we saw a marked improvement in time to first byte and the time for the page to become interactive, as shown in Figure 6, below:

Figure 4: Although our older, Preact-based web booking flow had a smaller bundle size and quicker time for the full page to load, the new, Fusion.js-based actually became usable more quickly, leading to a better rider experience.

Our earlier web experience also allowed riders to save bandwidth by switching off maps, but the experience was not aesthetically pleasing and the toggle was difficult to discover. In the new experience, we gave riders more control by bringing the map toggle upfront. We also made the mapless experience much more intuitive for riders who prefer that mode.

Figure 5: Riders may choose to turn off the map in our web booking flow, as the bandwidth it uses may be too much for a particularly slow network.

Final thoughts

We want to make Uber’s services accessible to everyone, not just those with the latest, greatest smartphones. Leveraging tried and true platforms like the web help us reach a wider audience, including people who may live in regions where network access is slow or where phones based on older technology are more common. 

Behind the scenes of the seemingly basic technology of a web site and browser, however, technologies like progressive web apps and the Fusion.js framework lets us give a great experience to our riders. Not only can a rider using our web booking flow at m.uber.com search destinations and see ETAs, they can get real-time updates for when their ride will arrive. 

And it doesn’t end there. We found an opportunity to update and improve over our previous web booking flow and will continue to look for ways to make it better. 

Acknowledgments  

Ravi Hamsa, Abhilash Goje, Abilash S, Shreedhar Shreenivasa, Gaurav Jain, Aditya Binaykia, Adit Gupta, Namrata Mehta, Saurav Kaushik, Praneeth Reddy Kudumula, and Saurabh Choudhary also worked on this on this project.

Interested in joining us? Consider applying for a role on our team!

Comments