Quick Controls
Designing how owners interact with vehicle closures and commonly used features in Rivian R1 vehicles.
Problem
R1 owners unsure about what to expect under the Settings App and Vehicle App in the Center Display. Also, excessive hopping between Vehicle App and other apps.
Opportunity
Define a smarter model for owners to use and think about when it comes to accessing controls from the Center Display. More clearly define a control versus a setting and have the system reflect that level of simplicity.
Outcome
A new Center Display framework that elevates common vehicle controls to a system-level panel (Quick Controls). The re-homing of less commonly used preferences to respective areas in the Settings App.
A Clean Sheet
I joined Rivian at the outset of defining the R1 in-vehicle user experience. Our team’s earliest tasks were to define features like climate controls and vehicle access — features that were must-haves for a functional car that could be legally sold. The interior’s 16-inch Center Display would support almost all functions via soft buttons and replace traditional hard keys or switches found in most trucks and SUVs.
Original Vehicle App Design
I worked with a small team of UX, UI, and motion designers to design the layout and interaction design for the original Vehicle App. We grouped vehicle content like closures, lights, and display settings into a single home with different tabs along the left for easy navigation. At any moment, a user could select the Vehicle App from the bottom app tray and use it to open closures or select different tabs for other features.
We worked through numerous layouts but landed on one that kept the car positioned upward and clustered the most important controls closest to the driver. We gave labels to each closure so new users would know exactly what they’re pressing and what will happen as a result.
Vehicle App and Settings App
The original in-vehicle software featured two somewhat related apps; Vehicle App and Settings App. Vehicle was where to use various controls and change some preferences related to the vehicle.
Meanwhile, the Settings App also contained preferences, but ones that were grouped differently, were simple binary choices, or were considered to be less frequently used. It was designed with a simple navigation for drilling down — easy to use in distraction filled environments (like driving).
I led the design of the original Vehicle app and Settings app. They both were apps that could be selectable from the bottom app tray.
An Emerging problem
As first deliveries were ramping and vehicles were hitting the streets, we began capturing qualitative data on non-employees using the vehicle. We heard users getting anxious selecting between the Vehicle App and Settings App. Our data suggested people couldn’t really tell the difference between what belongs in the Vehicle app versus the Settings app. In other words, They weren’t sure where to go, to do the thing they were thinking of.
design philosophy
To start, we really had to take a step back and think about our system philosophically. We explored the relationship between settings and controls, recognizing that R1 owners' expectations stem from the combined experiences beyond our vehicle software.
We collected and were inspired by tons of examples of products and services that differentiate controls from settings, frequently used functions from less frequently used, and gestures or accelerators that advanced users would employ.
Across many diverse experiences we studied, the 'gear' icon consistently represented settings, serving as a universal symbol for adjusting preferences or how something behaves. With that in mind, we chose to keep the Settings App, but be more deliberate about the content that goes under it.
Settings are often 'set and forget' choices, while controls act are more frequently used actuations — used and immediately put away. I helped drive alignment on the agreed-upon difference between the two.
Thinking about form
Right away we began questioning whether controls really make sense in a fullscreen app form. I focused on other possibilities that felt more system-level similar to the already existing media player on the right side. My early hypotheses (which revealed a way forward) was that addressing the form factor could help people mentally distinguish the two spaces. The aim was to increase confidence to know where to go based on whether it was a control or a preference.
I designed and later prototyped a floating panel that can be swiped in and out of view on the Center Display. It was the start of something much simpler to navigate, and easier to access.
Original Concept
The first draggable panel was intended to strike contrast with app level content. We made a floating panel that started with the most relevant content that should be quickly accessible: access to closures like hood and liftgate/tailgate.
Version 1 had an expand function which we later removed because of the unnecessary complexity it added.
Usability testing
I worked closely with our UX Research team, participating in several rounds of usability testing and task analysis. We’d usually place a tablet over the display of a testing vehicle and run prototyped concepts via ProtoPie software. We’d give participants vehicle control-related tasks and settings tasks, measured task completion, and asked them to think out loud as they interacted with the prototype.
A researcher walks an internal participant (driver) through a set of tasks and asks them how they would complete those tasks. Early testing with lightweight methods told us we were onto something. We would eventually perform 5 rounds of participant observations like this as Quick Controls became an officially sanctioned project and properly resourced.
We ended each session with a simple question: Could you see yourself using this new feature and followed up with questions like How? and Where? Participants overwhelmingly embraced the new form factor and overall concept. Our research partners agreed, we were making our system easier understand by re-factoring the Vehicle app into a floating panel. We shared quotes and video clips of our internal testing with stakeholders and let participants echo positive sentiment.
iteration
We iterated on the layout of Access until we eventually removed the verbose labels and gave the tabs of the panel tap-able regions for quickly paging. Later iterations got the support of Visual Design and Motion team members to help refine the visuals. Overall we focused in on designs that optimized for the ownership experience and were more forgiving when it came to first-time user experience unfamiliarity.
I used ProtoPie to build advanced prototypes that could be tested on target hardware. They would be used for executive demonstrations, usability testing, technical reviews from software teams and eventually documentation. Moreover they served as means for the team to try out different system-level concepts without the cost of developing real software. Our rapid prototyping cadence gave us the confidence to go wide with our explorations and ensure solution validity.
I made several prototypes to explore the boundaries of how our framework would adapt; affecting the app layer and providing more personalization.
We heard users asking for more flexibility with our system making requests for things like “split screen,” a multi-tasking view, or even a sense of ‘home’ like what Apple Carplay users are accustomed to. We also heard them ask for more simple and straight forward requests like bring the media player from the passenger-side to the driver-side of the Center Display. Other owners requested access to have drive mode controls and cameras simultaneously while off-roading to enjoy experiencing terrain from various live angles.
Defining the vision
What we made had to be dynamic and solve for a broad range of limitations in the current R1 Center Display framework. We used prototyping to feel out the kind of experience we ultimately wanted users to have. We called this the vision work, and it was meant to inform how we’d chunk the work for software releases.
planting the seed
At first, our concepts weren’t well received by leadership. It would take some time and some usability testing feedback before opinions would change. While we pushed on other concepts we kept coming back to the advantages of a floating, temporary panel. A few key user experience advantages had executives eventually wanting to see more:
Content that was vehicle access related was showcased in a more appropriate form factor.
Additional gestures like swiping from the edge to reveal added significantly to ease of use.
Being able to trigger the panel upon vehicle states like entering PARK was a really desirable way to cut down on interaction cost.
“The day you plant the seed is not the day you eat the fruit.”
Testing at the Farm
Getting away from the desk and interacting designs how they’ll be experienced is critical to in-vehicle design. A team member who owned a farm and kindly offered his truck as a testing platform allowed us to learn from our designs firsthand.
We drove routes that began on pavement and ended with a muddy crawl across uneven terrain that gave us an accurate sense of how our designs would be perceived. With sticky tac we mounted a large tablet loaded with various prototypes in the vehicle and tested our designs while driving.
Delivering Version 1.0
I partnered with a front-end development manager to understand how we could package our work into a first release. We focused on the smallest body of work that would create the most value for users while moving toward the vision we’d created.
Our first release would be a simple swipe-able panel with just two sections: Access and Shortcuts. All other content from the original vehicle app (that were more like settings) would be moved to the Settings app for a cleaner mental model. With our concept scoped and properly resourced for development, we moved into the production stage that would end with an over-the-air update to Rivian vehicles nationwide. A content leader casually referred to the panel as Quick Controls in a design review, and the name stuck.
After several visual design iterations, we came up with a concept of placing the vehicle overtop of access tiles with soft borders to show where to press.
We deliberately designed R1T and R1S access views in tandem so neither one was just adopting design decisions from a different vehicle. We used Confluence for documentation so that’s where I documented in depth all the details for consideration by software teams.
I made a demo of each permutation of R1. This was a part of the documentation used to convey to engineering teams exactly how we planned to solve for the variation in our product lineup.
Testing on target hardware
Once integrated with some test vehicles, I’d get hands-on time with Quick Controls where I’d video record bugs or areas of the experience that needed more polish. This was a critical stage that required constant communication with development partners. It’s also where my attention to detail really shines.
Released into the wild
Quick Controls arrived for R1 owners in mid-February 2024 via a software update. After almost three years in the making, our hard work was getting into the hands of the Rivian community of owners. It was met with overwhelmingly positive feedback. We succeeded in making a more easily understandable framework and set the foundation for exciting future updates.
Below are snippets from Reddit where R1 owners gave unsolicited feedback of the software update.
Coverage - CNet
Exclusive Look
Inside Rivian’s EV Test Lab
June 6, 2024
Reaction after experiencing an Rivian (and EVs) for the first time:
“…But I also really felt like when I was driving with the vehicle, interacting with the screens, changing all those settings, it really felt like an extension of the things I’m using in my everyday life.
That real mentality of how I use my device kind of now translates to the car itself.”
Coverage - the atlantic
What the VW-Rivian Deal Means for Big Auto
July 8, 2024
“Volkswagen is partnering with Rivian not because it wants access to the company’s manufacturing expertise or even its EV technology. It’s doing so because it wants access to Rivian’s software. What this deal represents is an admission by Volkswagen that it needs help, and that its attempt to go it alone with EVs has stalled. But that’s progress. As they say, the first step to solving a problem is admitting that you have one.”
Other notable comments:
“The EV maker (Rivian), meanwhile, isn’t putting up any cash; all it’s contributing is its knowledge and intellectual property. This is unquestionably a good deal for Rivian.”
“So if working with Rivian puts software in those vehicles that’s reliable and user-friendly, VW would be well on its way to realizing its ambition to be a force in the EV market. If you can’t beat ’em, join ’em could be VW’s winning strategy.”