top of page
sxm logo_3x.png

Building SiriusXM’s First Responsive Design System

In 2020, as a response to this industry shift towards Google’s Automotive OS design system, SiriusXM began working on a new product offering, SiriusXM Official AAOS App. As a result, we needed to build a new component based system that would allow us to scale SiriusXM with 360L to any automotive AAOS program.

responsive mockups2.png

An Industry Change

Google first made the push to infotainment in 2019 with the launch of the first Android Automotive OS powered vehicle, the Polestar 2. Since then, multiple automotive manufacturers, including Ford, GM, and Stellantis have signed contracts with Google to implement Android OS in upcoming programs.

While past automotive solutions relied on screen projection, Google’s AAOS ties more closely to custom vehicle functions. With AAOS, the automakers have more freedom in deciding what media templates look like, meaning designers would not have to stick to Material Design standards and can pick typefaces, colors or button shapes that will best integrate with the overall design of the automaker specifically. Meanwhile, the automaker would have control over how design elements are laid out and what information is displayed.

 

From the UX side of the house, this was a major shift in how we approached design with our automotive clients. Although the Google media templates provide much more flexibility in terms of layout and customization when compared to Android Auto, they were still a huge step away from the level of granularity that most OEMs are used to when working with us to design their UI from scratch. 


What is AAOS?

 

AAOS is an Operating System and application framework for the car, built by Google on top of Android. The benefit to automotive companies over traditional development is that AAOS provides hardware and touch support, third-party apps, and a well-known developer SDK with monthly security updates to the codebase.

specsite-general-intro.gif

Animation courtesy of Google Design for Driving

Start

The Opportunity

With the shifting industry standards, SiriusXM saw the opportunity to create a fully-featured production-ready application, scalable to all OEM’s that are implementing AAOS. Unlike third party media apps such as Spotify or iHeart Radio, SiriusXM is pre-installed and updatable by the OEM via over the air updates or OEM-Managed app store. 

 

Our new approach included a full UX & Design implementation based on SiriusXM’s Blueprints & Reference Design. Due to SiriusXM’s position in-vehicle and strong partnership with OEM partners, we had the added flexibility to design outside of the strict Google media template and to exist in each OEM’s specific app store, as opposed to the Google Play store. This also meant we could leverage our industry knowledge and take into account the best practices from across the automotive and design industry and from SXM’s in-vehicle research.

Group 10.png

My Role

I worked as one of three lead designers tasked with building out SiriusXM’s first responsive design system. While we all worked collectively on researching and interpreting AAOS standards, building out the design library, and developer documentation, some of my specific areas of focus included defining the motion/animation guidelines for the SXM AAOS app, setting up the responsive constraints for each component and layout, building out the layouts for the Now Playing audio stage, Search, Tuning and Modals, and advising the team on OEM requirements and restrictions.

Key Goals

Create an AAOS-based component based system that mimics the functionality of SiriusXM with 360L as closely as possible. The goal was to learn the AAOS published standards, and identify where and when those standards either a) conflicted with our work, and/or b) when key interactions needed by 360L are not defined in AAOS at all.

 

The design system would be the home for specifications on recommended responsive components, page patterns, concept examples 360L-AAOS compliant screens, and calls-outs for changes made that may deviate from AAOS published standards.

Artboard – 2.png

Considerations

Unlike our previous reference design for SiriusXM with 360L, the SiriusXM Android app was designed to responsively scale to all standard screen sizes. It was also designed with UI Customization options that allow our OEM partners to closely match the look and feel of their design, which include:

  • Styles & Themes - The “look and feel” defined by colors, fonts, icons, etc

  • Layouts - The position of elements on the screen

  • Configurations - Difference in behavior for a specific OEM or vehicle

With this shift in our design approach, we knew that we would need a fully responsive design system that could be used by designers across the company to help implement a consistent app experience for any OEM. This was a huge shift from the past way of doing things, which was building components and screen renderings from scratch for each new automotive program based on the OEM’s existing UI. 

 

From the business side, this new approach would allow SiriusXM to create a consistent in-vehicle experience, that not only drove brand awareness but also provided users the full functionality of 360L regardless of the budget or resources available by the OEM to implement those features. From a design perspective, the design system would allow us to streamline the process of creating OEM instantiations by allowing designers to pull from a library of responsive components and screen templates and simply customizing the global styles and layout options based on customization choices made by the OEM client. 

We build to edit. That means, not taking any shortcuts upfront and taking the extra care to build a design system that is truly scalable, flexible, and editable.

The Design Process

Research and Prep Work

Screen Shot 2021-07-01 at 4.28.21 PM.png

We started our preparations by doing a full design inventory of the existing SiriusXM 360L experience and documenting each screen template, variants, and individual components.

The inventory was documented in a master spreadsheet that we could share with developers to indicate which component groups correspond to which layout.

Snapshot of the SiriusXM with 360L design inventory document.

We also closely studied Google's AAOS guidelines, as well as OEM programs to understand what limitations we were working with. Based on our research we had to decide whether we would follow the existing media templates or if we would create custom templates while using AAOS as a guide for best practices. Ultimately, we chose the custom approach so we could easily implement our solution natively for any of our automotive partners and include customer favorite features such as presets.

Group 16.png

When we were finally ready to start building, we evaluated several design tools for our design system to live. We have previously worked in Sketch, which was great for mocking up static screens for individual programs. However, for this project we chose to use Figma because of the collaboration features, prototyping capabilities, easy to use global styles, and advanced features such as auto-layouts.​

Screen Shot 2021-07-01 at 4.36.31 PM.png

Screenshot of our Figma design library document (cover page).

Methodology: The Benefits of Atomic Design

When it came to the methodology for building out our design system, we leaned heavily on Brad Frost’s Atomic Design. Atomic design breaks the UI of a site down into Atoms, Molecules, Organisms, Templates, and Pages. By breaking a page down into these different elements, we create a mental model that helps with constructing a UI. This helped us break away from our practice of designing static screens and helped us create a more flexible, scalable system of reusable components.

Group 15.png

Building a component based system.

By breaking down our components into atoms, it became so much easier to see which atoms can be combined or mixed or swapped in Figma to form molecules or organisms. It helps us to significantly simplify our components and see how changes flow between atomic parts and the final screen renderings for our UIs.

Simpler automotive instantiation. 

 By leaning on atomic design principles from the beginning, we were able to incorporate all of atoms and molecules into our style guide, as well as our customization guide for Automotive partners. This helped to keep our design consistent across platforms.

Streamlined, re-usable code.

Because of the flexible nature of a component based system, our dev team was able to recycle components to create the app layouts, and apply a single change that would ripple across the app instead of coding each screen individually.

Faster prototyping and editing.

By having a defined list of components, we were able to mock-up pages quickly and easily. When a change is needed, only one component is changed at a time. 

Building the Design System

The first step was to establish our core screen sizes, responsive grid, and breakpoints. We used the AAOS defined Standard screen size as our starting point to make sure that all of our components could be accommodated even in the smallest screen sizes.

We also used keylines to maintain proportional horizontal scaling of components based on screen width. Keylines specify how far an element is from the nearest margin or edge of a component, and change value based on the breakpoint. 

Group 17.png

Snapshot of the global grid guidelines defined in our style guide. 

System Controls.png

The next phase was to start building the core atoms and molecules of our design system based on the design inventory we had done. Breaking the system into the smallest definable symbols, we gave ourselves the ability to quickly replace iconography or interactive components app-wide to meet OEM instantiations and branding requirements.

Example of an atoms and molecules page from the style guide.

From there, we were able to start building “component groups”. Each group is based upon atoms and molecules defined earlier and designed to be responsive on its own. This gives us the ability to not only apply branding to these groups, but also combine groups quickly to create a custom layout, as well as add future functionality within an individual group while minimizing the impact on the rest of the page.

core_nav.gif

Example of a component group that can be dynamically scaled & updated.

Once we had laid out the building blocks, it was time to finally assemble the page patterns and templates using all of the responsive components, as well as the grids, colors, and typography rules we had defined previously. This was the most tricky section of the documentation as we had to meet AAOS minimum size and touch target requirements, while also ensuring all screens would scale responsively for each possible breakpoint. It was also important for us to build these templates in a way that was completely flexible, so that templates can be used for different content types and layout variations as opposed to designing a static screen for each possible variation.

 

This is where some of Figma’s powerful features such as auto-layout came into play. These allowed us to make sure components and layouts would scale fluidly if any of the Global rules changes.

 

Dev specs were created for each component and template to communicate to developers how we expected the layouts to scale. Establishing a tight feedback loop with the dev team was critical at this point, as our specs had to account not only for responsive breakpoints but also make sure all components flexed with changes in OEM typography and icon scale.

Group 16.2.png

In the final phase, it was time to explore how we can use micro-interactions to make the SXM in-vehicle experience feel meaningful, fluid, and easy to use. Motion orients users and invites them to interact with the experience. By indicating that something’s happening, it can also help reduce friction for the user. Our goal was to use simple animations and transitions encourage users to explore and show that the interface is responding, creating an emotional connection.

drag animation

Example of a drag animation defined for our design system.

The Results

Impact and Next Steps

Creating SiriusXM's first fully responsive design system and component library was a huge step for the design and engineering organization. The system reduced the time to delivery for our automotive-designers by over 50%, allowing them to create branded, high fidelity prototypes for our clients faster than ever. It was also the first step to building a component based application, which resulted in less development time and more streamlined QA testing.

 

The system was also used to help some of our largest automotive partners customize and implement the SiriusXM Android APK, which allowed more programs to implement the full set SiriusXM with 360L features, driving greater user engagement, content discovery, consistency across the SiriusXM experience.

More Case Studies

bottom of page