Soundstripe Design System
The Soundstripe Design System is a comprehensive framework that transforms their brand identity into a consistent and cohesive customer experience across all aspects of the product, through a set of design standards and components.
I led the creation and ongoing development of this system, collaborating closely with teams from Marketing, Product, and Engineering. My contributions involved planning, designing, and building the design language and components from the ground up. This work has resulted in a more unified product experience and significantly improved developer efficiency.
Site audit
The first step I took was to document the wide variety of styles currently in use across the Soundstripe app. The amount of variance I found wasn't surprising given the fast-paced, development-focused nature of the product's evolution. This audit helped me to better understand what was working and not working, and illustrate the need for visual and functional cohesion to the larger product team.
Color alignment
I started my standardization work by consolidating and unifying our gray colors, which at this point we had over 50 of, with token names like "light-gray-not-as-gray" or "more-grayer". We replaced this with a set of consistent, blue-toned, grays that serve our app in both light and dark modes.
Once our gray color palette was established, I went on a long journey trying to nail down our full UI color palette. Using a "brand" pink as the base, I created a full color palette across a spectrum different hues.
Using everything we had put together, we built a comprehensive set of design tokens that covered a large chunk of how we were using color across our products.
Throughout this process we were also experimenting with a lot of different color combinations. If nothing else this reminded us that this job is fun, but also gave us some ideas to put in the cookie jar for later.
Type system
The existing type system consisted of a single font family, which we wanted to keep, in a large variety of sizes. Hierarchy, spacing, and vertical rhythm hadn't been taken into account, and the result was an uneven and slightly illegible content experience. We created a type structure that could be used across the app, and set us up to transition seamlessly across device sizes.
We built Heading and Text components on top of this system, giving our development team an easy way to add and modify content. Best of all, this gave us a way to separate semantic structure and text style, leading to a more accessible and AT-friendly product.
Design tokens
To round out the foundation of our design system, we created standards and design tokens for nearly every visual aspect of our app, everything from breakpoints to z-indices. We then spent an entire sprint implementing (and testing) these new tokens, meaning that we had nearly full-scale adoption from the get go.
Seeing these implemented across the product was a huge accomplishment. It represented a ton of work from man people, and also symbolized a big step forward for the organization.
Components
With our foundation in place, we had everything we needed to design the first wave of front-end components; typical things like buttons, forms, and links, as well as UI patterns we used frequently, like playlist images and media controls.
Page templates
We also wanted to bring consistency to our page structures. A quick tour around the app revealed a wide variety of spacing and width settings across our breakpoints, which caused unnecessary headaches for both designers and developers. We created a series of templates based on page type (search, collection, admin) that we quickly turned into helpful container and grid components.
Built-in accessibility
"Showing off" a design system is a funny thing – there's so much beyond the visual consistency it brings. It has helped our team communicate better about our front-end, develop ideas faster, and even enable developers to pick up a feature ticket without needing a fully spec'd design.
One benefit stands out above the rest to me: accessibility is now embedded into our components. One prime example of this is our checkbox component, which we use everywhere for our media filters. Before the design system, these were simply styled divs; functional for some, but inaccessible to many. We updated our this component to use semantic HTML markup, add aria labels for assistive technology purposes, and create a clear focus state. The visual changes aren't that different, but it's an entirely new component behind the scenes.
