AccuWeather has products built for mobile, desktop, television, and many more; however with their new partnership with Volvo’s Polestar, they needed their weather application to be adapted for Android Automotive Operating System (AAOS) - Google’s Android operating system tailored for vehicle dashboards.
Problem
How can we build a weather application satisfying the guidelines of AAOS while ensuring that the required information is displayed in an intuitive and clear way?
Outcome
We launched the AccuWeather AAOS app in over 64,000 Polestar 2 cars in the first launch. Throughout this process we also collaborated with the AAOS Google team to present ideas on how to future-proof AAOS for other types of applications.
DEFINING TERMINOLOGY
Throughout this case study, I’ll be referring to Android Automotive OS (AAOS) and Android Auto (AA). The core difference between the two is that AAOS is an entertainment system itself so it does not rely on the user's smartphone to be connected to the vehicle, while AA does.
Constraints
Working within templates: The AAOS rules were very specific due to the safety required when designing for drivers, but the type of app we were designing (weather app) wasn’t included in any of the categories mentioned in the guidelines. Due to this, we had to modify our designs to fit within the templates set out for other app types (communication, media, driving).
Brand guidelines: Since the project was in partnership with AccuWeather, we had to ensure that their brand guidelines, colours, icons, and copy were maintained throughout all of the designs.
New technologies: Given the nature of the new technology that our engineers were working with, they had to use an emulator for testing purposes and were discovering limitations in AAOS on a daily basis. This resulted in our designs being created very much in tandem with them testing the functionalities of the features, creating lots of rapid changes.
Short timeline: Working in an agency setting also meant that we were on a short timeline of six weeks, after working with the clients to decide the MVP features we had to regularly make sure that we did not encounter scope-creep in the designs which we were creating.
What do we need to include?
The first step in this process was understanding what information needed to be displayed at what point of the interaction, and the different states we would be designing for. For each of these there would have to be a different variation of the information displayed. The different states we landed on were:
Drive state
Parked state
Error state
We laid out the core information and optional information required in each screen.
Doing this early on allowed us to design with the content in mind instead of thinking about the content afterwards. This was particularly useful later on when exploring the different templates we could use as we would slot in the information into different parts of the template to explore how it would change the user experience.
Design for Driving guidelines 🚗
A core part of our learning for this design process was becoming innately familiar with the principles, interaction models, layouts, and components in Design for Driving for AAOS.
In particular when designing for drivers it’s important to keep the following principles (from Design for Driving) in mind:
Keeping information current and glanceable
Encouraging hands-on driving
Prioritizing driving tasks
Discouraging distraction
To ensure the above principles we had to ensure that the content was easy to read, targets were large and distinct, and that there was a low mental load when users made decisions. We also had to follow the conditions that all flows were 5 steps or less, and that buttons with states could only be used in list rows.
We discovered during the design process that we were limited to using the 7 general purpose templates designed for all applications.
To better understand the space we had to work with, our engineers provided us an overview of how much space we had to work with in the navigation bar, status, and screen area. The other designer on the team also went to the Polestar display store to give us a better understanding of the interactions already present.
The AAOS emulator
The maps AAOS application
Exploring the landscape
To gain a better understanding of how the current market was displaying weather information in cars, we explored how other cars displayed their information on the existing Android Auto system.
We found that there were a variety of different ways the same information was displayed, while some manufacturers leveraged columns to display daily data with more visuals, others used rows in order to display more information.
A common theme between all of them were that images and iconography were heavily used in order to allow used to have a glanceable way to understand the information provided. Colours were also sparsely used, and only correlated to one type of message (i.e. sunny was yellow, rainy is blue, red is an alert)
Carrying forward patterns
Since we were designing under the AccuWeather brand of products, it was important that we understood the current design patterns and flows across other platforms, specifically their offering on Android Auto.
By doing this we found that the typical design pattern followed by AccuWeather is to have horizontal rows of information to show as much as possible. There was a carefully decided hierarchy of information which we could leverage when designing our version.
Collaboration
Our main collaborative partners throughout this process were the engineers on our team (development and QA), as well as the stakeholders from AccuWeather and Volvo.
My experience collaborating with the engineers on this project was unlike anything I had ever done before. We were working together continuously to test out different ideas and variations of layouts we could use in order to better showcase the information. We created a page on our Figma with mockups of screens to test for feasibility and the particular part of the screen we wanted to test. Doing this was very helpful because it provided the engineering team with visuals of what we were looking for, and allowed us to quickly consider alternative designs if a particular aspect of a screen was technically unfeasible.
When it came to collaborating with AccuWeather and Volvo, our main priority was ensuring that we were adhering to their respective brand standards and vehicle regulations. We checked in with the AccuWeather team once a week, communicating with their internal design and product team when it came to making key product and information architecture decisions. Through this project, I had the opportunity to discuss the design decisions I was making with stakeholders, justify my reasoning behind them, and absorb different perspectives before making a final decision.
Visual explorations
When we initially started our visual design approach we were not aware of the specific templates we had, but only the general space constraints to follow. The key parts of the process we explored were the navigation bar and the current weather screen.
Navigation bar
We were limited to having only two options in our sticky navigation bar at the top of the screen. The options we could show in the navigation were: alerts, settings, search, hourly weather, home screen shortcut.
In order to determine which two options to choose, we made mockups of each version and created a path showing how the user would interact with the screen given each situation. Based on this, we realized that having the settings on the navigation bar would not be useful since this is not a commonly used path. Having the shortcut to the home screen was also redundant since there was already a back button on the left side of the navigation bar which we could leverage.
After talking to our engineers, we found that we could have a dynamic alert button which went from outline to filled when there was a live alert in the location that the user had selected. Due to this we were left with two options for the second icon, search or hourly weather.
Based on our understanding of the industry standard in other AAOS applications and the constraints we had, we chose to include the search and dynamic alert buttons in the navigation bar.
Current weather explorations
When designing the home screen, we had a lot of information to be displayed, but had to ensure that all of it was clearly understandable. A key part of this was using large iconography, hierarchy within the text, and only showing the information that was relevant. For the first iteration of the design, we explored using the background image to help indicate the temperature. We put both the hourly and daily temperatures on the same screen using font sizes to separate the information.
While there was some level of hierarchy in the information displayed, there was still too much information presented on the screen. We found that at a quick glance it was not possible to immediately find the required information. After talking to the engineers, we also realized that it was not possible to have a dynamic background page.
In the second iteration we focused on only including the necessary information. After exploring different versions of how the current weather should be placed in relation to the navigation bar, we found that having a top navigation bar with the current weather centered worked best.
In the third iteration, we explored alternative visual representations of the information, as well as the different states that would have to be present. We found that having visual representation was very important, but one clear icon helped convey the message best. A very important state in weather applications is the alert state which should both be visible and clear. In all of the designs, it was important that there was space for this state without making any of the other information too small.
Design templates
After going through this process, we realized that many of these were not possible due to the templates we had found. As a result we decided to choose the panel, search, list, and long message templates, and leveraged our earlier visual explorations to decide on the final versions.
.svg)
