Sony Music

Solfège Design System

TL;DR

I created and led the Design System initiative at Sony Music Product Design & Engineering. From introducing the concept & purpose, defining the strategy, success metrics and roadmap, to leading my team through the creation of each component. I also helped them define the guidelines and rules of usage, and I liaised with the engineering in charge of implementing them. Thanks to our design system Solfège, we’ve not only improved the consistency of the experience and the front-end implementation, but also increased both designers & engineers productivity.

What

What do you do with a pitch, a ball, and 22 people?

If you thought ‘football’, I’d argue that it’s only gonna be football if you follow the rules of football. Otherwise, there’s an infinite combination of games that could be played with those props.

In this analogy, the design system is the game. If we only have components and no definition, no rational, no structure, no dos and don’ts, and if we have no process to enforce it, it’s only just a component library, and not a design system. It won’t create consistency, it won’t allow people to play together - or work together - as there would be no alignment amongst players. Without alignment the game is only gonna be chaos; frustrating to play and painful to watch.

A design system is a product, and its users are both designers and engineers. The mission of our design system is to set the tone for our apps, features and experiences. To provide a collection of principles and rules, as well as standardised components. As a result, using our design system should help us work together to build an intuitive and consistent experience for all our users.

I suggested the name Solfège as solfège is the name of the discipline at the core of musical theory: it covers tonality, tempo, rhythm etc... In a sense, it represents the building blocks and structure behind music and music notation. It felt like the perfect name for a music company's design system.

Why

Solfège was born from the observation that although our apps were sometimes re-using the same components, the usage of said components varied a lot. They were used in different ways that weren’t consistent. Or several components had been created to fulfil the same purpose, creating different experiences that would in fact, perform the same action.

That made both designers and engineers’ job more difficult as there was no clear process; it was a lot of copy/paste then adding a layer of customisation to match their use case. There was no centralised maintenance or tooling, and no communication about which components existed already or not.

Furthermore, for our end users, having different experiences to achieve the same outcome depending on the page or app they’re in created confusion and didn’t help increase adoption of our apps: if users have to re-learn how to use each and every one of them, it’s one less incentive to stay loyal to our Suite of apps.

We created our design system as a collection of tools, libraries, and guidelines that empower designers and engineers to build standardised apps in an efficient and productive way.

What success looks like

To ensure we’re successful in our mission, we defined what success looks like using indicators.

  • Consistency
    1. We look at the amount of occurrences of each component, because the more apps it’s used in, the more consistent we are.
  • Productivity
    1. We track the percentage of custom versus existing components that are being used in each app.

Challenges

Solfège is a standardised set of components, patterns and guidelines. Those elements constitute an experiential language that allows us to communicate meaning through our visual interface and interactions. To be used across the board, Solfège has to consider every existing use case and analyse them in order to recognise patterns that could be optimised and reused.

  • Systemic thinking
    1. To answer questions such as: how do we represent interaction? How do we represent states? How do we represent hierarchy? We first need to identify what’s an interaction, what’s a state and what’s the hierarchy. Systemic thinking means understanding the connexions between elements and how they impact one another. Identify patterns and understand that a change in one place will affect the pattern, and that to convey meaning — create a predictable experiential language — we need to be disciplined and methodical in the way we create and use our components.
  • Misconception about standards
    1. For both designers and engineers, standards come down to starting a new task or project from a set of guidelines as opposed to starting it from a blank page; some people find it helpful as they can focus more on the actual problem to solve, and some people find it difficult as they feel like they’re constrained within a box, especially when the box includes use cases from other Suite applications.
    2. It also requires to learn the tool — both our guidelines and patterns but also how Figma sophisticated component library works. The same applies to engineers having to learn how to interact with our front-end libraries. There’s a learning curve.
  • Silos
    1. Solfège is one of the design solutions to our overall Suite adoption objective. However designers & engineers who use Solfège only work in 1 app within Suite. Therefore, the adoption of other apps besides their own doesn’t obviously fit within the scope of what they immediately care about.

How

To successfully drive adoption of our design system whilst enabling consistency & productivity, I focused on 3 main themes: Collaboration, Structure and Communication.

Collaboration

It’s easier for a team to adopt a solution when their members took an active part in designing said solution.

  • Collecting requirements
    1. Designers bring up requirements from their app’s use case to our Solfège weekly ritual. We discuss whether an existing component can be used, if it requires more properties, or if a new component should be created. By involving the whole team we ensure that if similar use cases already exist, the solution will be consistent.
    2. As they implement components in the library, design System engineers connect with product engineers to understand better their current technical implementation. That way we ensure our components can be used with minimal implementation effort on their end.
  • Defining creation, update and prioritisation process
    1. We designed a clear process for creation, upgrade and review of our components. This is to ensure that everyone affected by the change will be consulted and made aware of what’s coming.
    2. Our design system product manager prioritises the implementation roadmap based on squads needs. As we provide components for each and every team, we need to juggle with priorities and offer alternative options when we don’t have capacity to implement everything within the timeline they need. For instance, squad engineers can contribute to Solfège by implementing components following the guidance of Solfège engineers. Those components will then be reviewed and added to our library. This process works as the design of those components are reviewed by the whole design team prior to implementation.
Structure

Any system needs a framework that guarantees its functioning. By defining what a healthy system requires, we’re capable of identifying how things should be done and also when we can afford to create exceptions without compromising the health of the whole system.

  • Tooling & Maintenance
    1. We have a dedicated designer in the team in charge of creating and updating components in Figma. That way we can ensure that the logic of creating properties and labelling them stays consistent. We also created a Solfège hot line Slack channel for any technical question about Figma components.
    2. The same concept exists on the engineering side: our principal engineer created documentation that explains how to interact with our front-end libraries, and a Slack channel is in place for any clarifying question.
  • Atomic Design
    1. We follow the atomic design framework: we started with standardising atomic components, then used them in more complex structures (molecules & organisms). The bigger the structure, the more options we propose, which allows for more flexibility whilst keeping the information architecture and UX consistent.
    2. From an implementation stand point, we started with implementing atoms as those are the building blocks of any other component.
  • Patterns & Flows
    1. Beyond components (atoms, molecules and organisms), Solfège provides guidelines for page templates and most common flows (like creation of an object). Those are guides and more loosely enforced, but following them ensures better consistency and therefore predictability of the interface for our users.
Communication

Creating a performant system is only going to have an impact if said system is understood and used by everybody.

  • Feedback collection
    1. We have created several channels for feedback & communication using Slack, regular office hours meetings, and a newsletter.
  • Showcase & Education
    1. We have created a Solfège app using our own Solfège components to showcase all of our components & guidelines, with examples and status updates.
    2. We have regular demos where Solfège product, design and engineers go through the requirements they collected, and the solution they implemented.
    3. We send a newsletter to update all squad members about what’s been released and what’s been worked on.