Sonos's universal configuration framework (Unicon for short) is comprised of cards, tiles, onboarding modules, helpsheets, and update tips.

It is heavily framed around a "show, don't tell" principle of communication, and is highly contextual and modular, allowing it to smartly surface the right content at the appropriate time, and chain together specific flows as necessary.

At Sonos, Unicon operates as its own separately handled sub-section of our design system, Symphony. I created and manage the Figma library of components and assets that designers use to create configuration related experiences like setting up a product, creating a stereo pair, building out a home theater system, and many other scenarios.

Highlights & Key Outcomes:

Asset Production Time Vastly Reduced

The complete asset process went from taking 9 weeks to 3 with increased accuracy and a larger, more complex asset package than initially existed.

Animated Asset Library

A reusable asset library built in Rive allowed for onboarding related assets to be used in both the app and Sonos support sites.

UX Adoption

Unicon became a “get-to-do”, giving designers increased confidence in the accuracy of their specs and increased velocity for creating new setup related flows.

Longevity

The configuration system was built with extensibility and longevity in mind, and has not required any major reset or rework for three years. The Figma library and its asset system continue to be used in its demonstrated form to this day.

Setup Systemization

A typical Unicon card is comprised of three main areas: a header that allows titles or descriptions, a canvas which is a slot for images, control mechanisms, and input fields, and a footer which allows different combinations of actions to be tied to a card.

The card above is a typical example showing body text, a product image, and a primary and secondary action.

Don't let the prior card fool you though, there are many different ways to combine the three properties to tell different setup related stories. We also have allowances for other categories of cards like smaller pop-cards which are used to initialize a flow, and cards with full-bleed backgrounds like Update Tips.

This is a non-exhaustive snapshot of where the Unicon card system lives. The different card types, headers, canvases, and footers are componentized in the library. Pre-fab product-centered cards are shown for demonstration purposes or as a jumping off point for editing.

UX Intake

These modular cards are used by the UX designers to create all the logic, flows, and conditions of setup. Accuracy is paramount because this is the primary way engineers are engaging with their understanding of the design intent.

Video

Video is a significant area of Setup that I steer. Each product has a fully rendered 3D video that is used during setup - sequences are smartly targeted and shown depending on the part of the flow you're in.

As the primary point of contact that manages the external vendor creating the videos, I will storyboard out the videos, work with Industrial design and the vendor to articulate how hardware should appear, provide feedback on videos, and be the ultimate approver before video assets become the basis from which any stills used within the app are derived.

Shown here is a cropped example of the kind of storyboarding I'll work on with the vendor.

When working on these I'll be looking for consistency of animation across the portfolio, guiding proposals for net-new animations like NFC (near field communication) behavior, and making sure there is not any unnecessary sequences added into the product as this can have a detrimental effect on how the code knows to call a certain sequence.

Rive Animations

As part of my work with Unicon, I was tasked with creating a series of onboarding modules - visual tours that were created to provide users with education on how to use their speakers, understand its functionality, and get the most out of it.

To create these I had to learn a new tool, Rive, which is popular for 2D animation in games and is notably extremely performant in its file size and highly flexible in where it can be used live.

If you'd like to go more in-depth on some of the different animations I made for hardware education, check out the Sonos Voice Control Tour or Roam Product Tour.

Starting from one product, I established a consistent visual framework for how products of different categories would all tell onboarding stories with a singular visual language. As the manager of all the different hardware assets, this allowed me to create asset dependencies that would be able to recontextualize product imagery we'd be guaranteed to have for other use cases, minimizing maintenance effort that would come from creating a bespoke treatment for each feature visual.

An additional example of visual consistency regardless of product size. In our newest generation of products we went from capacitive touch buttons to a swipe trough, which led to a new visual paradigm for how we educate users on adjusting volume.

One of Rive's great strengths is that it's able to be used on both our mobile apps and our web properties. The same animations that I created for hardware education were also utilized in Sonos User Guide.

If you're interested, you can also read the case study on how I redesigned the Sonos User Guide.

Asset Management

Unicon is powered by over 2000 images - this covers the entire portfolio and many, many different use cases like home theater, stereo bonding, button press combinations, and LED light indicators.

These master files come in from the vendor, and certain asset types are hand-posed by me in AfterEffects with Element3D.

To help aid the understanding and expectations of an asset class, I created clear guidance on what every asset's export size should be, its use case, and example appearance areas. This was repeated across dozens of different asset classes that all had specific guidance and display expectations.

As part of minimizing any error, this meant we needed a self-referential library. This meant that it needed to be built in such a way that one asset would push out to as many of its referenced visual scenarios as possible.

When working with hardware, at any point in the program there can be some kind of change to the color, material, finish, or other appearance factor of a product. We've had times where the logo color changed, the glossiness changed, and the overall hue adjusted.

Before I entered this would've been a manual process without any componentized relationship, I was able to remedy this and make component dependencies derived from a single master file.

Maximizing Asset Accuracy

Accuracy of assets was extremely important. We had certain classes of assets that were actually built from compositing, and this was very easy to get wrong.

There are creative liberties you might need to take with the scale of products, and you have to be certain that wherever a product is placed will be able to land in highlight zones, directly underneath the TV, or purposefully appear behind another product where it can be seen such as in dual sub configurations.

I created layout and sizing guidance that could be used to visualize the full portfolio, test in advance, validate the scale relative to other products, and verify that same products of different colors didn't change in size.

This is a simpler view for a simpler 2.1 setup - these layout guidances needed to be created for multiple possible configuration types such as: soundbar only, soundbar + sub, and soundbar + surrounds. + sub.

Proofing Sheet

To further make sure I was delivering assets and implementing them correctly, I created a Proofing Checklist - a visual table for previewing an asset's name, use case, and size guidance. Different proofing sheets were made for our full product portfolio in categories such as: all-in-ones, soundbars, subwoofers, components, and portable, all of which have different combinations of allowed assets.

To top it off, each proofing checklist comes with an export sheet. We have a large mix of assets that are in their @2x form, others that are reduced in size to fit into the design system, but the developers need everything at one size.

It was very easy to get confused figuring out which assets needed to be divided or doubled in their size pre export, and this helped prevent any confusion.

Thanks for viewing!

If you like what you're seeing and want to talk about design systems, I'd love to hear from you!