A Tesla is a computer on wheels, and while the official app already offers a lot of functionality by letting the owner remotely summon the car, lock/unlock the trunk, start/stop charging and more, it currently lacks a way to access *all* settings that can be accessed via the car’s center screen.
Being able to change any setting(s) directly in the app is convenient – think remotely adjusting something that you don’t want to forget about until you’re back in the car for example.
But access to settings as well as the same visualization and information that is available to you via the center screen can also turn your phone into a valuable backup in case the center screen fails for any reason (and can’t be rebooted by hard reset).
Totally agree. Tesla phone app should have all controls that car center screen has, so your phone can serve as a complete backup.— Elon Musk (@elonmusk) April 4, 2019
To get an overview of the existing information architecture, prioritization and user flow, I analyzed the Settings menu in the car and the Tesla app for iOS. Massive shoutout to everyone who sent me photos of their center screen, especially the Settings menu, and let me log into their Tesla account for a deep dive into how the existing iOS app is structured 🖤
As a result, there are three main objectives when it comes to prototyping the functionality described above:
The car is fully drivable without the center screen, but as there is practically zero information about the car’s remaining range or how fast you’re actually going, it can be quite an eerie experience.
For the first wireframes, I grabbed my iPad and started sketching a bunch of wireframes to get an idea of the overall structure and shortcuts, as well as to conceptualize new features, such as the ability to temporarily use your phone to access key information usually displayed on the center screen.
I started off by adopting some design patterns seen in Tesla’s current iOS app, but quickly decided that going with Apple’s Human Interface Guidelines, e.g. using patterns and information architecture similar to iOS Settings, would feel more natural.
Some ideas were also scrapped in the wireframing process. For example, I originally intended the windows to be opened by a swipe gesture as shown below, similar to the intuitive interaction to adjust the air vents on the Model 3 center screen.
However, it turned out to be something that looks cool on screen, but doesn’t provide nearly as much UX value as I thought it would. Talking to Tesla owners, the overwhelming majority told me it would be a cool gimmick – but nothing more. Since windows are controlled by an actual switch in the car as compared to the center screen, I felt there was probably no need to prototype and implement a fancy gesture hidden in a submenu, and decided to go with regular buttons to fully open/close windows.
For Quick Controls, I assessed whether the current prioritization in the car was still valid on iOS, and, if not, which options potentially needed to be added or removed.
After some iterations, I decided that adjusting the mirrors and steering wheel position is an interaction that occurs very infrequently – and therefore can be moved to a submenu (such as Driving).
I added a button to enable using your phone as a temporary replacement for the center screen (which was originally dubbed Emergency Mode, but after giving it some thought, that might create a wrong association with emergency services/first responders) as well as an option to open/close individual windows or all of them.
Adjusting display brightness didn’t seem to be necessary for Quick Controls either – considering the use case of the center screen not working – so I moved that option to a submenu (Display) as well.
Lastly, I wanted to avoid redundancy within the Tesla app. As options to unlock/lock the car, adjust the AC, open/close the trunk and frunk etc. are already prominently featured on the app’s main screen, I came to the conclusion that repeating these options in the Settings menu would only add unnecessary complexity.
For General Settings, the goal was to provide the same functionality as in the car, but simultaneously make sure individual submenus don’t overwhelm the user with options or get too crowded/cluttered.
Since Tesla’s in-car UI is mostly based on Material Design guidelines and patterns, it was important to slightly adjust icons and the overall visual layout to something more in line with Apple’s Human Interface Guidelines in order to make Settings an intuitive iOS experience. To achieve said experience, I mostly worked with existing iOS component files for Figma.
To make sure Settings blends in well with the existing Tesla app, I chose to use the same color palette and opted for dark mode as well.
At first, I actually wasn’t sure if people would even want to use their phone as a temporary center screen replacement (is that functionality even necessary? Isn’t that inherently dangerous? Shouldn’t they just call Tesla to figure out a solution if rebooting/a hard reset doesn’t solve the issue? Wouldn’t most people drive anyway, even with no critical information such as their speed available to them? etc.). In addition, I’m not a Tesla owner (yet), so making assumptions based on my limited experience is probably not the best way to approach this problem.
However, after conducting the most elaborate UX research known to man – a Twitter poll –, I started sketching and figuring out how to make the most use of an iPhone’s 5.8” display.
If the center screen in your Tesla failed for whatever reason — would you like to be able to use your phone as an emergency center screen while you’re driving to the service center?— Viv 🐉 (@flcnhvy) May 21, 2020
The most important bits of information are:
I decided against including buttons like Voice Control or Camera, since the former can be activated by long-pressing the right scroll button on the steering wheel and the latter isn’t nearly as useful – if useful at all – on a small phone screen as it is on the car’s 15” center screen.
All buttons and icons were designed to be as oversized and big as possible, so the user could place their phone on the car’s wireless charging pad, a dedicated phone mount or the center console, and glance at it while driving without being overly distracted or having to actually hold the phone (since that’s illegal in many states).
Obviously, this functionality isn’t meant for day-to-day driving, for aforementioned safety reasons, but I feel it might be a valuable feature to have – especially for those who wouldn't feel comfortable driving the car without any information available to them.
Ideally, the center screen should never go black without being rebootable, but tech isn’t always predictable. Think failed or not completed software updates for example – stuff like that can always happen for whatever reason, and it’s neither the company’s nor the user’s fault. It’s usually an easy fix too, but if you’re in a hurry and need to go places, it might be useful to have a backup solution.
I’m someone who finds (re)designing stuff that actually exists or has a chance of being implemented much more useful than designing imaginary apps and websites with close to zero real-world application.
In addition, while I love designing (and using) interfaces that look nice, functionality always comes first. Ideally, you want to have both – a beautiful product that also adds real value through functionality, and offers a seamless and intuitive user experience.
In that regard, this design exercise was incredibly fun and provided a great learning experience for me as a design student. I’m in my first year of design school (as of June 2020), and continually strive to learn, improve myself and add to my skill set.