We’re kicking off the New Year with a seventh round of your favorite Q&A! After crowd-sourcing many thoughtful questions, we picked four key topics you’re asking about, time and time again. From prioritizing workloads to governing design systems, choosing colors to nailing product design processes — designers in our community are sharing their eclectic wisdom with you! To top it off with a lick of paint, we have colorful portraits illustrated by Simon Child.
How do you govern your design system?
Here at Spotify, our family of design systems is known as Encore. At the heart of Encore’s governance is our system of systems model (affectionately referred to as the “onion model”). This model delineates and distributes ownership of different types of components, tokens, and use cases across the company. We’ve blogged about it externally before, and we are in the process of evolving this model to better serve our needs moving forward.
There are many different aspects of our governance; I’ll focus on a couple that might be most interesting to you: how we form new local systems and our contribution inbox.
Forming new local systems
A potential risk with the system-of-systems model is that every team would create their own local system. This creates a lot of complexity, hinders component sharing, and risks ownership and maintenance lapses. The central Encore team created a process and guidelines for when and how a local system should be created.
For example, when a team reaches out with interest in creating a local system, we send them this list of requirements they must satisfy:
Name: A local system name following the format
“Encore [ product or signifier ] [platform]”,
e.g., “Encore Ad Studio Web”
Components: At least one component unique to your design system
Documentation: Every component should be documented on our design system’s internal website. If you don't do this, we require you to document at least one component to launch, and we'll ask you to commit to documenting this component in the near future.
Designs: Every component should be available in a new Figma toolkit created for your local system.
Consumers: At least two products that plan to consume your system have been identified
Accessibility: Design and code satisfies WCAG 2.1 AA guidelines
Browser compatibility: Same list of supported browsers (or more) as Encore Web
Tokens: Use tokens for all colors, spacer sizes, and constant values
Typescript support: Component props should be typed
Versioning: Semantic versioning should be used, and follow our definition of a “breaking change”
Ongoing support plan: Must stay within one major version of the latest Encore release, and have a documented plan for supporting consumers.
Ownership: A single squad must be accountable for owning and maintaining code, designs, and documentation for the local system
When a team understands the work involved in creating a local system (especially in terms of ownership and maintenance), they can make an informed decision on if it’s really right for them. Often, they will decide to just use our core Encore Web system. This keeps Encore up-to-date and streamlined.
Contribution inbox
Contributions from product teams are a vital element to Encore, and we encourage them. However, we need to strike a balance between letting contributions flow in and keeping the quality bar of components and tokens at the right level. For example, we want to ensure everything in Encore is WCAG 2.1 AA compliant and localizable. We want to make the process clear and as self-service as possible. This way, product teams know up-front what they need to do to have something accepted in Encore, and we don’t have to spend as much time fielding questions and assisting potential contributors.
As an example, the Encore Web contribution flow in an ideal case is this:
Contributor consults our contribution Decision Tree we built in Figma. This guides them all the way from “I’ve spotted a potential pattern” through a series of choices to help them decide if it’s a thing that should live in Encore.
They file a card using a template in our Contribution Intake Trello. This asks them a series of questions about the contribution proposal.
A member of the Encore Web team is assigned as a peer reviewer. They go through the proposal to make sure it meets all the quality bars and either ask the contributor to make modifications or accept it.
The contribution is added to our backlog and Jira issues are created.
Contribution shipped as part of Encore. Our design system and contributor community grow.
— Seth Orr, UX Design Program Manager
How do you prioritize your work tasks so you work on what's most important?
The only constant is change, and surprise, surprise, priorities will always change. So how do you keep up and feel confident that you’re working on the right things at any given time? Well, my secret is to continuously Review, Reflect, and Revise.
Currently I have a 45-minute “Do Not Book” event on my calendar at the beginning of every week. During this time, I walk through the below steps so I can begin each week feeling confident that I’m working on what is truly a priority.
The 3 Rs – Review, Reflect, and Revise
Review: What am I doing? What does my workload currently look like?
Something that helps me do this is visualizing my work so I clearly see everything on my plate. You can do this by creating a simple kanban board with To Do; Doing; Done).
Example of my own Kanban board
2. Reflect: Take the time to step back and reflect on your workload.
a. Looking at the current state, I try to understand what is possible for me.
i. What is my capacity? (How much time do I really have to work? Are there holidays? Do I have a week of non-stop meetings?)
ii. What is sustainable? (I set myself work-in-progress limits so I don’t risk dropping balls or sacrificing the quality of my work.)
2. Revise: Am I working on the highest value and impact items?
a. What is the urgency? (What are the real deadlines?; What is the impact if it doesn’t get done in time?)
b. What is the value? What does this add in the bigger picture?
Example of a prioritization exercise
Doing these steps helps me to communicate with managers, teams, and stakeholders. I find that I’m able to fully articulate what I’m working on, the reason it is a priority, and what my capacity is. This articulation helps others understand where their request lands and what would need to change for me to prioritize.
So, make some time for yourself to Review, Reflect, and Revise so you can also be confident you’re working on what is truly most important.
— Kimberley Miller, Agile Coach II
How do you choose colors?
Within the visual merchandising team, one of my focus areas is bespoke artwork creation for music playlists. I frame this work as a mix of branding and editorial design within the context of our platform, and I choose colors based on this principle as well.
Some playlists not only exist in the product, they are also marketed through various channels outside of the product — billboards, posters, social media… the list goes on. It’s important that we keep a good balance of the playlist brand and the Spotify voice. We think about our use of color often with these applications in mind.
Since Spotify has a very robust and specific color system, we have a wide range of colors to choose from. Most of the time I start with a few core colors as the primary palette to set the tone for the artwork. Once the main tone is set, I can fine-tune the rest of the palette.
Much of my work is about visually expressing genres, moods, and energies of musical content, so I try to think about colors by listening to the music and understanding the audience of the genre. Does the content feel more tonal? Muted? Or high contrast? I am often able to choose the secondary colors to complement the primary palette that way.
Because our work spans many different cultures and markets, another important thing that I try to keep in mind while designing is the specific culture of each market/region. Through editors’ briefs and user research, we can usually find detailed insights into local visual cultures — these often include color associations. Bright Red could be a popular color for a certain culture but taboo for another. Using the right color combination is crucial for creating authentic, localized work.
As I design and apply the colors to different scenarios and formats, I’m able to tweak a bit further, and find pairings or combinations within the palette. Eventually I can get to a place where the whole design system feels right, and I can almost hear the music coming from the cover!
— Elsa Chiao, Senior Art Director
Can you explain your product design process from zero to release?
Yes! Well, kind of. As designers, we like being able to fit things into nice little neat boxes, but when it comes to the process, it’s rarely as neat and orderly as we might like.
There are many tried and true frameworks out there to help guide a process that is problem- and hypothesis-led, insight-informed, creative, and all the while efficient. But (and it’s a big but) the real answer is that “the process” can take many forms depending on the context, confidence, and new information gathered along the way. It’s rarely predictable or linear. Being able to adapt to new information and help your team adjust accordingly is all part of the process.
So, with those caveats out of the way, here’s a high-level step-by-step for providing new product value to users…
Understand your goal: First of all you need to understand what you’re aiming for. For us at Spotify, this is typically informed by our company and mission strategy (a mission is a purpose-led part of Spotify).
Define your problem: Understand who you are designing for and what their needs are as it relates to your goal. Work with your product counterparts and plan to spend some time with this, including insights and data if you can get it, and running research if needed. Be as detailed as you can – it’ll pay dividends later.
Frame the opportunity space: Define your beliefs, hypotheses, and contextualize the opportunity. This might include referring to, or generating, guiding principles, mapping user flows, or comparative product studies.
Start exploring solutions: Try to break down and organize the parts of the experience that need your head (your thinking) and hand (your craft), and consider starting with the most foundational, riskiest or contentious parts first before getting drawn into details. Push yourself to explore many solutions before developing the belief that you’ve got the right solution and remember that the more accurate your designs, the more confidence it looks like you have in it. Even if you are confident in your solution, try to remember that you could easily be wrong, and that because users are never wrong, you can learn through them by testing.
Test and learn: It’s time to learn about how well your solution fits the problem. Define what questions you have and set out a plan for learning. Use qualitative research to learn about why users need or want something, and if you can, run quantitative tests to learn about what users are really interacting with. These insights will help inform improvements to make before rolling out the feature to more users.
Ship it. You now have an experience that you’re confident in, you’ve brought your team along the journey, UX writers have made your design work twice as good and you’ve worked with engineering to understand technical challenges — now spec it, annotate it, work with engineering to implement it and ship it to your users!
— Jack Maxwell, Staff Designer
Credits
Spotify Design Team
We're a cross-disciplinary team of people who love to create great experiences and make meaningful connections between listeners and creators.
