Designing from the Car: Why Context Matters
Every week, over 100,000 new drivers around the world make their first trips with Uber. These first few trips are when we have the best opportunity to educate the drivers on the ins and outs of Uber to help them most quickly and easily reach their full potential. That’s why our team set out to create a great onboarding feature that would be instructive and informative without getting in the way. We needed to understand the driving experience deeply. As the lead designer, I decided to bring the team into the context of the car, unshackling ourselves from our desks and taking our design work out into the field.
In designing this feature, we had three guiding principles, developed through our own driving tests. We knew we had to be:
- Instructive
- Non-intrusive
- Focused and Timely
Instructive: Education through clarity.
We wanted to guide users through the intended journey, without assuming they would know how the flow works or how to use the UI off the bat. Our onboarding feature guides drivers as they:
- accept a trip
- navigate to the rider’s pickup location
- identify the rider
- navigate to the destination
- drop off the rider
- rate the rider
The whole time through, we wanted the instructions to be clear, concise and easy to understand for a global audience.
We also wanted to ensure the onboarding feature would be instructive for all drivers, including those with hearing or reading difficulties. A main goal was to provide education in various forms to accommodate different learning styles and types of drivers.
Non-intrusive: Get out of the way.
There is a lot of important information that has to fit onto a driver’s phone screen — all of which has already been carefully crafted by our designers, product managers, and engineers. We had to make sure not to block any critical information in that moment, which meant being mindful of the overall system. It needed to work seamlessly and sequentially in a pre-existing user flow and mesh with what was already on the screen.
Focused and Timely: Not just what, but when.
It was important to consider not only what we wanted to convey to new drivers, but when we wanted to convey it. You should not bombard new users with all the information at once. Instead, it’s better to present bite-sized information when it is most pertinent, moving the user through the nuances of the moment and into the future.
How we got here
The principles were roughly formed in the beginning of the project and informed throughout the process of contextual prototyping. We iterated and refined them as we designed from the inside of a car, stress-tested with the team and validated with new drivers on the road. Designing in context gave us full confidence that our designs would draw upon and respond to real-world use cases. We took three drives over the course of product development before launch.
First Drive: Clarity through context
For our first drive, I invited an engineer, a product manager, a design researcher, and a content strategist to drive and collaborate on the designs while working through several prototypes (we used Sketch Mirror and InVision). We wanted to test the user experience as if we were a driver running through an ordinary sequence: accepting a trip, navigating to the pickup location, picking up a rider, navigating to the destination, and finally dropping off and rating the rider. Our aim was to identify best opportunities to educate and make sure we weren’t blocking critical information in the existing flow.
What we learned: We noticed right away that some of our instructions could be made clearer with context. For example, we replaced our original “Slide right to start trip” with “Confirm the rider’s name, then slide right to start the trip.” Here we sacrificed some screen economy in favor of context that would be more helpful to a new driver. We also added voice guidance, which freed us from the word limit of tooltips.
Some other changes based on this drive:
- Different tooltip colors based on natural outdoor lighting we experienced.
- When gray-outs would appear to increase focus and attention.
- Increased font size informed by car ergonomics, such as the “three foot experience” — understanding that drivers using the app would typically have their phone mounted about three feet from their eyes.
- Additional animations to grab the driver’s attention when necessary,
- Adjusted timing of information because we now knew exactly what was happening and when.
This first trip was crucial in realizing just how necessary the drives were going to be to the overall process. Many of the opportunities and tweaks we made might not have been thought of when designing from our desks without the benefit of real-world context.
Second Drive: Evolving the experience
For our second drive, our engineer built a prototype based on learnings from the first drive. It was fully functional, so we were able to test the entire end-to-end flow on mock trips.
What we learned: We were interested in learning how we could evolve the onboarding experience over the course of a driver’s first few trips. We wanted to phase out tooltips and then voice support as the driver became more experienced, building muscle memory, so that actions and behaviors became second nature.
We also realized that we hadn’t included any guidance when a rider is a no-show at the pickup location (when this happens, the driver should call the rider). This omission became obvious in the context of a real-world test, but something we had missed back at headquarters.
We also saw how much more challenging a ride might be for drivers on trips without a provided destination. While this is a common occurrence that’s easily dealt with by experienced drivers, our test drives led us to recommend that first-time driver’s only be offered trips with set destinations.
Third Drive: Validating with real drivers
On our final drive of this design process, we invited new drivers to use our prototype with the code we were planning to ship. This was a great opportunity to see how people completely fresh to the development process would interact with the onboarding feature.
What we learned:
The third drive was crucial in validating our design approach. Adding real new drivers was the last bit of context needed to make sure that we were developing a useful tool. We were thrilled to watch the drivers take the right next steps thanks to the guidance.
We were also surprised to learn that removing all the training components after the first trip was less successful. They did not remember as well what to do on the second trip. That led us to the realization that we needed to progressively remove each component (first gray-outs, then tooltips and finally voice) and offer the driver a more gradual transition experience.
The tests went very well, and we received great feedback. Some of the best feedback came in follow-up interviews when the drivers didn’t even remember seeing training components — a good sign that the UI was seamless and unobtrusive, and that the staged removal was working. This gave us confidence that we were building the right thing to support and help prepare new drivers. This step also informed our AB testing approach and how we tested when to remove specific training components.
Bigger lessons
Besides learning lessons applicable to specific product design questions for the onboarding feature, our drives offered us valuable insights into broader themes as well:
Minimizing risk, maximizing empathy
Taking our prototypes out for a real-world spin offered a great opportunity to identify moments for education, catch mistakes or blindspots early on in the design process, minimizing the risk of shipping products that might have less of an impact.
Ultimately, in-context prototyping is all about empathy: experiencing the product or feature the way that the user will, and helping us to identify more closely with that user.
Increasing collaboration and team buy-in
It was important to me to bring members from across the team on these drives — not just designers and researchers, but product managers and engineers as well. This ensured that everyone experienced the real-world scenarios together, had the opportunity to give valuable input, knew exactly why we made the decisions we did — in short, that we were all aligned on our mission. As an added bonus, getting out of the office and taking our prototypes for a spin was a fun team-building exercise and a great way to mix things up.
Broader applicability
In developing these components we soon realized that the same methods we were implementing for this specific use case — offering support to new drivers — would have relevance for many other teams and the experiences they were building. The educational components could be applied any time we added features to the driver app or made any other revisions. For example, these components could be used to teach drivers on how to do deliveries, or to walk drivers through their first pay statement to help them better understand their earnings.
Designing within context
Just as our onboarding feature can be applied to other use cases, designing in context is useful no matter what product you’re creating or who you’re designing for. Whether it’s a fitness app or a medical device, putting your prototypes through their places out in the world and stress testing use cases, both early and often, is a great way to keep the end users’ needs in the foreground throughout the entire process. You’ll discover product opportunities, improve the experience and fine-tune your designs before making large execution investments.
Our in-context drives for the purpose of prototyping were invaluable to our design process. They brought to the forefront considerations such as ergonomics, lighting, distraction, sound, and timing that may not have immediately come to mind when we were in front of our shiny big Mac monitors.
So I encourage you to get out and design in context! Your users will thank you for it.
Thank you to Grace Vorreuter, Daniel Burka, Florent Crivello, Pete Petráš, Megan Ma , Molly Nix and Adam Zethraeus for editing drafts of this piece, and our wonderfully talented extended team for their hard work on this project.
