On Theme: Design Systems in Depth

Bye Purple! A redesign powered by local & global design system layers at Spotify, with Smith Schwartz & Tyce Clee — #09

• Elyse Holladay • Season 1 • Episode 9

Share episode

📲 Text the show your thoughts!

Spotify’s ad platform just got a serious glow-up, and Smith and Tyce are here to tell us how they pulled it off. Smith Schwartz, Product Design Manager, and Tyce Clee, Engineering Manager, walk us through the redesign of Spotify Ads Manager—why it was needed, how they used design systems to make it happen, and what it took to get buy-in. Smith and Tyce tell us about the shift from a playful UI to a more data-dense, enterprise-friendly experience, how their local design system worked alongside Spotify’s global Encore system, and why storytelling (not just metrics) is key to selling design system work internally. Plus, how a simple name like "Bye Purple" helped them drive alignment and make the redesign a company-wide priority.

💖 On Theme is a brand new podcast, so if you like what you're hearing, please hit subscribe and sign up at designsystemsontheme.com!

Links & References



🎨🎟️ Into Design Systems is May 25-28
Get your ticket at intodesignsystems.com/ontheme

Into Design Systems is back with their annual virtual conference, May 28-30, 2025. Get your ticket now for three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. 

Smith Schwartz:

Yeah, we've invested a lot in frameworks and patterns this cycle. We've invested a lot in content design and content frameworks and tone of voice. And how does the tone of voice impact our visual presentation? And thinking about information architecture, thinking about user journeys and really getting into, you know, the gnarlier, meatier, bleeding edge of what a design systems team typically gets to do, we get to do, because we're built upon Encore. Because we have that strong foundation to stand on, we're able to go a little further and deeper into the reaches that a typical design systems team wouldn't get to do. Right now we're in the midst of some really meaty page layout, information architecture, problems to solve at the systems level. It's really a, a pretty fantastic vantage point to sit from, and I'm super excited about that work.

Elyse:

This is On Theme, Design Systems in Depth, and I'm Elyse Holladay. Together, we'll be exploring how successful design systems get built, maintained, and deliver impact. Design systems is due for a major reinvention moment, and I want to share what's working from design system practitioners out there forging the way. As you listen, text the show with your thoughts, aha moments, and questions by clicking the text link in the show notes. Before we begin, a quick thank you and word from our generous sponsor, Into Design Systems. Into Design Systems is back with their annual virtual conference, May 28 30, 2025. Visit intodesignsystems. com slash ontheme to get your ticket to three days of practical, hands on sessions showing the what, why, and how of design systems. This year, the conference is focused on developer handoff, accessibility, multi brand theming, and governance. You'll get hands on knowledge you can put to use at work immediately, files and resources to take away, and hear from very well known industry speakers. Get your ticket at intodesignsystems. com slash on theme, and I'll see you at the conference in May. All right, let's dive into the show. Today on the show, I have Smith and Tyce from Spotify who are gonna share with us a really exciting project. Smith is a product design manager at Spotify based in Kentucky, working on a design team positioned horizontally across the advertising business. So they work on the self-service ad booking tool, Spotify Ads Manager, which is what we're gonna talk about today. They also own their local design system, and we will definitely be talking about that today. Smith, thanks for coming to hang out.

Smith Schwartz:

Hey Elyse, thanks for having me.

Elyse:

For sure. And Tyce, you're an engineering manager, because you have an engineering background, you can talk to us a little bit about the tech setup for Spotify's design system and your local design system. Thanks for coming on the show.

Tyce Clee:

Thank you for having us.

Elyse:

Smith, we've known each other for a really long time, I think we've both seen a lot of changes in the design system space and shifts in the way that we design and build UI. Um, and I'm just so excited to reconnect and get back with you and talk about this project. Tell us a little bit about your role. You're a product design manager and this project was also working with the design system. So tell us about your role and your product that you own.

Smith Schwartz:

Yeah, so I'm a Product Design Manager in Ads business unit. My team is essentially a platform design team. Some of the designers are working on the design system and some are working on other capabilities. We have a parent design system called Encore, which you've probably heard about. And there is Encore Web, which we use to build our product. But our product started, in about 2017 and at that time it was called Ad Studio, so different name. You know, one of Spotify's ethos is to be playful, and to have this like spirited movement, and, our, our UI often reflects that in the consumer experience. And it was reflective in our Ads Manager experience as well. This project was part of a rebrand and to really signify that our product has grown up in the market after all these years. In the beginning it was like, artists promoting their music, podcasters promoting their podcasts, and now we are really a full fledged ad platform on the likes of any other ad platform out there, where you would go and spend many hundreds of thousands, if not millions of dollars, on your next ad campaign. And so we needed our UI to reflect the sea change of our business, and how we've matured, how we've essentially grown up, but also the needs of our users. That playful, spirited, you know, themed UI was not reflective of what our customer's needs were. We know, for instance, drilling down into details, that our customers are typically using a 13 inch Dell laptop. They're buying ads on Spotify, on TikTok, on Snapchat, on Meta, on Google, all at the same time in different tabs. They're very busy, trying to get through all of these like intense multi-step workflows on all of the different platforms at the same time. And so that playful part of Spotify didn't quite serve them. They needed data density, a more typical B2B design ethos, to support their needs. And so this redesign really encapsulates that. We spent pretty much all of 2024 working on this. And we used our design system as a delivery method, because that's the only way we're going to get through a sweeping change this large, was to be able to touch every surface through tokens and through layout themes and different values to deliver that really, really

quickly

Smith Schwartz:

to our users.

Elyse:

Broadly, how big is Spotify? And the Encore design system team?

Smith Schwartz:

Spotify's about, oh, don't quote me, but it's about 8,000 people, I think, worldwide. I think design's around 300 globally. My team is seven designers. For the redesign we would have at any given point, five to six designers working on this, some who were on my team, other others who report to other people. Our philosophy here was to bring the right people with the right skillset, with the right domain knowledge to come and work on any given project at a given time. So there was a lot of flexibility built into that system. And I also have a really strong point of view that design systems is something that folks should do tours of duty onto, essentially. Like we should rotate folks in and out. It's almost like in the same way that everybody should work a customer service job at some point in their lives to build that empathy and to understand what that's like, you know, every designer should contribute to the design system in different ways. And so we try to live that value on our team.

Elyse:

Yeah, strong agree. So Tyce, how did you end up working on this project?

Tyce Clee:

That's a good question. I've moved around Spotify a little bit, over the years and then physically moving from the US back to Australia kind of popped me into a team that was close to Smith and, what her team were doing. And then eventually at the beginning of, 2024, we ended up on the same team, which is great. It's very meta to go from a centralized platform team for the entire company, creating a concept of local systems and then to land yourself in the team that is owning and maintaining the most popular and beneficial local system. I feel very lucky, and it is refreshing and I would say very, very healthy to go from distributing a core system for so many years and being just so deep in that and then being on the other side of the coin, uh, supporting feature teams, which move very quickly and, let's just say patience isn't exactly a virtue when you've got deadlines, right? I would highly recommend it for anyone that's been working on a core team for years, take a break, go out there and embed with another team. Experience life and the exhilaration that comes from launching something that people actually see now, not like months from now. It really gives you empathy and it puts things into context, it's given me a whole new lease on design system thinking life.

Elyse:

It really does. Working on the actual product really makes you, have a different opinion on the work that you do on the design system. Those little pains and paper cuts really add up and you just never see that stuff unless you get in there yourself and you're building some product yourself. So, yes, fully endorse. So this, this project that we're gonna dive into was a redesign of Spotify ads manager. And you were doing this redesign with both a local design system and with Encore, your global design system. What was the goal of this project? Why did you decide to do it from a business perspective? And, what did you actually have to deliver?

Smith Schwartz:

Yeah, the reason why the time was right for this is our product had been very home spun. Like, oh, let's build this, oh, let's build this. So like, like any kind of legacy software product it's from 2017, not that legacy, but we knew that we had super big and ambitious business goals we needed to reach, but we weren't gonna reach those, we weren't gonna be able to design and release features at scale with the way our current app was set up and laid out. And so this was really an investment here, not only in the look and feel and upgrading that design, but helping our teams, you know, release it, scale and release efficiently. And so it was kind of twofold. Let's make it look better. Rebrand, rename, update the colors, update the themeing. But then there's also this component of, okay, now in 2025, how do we go fast? How do we make decisions that are logical, that are going to make sense to our customers and that are gonna scale our business really quickly? It was called Bye Purple because our primary brand color in the old design was this, it was actually technically Violet DCE 75. But it's purple. And, and we've rebranded, Purple doesn't elicit Spotify, right? And so, we've rebranded to a green, it's a little bit more of a darker grownup money green than, than the primary Spotify brand color. But, yeah, we, we've come much closer to the consumer brand in our themeing and our branding for this product, which is great.

Tyce Clee:

And I think that like giving it that name really helped us get work done. I remember multiple times leadership, and I'm talking like director level people saying, oh, is this part of Bye Purple? And I go, yeah. And they're like, okay. Like that was just awesome.

Elyse:

Tyce, you told me, in, when we were chatting in the pre-show, that you were on the core design system team. Smith was just saying you're using the design system as part of this redesign, part of this rebrand. Can you tell us about the kind of system of systems set up that you have with Encore, and the way that you were using it on this project?

Tyce Clee:

Sure. So when we started Encore a few years ago, in the beginning it was born out of another older, style guide, pattern library type thing that we're all familiar with. So we rebranded that and distributed it as the first version of Encore Web. And as we did that, we realized that because Spotify is so large and has so many different products within it, as a lot of bigger companies, I guess have, it wasn't fit for purpose everywhere. And when it was close to being fit for purpose, but not quite there, we were finding that people were modifying. Maybe doing the same thing over and over again, whether it was something simple, like reducing padding on a type component or, something more significant, like applying a different look and feel to all of the components and then re-exporting. So after doing some investigation, we realized that there were certain pockets of the org doing the same thing differently. That's where the concept of local systems for us at Spotify came up. Our execution was to invite those areas of the org into the Encore space. So we, you know, we pitched this to product teams that were very active. So at the time there were a couple of teams that stood up what we call local systems. Ads was one of the biggest contributors, probably the most active, and also the most dedicated to maintaining the system. Encore said, come live with us. We'll give you a home in this repository, in this Figma toolkit. Obviously you'll get all of our stuff, but then we will, you know, bless the ability to make the adjustments you want to make, and then you can use our distribution mechanism to get that back to your corner of the org. I think Ads is one of the biggest success stories, where people like Smith from Design and some other engineering leaders realized that what was being born was almost like an enterprise version of Encore. So things were a little tighter, things were a bit more condensed. We had people doing repetitive tasks, as Smith mentioned, where real estate was a commodity. That's not the same as our front door websites that are big and bold and expressive. So it allowed us to learn a lot about where the system is useful for the bulk of the company, but then there are certain pockets where it just wasn't satisfying the need, and needed some adjustments to become useful again.

Elyse:

We say, oh, B2B design is boring, but the reality is, this is a tool somebody's using every single day. They don't want the mental overhead of all of these slow animations or big things getting in their way. Like they have a literal job to do. Um, and it really is different than what you might need on the consumer facing side or on the marketing website side. You were also doing a lot of efforts to change the Ad Manager to improve the way that it was using the design system. There's an engineering component to that as well?

Smith Schwartz:

So the first big release, we built upon something that Encore had built called Layout Themes. And essentially what this is, is all the padding, all the margins all, and the type scale. that gives you, the sizing and spacing on any given surface. This also enforces great code hygiene because you can't use hard coded values. We're actually the first product at Spotify to support both dark and light mode, which is really exciting, and we can only do that because we're using layout themes. And so there is a decent amount of work to go in and clean the CSS everywhere, and clean all of the code that had hard coded values, and get it using tokens, and using all the right values there. And now things work and it makes those subsequent releases even faster. Like we were able to fast follow with dark mode, without a ton of design or engineering effort there, because we invested in getting our color theme, getting it straight from the start.

Elyse:

How long would you say that took, that sort of cleanup process?

Smith Schwartz:

First big release was about a six month cycle and that was, you know, with any big company there's interesting people dynamics that are happening too. We had come off the heels of a big reorg, and of course, there's bumps in the road getting started. This is something that I personally had worked on for three years to bring to fruition. Tyce had been a partner in the beginning, of even like, standing up a local system three years ago. But it has been a long road of advocating for engineering resources and getting buy in from ever changing leadership and executives, and getting the right folks to believe in this work, and to get it going. And we got super lucky that it was Tyce and his team because there was a lot of design system experience, not only from Tyce, but the engineers on his team, a lot of really amazing front end acumen there, and folks who really got it and cared. And so, really impressed and proud that the engineering team was able to come on board so quickly, understand what's going on, and execute on a huge effort of getting all of the layout theming updated, getting the color theming updated, and really having that like big, exciting moment. And it's like, hey, we've rebranded, we've renamed. All the URL structures had to be changed. All of the navigation structures had to be changed. You know, when you change a name, like that, it sounds like a small thing, but really in the back end it's a pain in the neck. And so there was a ton of like very detailed work that went into this. On the back half of the year we invested in upgrading and updating a lot of UX patterns in some of our key surfaces, building more new components, and more traditional kind of design systems releases. Um, and so really now that we've made this huge investment through the course of this last year, we've got a very robust system that covers a good portion of what we do. Now I feel like we're able to jump into some of the fun things, like thinking about inter-page navigation, thinking about, you know, what are the new things that we're going to be doing? My goal for this team is for us to be forward facing as opposed to reflective. Let's think about what we're going to need and build that first.

Elyse:

Yeah, I know. It is such a common refrain in design systems to be like, well, we need to do all this foundational work first, and then it will be easy to do the cool stuff, right? Like if we have the tokens, if we have all this foundational setup, then it will be really great and easy and nice to build all these new things that we need. And that is true, which is why we're always going on about it, because it is true. But from the perspective of the business, that can also often be a very hard sell. I wanna go back to this because you mentioned that you've been kind of on that, selling that for multiple years. Talk to me about some of those conversations, some of the things that had to align from the business perspective to be able to actually get the resources—

Smith Schwartz:

Yeah.

Elyse:

—to do that. Because I feel like a lot of times you hear design system practitioners being like, I can't get buy-in. I'm never gonna get the time and resources to do that, or to go back and do that foundational work. And even in product design, it's like, nobody's ever gonna let us take the time and go do the big redesign, even though we know that once we get all that foundational set up done, and like, get the tokens in, and get it nice and cleaned up, then everything else is so much easier later. But how do you talk to your business partners about that?

Smith Schwartz:

Yeah, getting a redesign on board is a feat. It's never something anybody wants to prioritize. But I think we were at that point, and we had a VP level leadership change. When the new leadership came, there was a lot of frustration with our current UI. There was a lot of feedback given. And so, you know, not just me, many of us working together to advocate for this change and the redesign to happen. The first rule of redesign is you don't call it a redesign. You pitch it as an investment in systems and scale. You pitch it as a visual refresh, use different words to make people more comfortable. And so that's definitely one aspect here.

Elyse:

I can get some bonus, bonus user research in there about how the UX isn't letting your customers spend money with you.

Smith Schwartz:

Exactly.

Elyse:

And everybody loves that.

Smith Schwartz:

You tie it to the business goals, right? As designers, we know what we're trying to achieve. We know the roadblocks in front of us, but the business doesn't care about that. They don't care about design values and design quality. They just want it to look great, and work great for customers, and they want customers to come in and feel really comfortable spending money. And so if we can hypothesize and strategize that investing here is going to make it easier for that to happen, which we did, then we can get the investment at scale. It was just a matter of continuing to beat that drum, making some really big bets, and getting super lucky that we had a great engineering team to come in and execute. Like, it could gone sideways in a bunch of different ways, but we're really lucky that it didn't.

Tyce Clee:

I gotta jump in Elyse, just really briefly about the importance of design leaders that go to bat. Yes, we were positioned well. We did have a great engineering team to execute on this. But Smith's work for the years leading up to that, enabled that to happen, right? So like at every All Hands, every Slack post, every opportunity to talk about incremental wins, Smith has this unique talent of being able to find the right place and the right vernacular to celebrate that stuff. Which means it's always in the limelight, so it's ever present. So then that enabled us to come in last year and execute on it. The two words Bye Purple I noticed this immediately, were like a household set of words, thanks to Smith and her design team really hammering it in over the years. So I had to jump in and add that extra color there, because a lot of that is unseen. It doesn't get the limelight that it deserves, I think. So it's worth calling out here in this public forum.

Smith Schwartz:

Oh, that's so nice. And we were able to get this work prioritized as our P zero for the ads business. So it wasn't just like a high priority thing, it was like THE high priority thing for Spotify Ads Manager. And so it was easy to pull rank when, making tough calls of like, are we gonna work on X or Y? Well, this is part of Bye Purple, this is not, and so getting that prioritization really helped us as well.

Elyse:

Yeah, I love the shorthand, like the idea of having a project and a vision. I think that that's something that anybody can take away, right? Being able to tie everybody together under a shared language umbrella and just say, this is what we're working on, everything is related to this. And that actually is quite challenging, to paint a vision for people where they understand how and why some work is gonna relate, or not relate, and why it actually matters to them. And to do that for a big project like this, really, really valuable. But also, you know, I, I just wanna say again, like what you were talking about Tyce, with referencing successes that have to do with the design system from the product side. Smith, you're doing that on the actual like product side, which is incredible. But for design system practitioners listening, this has come up a number of times on the podcast already. This idea of talking and storytelling, in a different and celebratory way about the design system. I know we got in a real, like, moment around metrics for design systems over the past couple years. We love a metric. That's great. We love an ROI calculation. We love a component stat. But people like stories. And your leadership likes, I mean, sure, they like a metric too, but they're human. They relate to a story. When you can have the value of that foundational work that you've been doing, be called out, be highlighted, be referenced. So it's kind of always there on people's minds, on the tip of their tongue. It's so easy to let that stuff just be under the surface. What is it that they say about good design? It's invisible. When you have a good design system set up, it is invisible. Your product teams are just doing the thing.

Smith Schwartz:

Mm-hmm.

Elyse:

And I feel like that's a real marker of success for a system, but it's also really powerful as the design system team or as the product owner to just call that out. Like, we were able to use this, this actually helped us go faster. And I'm hearing over and over from design system practitioners who are successful, and successful in their organizations, that is a thing that they are doing.

Smith Schwartz:

Yeah, and like tying it to trust was a big thing for us. If you think about design, and how do you design for trust, the one story that I've told over and over to whoever will listen to me is like, if you think about it, Elyse, I know you've used cooking metaphors a lot in your previous work. But think about it like buying a refrigerator for your food. And that handle is stuck way up at the top, and it's, it feels like it might fall off. It's feeling cheap. It's like not opening the door. You might know cognitively that the temperature of your food is not affected. It's still running. It's still working, which is why you bought the thing. But that, loose, uncomfortable handle makes you doubt the quality of how the refrigerator is working. And so those kinds of stories are the way that I was talking about this for so long to get that buy-in. Because you need to show the quality of the thing that you are delivering. And if, if our front door looks terrible, then nobody's gonna walk inside and actually spend their money.

Elyse:

So the Spotify Ads manager product was already using Encore even before this redesign, and then there was also this layer of the local system. Am I getting that right? Tyce, can you share with us what, what was that setup? How did those things kind of layer?

Tyce Clee:

So the way that local systems are used, the idea is, that when the core system works, let's say a button or a type component or a dialogue or whatever you need, if no modification is needed, you will, quite literally fetch that from the core system. So in our case, you are fetching that from the root of the npm package. And then in Figma, you're getting that from that core toolkit. Now when there is a modification needed that you think will be used more often than not, with the local system set up, you can import that component, apply your changes. So let's say it's reducing padding on something or something more significant where you are compiling small components into more of a pattern or a larger set of components, and then you're giving that a name, and then redistributing that for your part of org. If you're a front end engineer working on our product, you might be pulling components from the core system. You might be pulling it from the local system. But it doesn't make a huge difference, because at the end of the day, they're still pulling it from a system. And we know as people that work on design systems, that the more often an engineer or designer can pull from the system, the less often they're having to create something bespoke, which helps us all move faster. And what we've found is that, it's like, does it exist in the core system? If yes, use it. Does it exist in the local system? If yes, use it. Is it something that other teams would want and use in this space? And then the fourth option is, no, it's just for my one route. And then we go, oh God, really? What is it?

Elyse:

You mean I have to build UI?

Tyce Clee:

And they're like, wow, I'm actually writing code today, you know, it's like, so really like the, the decision tree is meant to supercharge getting to production. And again, these are feature teams. They need to move quickly. They do have deadlines. They have many things to be working on that provide value, for our business. So if we can reduce the amount of time that they're writing raw code. Instead, let them focus on things like small manipulations, prop manipulations, and layouts, they can move so much faster. The work that we did last year around this Bye Purple initiative, all of that work has now meant that here in 2025, we're about to embark on a responsive journey. Which is another thing that some teams might come across, especially with enterprise products, it's not thought about in the beginning. It turns out, people use enterprise products, they also have phones. What a concept. Maybe they're on the go, maybe—

Elyse:

They don't, they don't do their business work on their phone, surely not.

Tyce Clee:

Never, they're never, they're never like, having lunch and just need to check on a report. Like, what are you talking about? So that's a great opportunity for us this year. Here's the good news. Because of that work last year, this year, we don't need to do as much implementation. We don't need to scour through the app and make sure that, Encore is being used everywhere and tokens are being used. The work for us to do can be more creative. We can think of what are the most popular routes on a mobile device. So because of that prep, we're very excited this year to spend more time with design. So all these things that as design systems practitioners, we espouse and talk about and get really excited at conferences about is actually happening here, which is a bit of a pinch yourself moment, but it does mean that we can move more quickly. Now, the caveat here is we can't take our foot off the pedal of reminding the business why we're able to move quickly. One of the biggest ways to do that is to continually reinforce that the reason why we can move more quickly is because we've implemented the system. That means you need to maintain the system. Which, I think that's where we're headed in the next few years for design system community talk, is how do you maintain that which we have achieved.

Elyse:

It's, it's the storytelling. It really is. And again, metrics, great. But it's exactly what we were just talking about, getting up at all hands, talking about it, referencing how this is helping a product team, reminding people like, there's a whole class of problems that we don't have to deal with because we have this now.

Tyce Clee:

If anyone says anything positive, like, oh wow, I could do X because of Encore. I get everyone in my team to ask that person, can I write that down? Can I quote you?

Elyse:

Mm-hmm. Oh yeah, that's going in the Slack, that's going in kudos, that's going in the brag doc, that's going in the performance review.

Tyce Clee:

Yeah, a hundred percent. So anyone out there that's like, oh, how do I build that narrative? I'll say, first and foremost, go and talk to people. Go and talk to the teams that are using this stuff. And the second you get any feedback, positive or negative, ask for it. Ask, can I write that down? Can I use that? If it's constructive feedback, that might give you the justification to do something that you might not have done. And if it's positive, wave that flag super duper high.

Elyse:

Absolutely. And sometimes I think it's just saying it and it becomes true a little bit.

Tyce Clee:

Willing it into existence.

Elyse:

Really, truly, truly, like sometimes it's just as simple as, hey, did you know that, the design system is 40% of the components used in this product? I'm just saying that out loud somewhere. Hey, the design system really enabled this team. And I mean, I'm not lying, like making shit up. But, you know, I'm, I'm going out there and saying it sometimes even when I don't have a really exciting, groundbreaking project or, piece of feedback. It's just about visibility. You know, I'm seeing PRS come across, from the engineers. I'm seeing what the designers are doing. I'm seeing where it is and isn't working. And when I see something working, sometimes I'm just like, Hey, this is going great y'all. And just putting it out there. And sometimes I think we think that it is self-evident that people know that and that they see that and it's just not.

Smith Schwartz:

No, it's not

Tyce Clee:

One thing, they worked on a Chrome extension where it would highlight where Encore components are being used in a web application, which is a really neat concept. But the way they did it, I thought was genius. And I remember a product manager there did a before and after with the desktop team, before and after they had mass adoption. And afterwards you hit this button and it just highlights the entire app. And it's so convincing when you look at that and you go, whoa, that is like 90 something percent of pixels, completely powered by the system. That visual is such a convincing method to be like, did you know?

Elyse:

Yeah. So we've been talking about the engineering side. But Smith, what about from the design side? How are you talking about the way that both Encore, the global design system and your local design system, have been supporting your designers. And how that has been improving the product that your product designers are working on?

Smith Schwartz:

Yeah, sometimes I'm really frustrated with the term design systems. It's a little bit of a misnomer. It's a noun and really it should be a verb. It's a thing that we do. It's a way of working. It's a strategy, it's a plan. It's all these things wrapped up under this umbrella that makes it sound, you know, to somebody who does not know that, like it's just this little thing that we did one time, like, oh, it's a little design project. There's a little bit of internal work you have to do against that sometimes. But the way that we work with Encore is, we definitely take a yes and model. Anything they build or design or release, we use all of those things. It's really nice as a local system, honestly, they have done a lot of that heavy lifting for us, so what we get to do is come in and build the specialized parts and pieces that we need to build our features. And so we really build things that are specialized to enterprise B2B platforms, and primarily the ads business, right? Encore releases a lot of great components, but we were finding that there is a bit of a gap in terms of designers knowing what to do with them. So we can put form components all over the page, are we aligning them horizontally or vertically like this, this card has them laid out this way, but this card has them laid out this way. So we've invested a—

Elyse:

Your design language.

Smith Schwartz:

Yeah, we've invested a lot in frameworks and patterns this cycle. We've invested a lot in content design and content frameworks and tone of voice. And how does the tone of voice impact our visual presentation? And thinking about information architecture, thinking about user journeys and really getting into, you know, the gnarlier, meatier, bleeding edge of what a design systems team typically gets to do, we get to do, because we're built upon Encore. Because we have that strong foundation to stand on, we're able to go a little further and deeper into the reaches that a typical design systems team wouldn't get to do. Right now we're in the midst of some really meaty page layout, information architecture, problems to solve at the systems level. It's really a, a pretty fantastic vantage point to sit from, and I'm super excited about that work. It's gonna be super fun to release.

Elyse:

I think that's really the future of design systems. I think design systems are more valuable than ever. And not in the way that they were five or ten years ago, but we're still thinking about how do we actually build really good UI? How do we standardize our design language, how do we explain, what makes good UI for our team, for this product, and how do we share that? Setups like y'all are describing are really the way that design systems are gonna show that value in the future, that we can actually share across our design and engineering team for the specific product, you know, our IA, our page layouts, our responsive tables, form flows, and button alignment, and these more complicated design language things, when you already have your core foundational components solved. So what are some of the ways that y'all are doing that? Can you give me an example of something, especially that really blurs that design eng boundary, you know, you mentioned page layouts. How are you actually sharing that?

Smith Schwartz:

It's a conversation that we're always having, right? Like, is the juice worth the squeeze on actually building something? Or is this just going on the doc site somewhere? Is this just guidance or is this something we need to actually enforce through code? And so, you know, we're working through that in a number of different levels. Like thinking about we're calling like our level three, level four navigation, which would be on that page detail level, like your breadcrumbs and how do you get back out to your L 2 nav?

Tyce Clee:

I was hoping you'd bring that up because that was an unexpected win at a global level. So those components were built, and I'm not joking, they were built so well, and shared in a design crit with the Encore crew, that instead of being shipped only in our product, the conversation was like, we'll put that in the local system'cause other enterprise people might want it. So we're like, okay, sure. And then the Encore team were like, you know what? Just promote it all the way to core, because the whole company could benefit. We don't have this. Now the reason why that worked I think it's because the designers that worked on that were so on the Encore train, that it was built and designed in a way that just looked like it belonged in Encore. And then our engineers built it in a way that it belongs in Encore. So the way that we structured it, the React and the prop methods, and the way that we managed our state, was more or less like 98% of what Encore would've done anyway. So right now, we are actually in the process right now of releasing that at the highest level. Now that's such win for us, but it's a win for the company.

Elyse:

And that's especially impressive when it's navigation, because navigation is so complex to build from an engineering perspective in a way where it can actually be shareable and make sense for other cases. That's actually really, really exciting because I would say navigation that goes in the local system or the product, not the global. So going back to the Ad Manager redesign project and building this local system, what were some of the things that you actually shipped and what were some of the ways that you were reporting back on success of the project?

Smith Schwartz:

Oh wow. We shipped, we have a whole laundry list of things that we shipped. Tyce and I did an All Hands presentation with like, movie credits of all of the things that we shipped. So I don't know if I'm gonna remember it off of the top of my head, but certainly—

Elyse:

Give us some good examples, some memorable examples.

Smith Schwartz:

layout theme, the color theme, uh, dark mode, we added new color sets, which didn't exist before. We had email templates, content guidelines, tone of voice, product writing 101, like how to actually go in and write for our product and for our users. All kinds of design guidelines. We refreshed all of our data table views and built a whole bunch of components there for complex data flows. All of our data viz and reporting views got a refresh. When you're buying an ad campaign, you go through a big, long, multi-step flow. The very last page, we call it review and submit. And that page specifically looked kind of like a big CVS receipt. And so we refreshed that page and now it looks like an actual branded premium experience. Um, tons of components. One of the components that I was really excited by was a prefilled form input, something that gives you a little nudge that the form input has been prefilled by Spotify, based on what we know about you, based on data that you've given us previously, to give a little nudge to the user. Uh, let's see what else. We did an uploader component, breadcrumbs, that navigation refresh. All kinds of things.

Elyse:

That is a serious laundry list. I know that you had a couple of really interesting stats and metrics that you were tracking around the success of this project, both I think from the project and the design system side, but also from the business side. So what were some of the ways that you were able to actually put numbers around the success of this, Smith?

Smith Schwartz:

Yeah, we worked with our data science team to get metrics on this, which was an interesting uh, pressure testing of how we work with data science. They're quite used to and very adept at testing new features and new releases and AB testing and doing all of those wonderful things. But then thinking about how do we test design changes when there are no feature improvements or changes, like we're just testing ux. But we were able to track time to completion for booking an ad campaign, and we were able to get that down by about 20%, which is huge, just by changing the UI.

Elyse:

That's a lot.

Smith Schwartz:

It's a lot. And it's a long, multi-step, gigantic form, that you're slogging through, you know, uploading creative, writing copy, doing all kinds of things to build out your ad campaigns. And so to get that down by such a significant number really shows the impact of this work. And we were able to track a couple of other metrics around, improved navigation and how people were utilizing that. We're continuing to work with that team to really think about like, how do we test design changes like that aren't, you know, adding new bells and whistles to the product. It's a really tricky thing to get right, and it's not something that the industry at large has done a great job of yet. We're lucky to have such creative and thoughtful partners there to work with.

Elyse:

That stuff is hard, right? Even when you have a great data team and you can track and try to isolate some of that stuff, it's still very hard to be a hundred percent sure that this is just because of this flow or just because of this color or this type or, or whatever.

Smith Schwartz:

We've collected feedback from different sources as well. Like our product marketing team was over in Japan when we launched in Japan last year, and collecting all kinds of direct feedback from advertisers working through the product. And one of the throughputs that they kept coming back to was, we love the look and feel. They had lots of feature requests, but they loved the look and feel. And so even just hearing those like small offhanded pieces of feedback coming from the customer mean a lot to the team. Also circling back to where Tyce was talking about other teams using our components, the most interesting place that one of our components ended up was in this year's Wrapped. Which is like, we couldn't be further from them thematically, like look and feel like we are, you know, buttoned up B2B enterprise level software. And Wrapped is like the most fun, the most spirited, the most fluid part of our business. And the fact that they use one of our components, I think really speaks to the durability of that design and the code and everything that went into that. Um, and it, I was just very proud of that moment.

Elyse:

That's delightful. So what about internally? What metrics were you using, or did you have to track the success of the local system, or those design language guidelines, anything like that, anything you were able to surface, uh, on that side?

Smith Schwartz:

Oh yeah. The satisfaction metric was really just a survey that we sent out to our own design team, asking questions around support, around component usage, around Figma setup, around delivering files to eng, around working with us, communication. Our designer who led this project set up that survey, and he did so much work with the team to really help upskill everybody. And it's a high metric, it's like 4.91 or something. So I'm not sure exactly how you get that number mathematically, but, um, I think it's like brought us closer as a team. I think the vibes are strong on our design team right now. It just came out of a really like wonderful, robust crit where, people are giving great advice, and we've moved beyond some of the systemic problems that we had before, where designers were playing what I like to call, component roulette. Like should this be this component or that component? Which one do you like? And now we're actually having like really deep conversations about the product around the user need, we're getting to the root of these like really critical discussions that I think we need to have as a team. And this work really set us up to do that.

Elyse:

Amazing. That's the goal.

Smith Schwartz:

Yeah, I mean for me, when I think about our broader design team, like this really was also a people strategy and how do we get all of our designers a shared way of working, delivering files to engineering in the same way. So that when one designer moves from one project to another, from one squad to a different squad, there's no disruption in service. Like each squad knows that no matter which designer they're working with, it's going to feel the same, you're gonna have the same level of quality, same level of delivery. And so we did a lot of work with the team there in terms of like, here's how you use these things. Here's how we set up our Figma. Here's some training if you need it. And we even worked with a designer on the Encore core team to come in and help with some of that stuff. He embedded with us for a quarter during the course of some of this work, and spent a lot of time with the team, upskilling. As designers, a lot of us have been around this industry for a long time. We've seen tools come and go. You learn what you need to learn to get the job done. No shade on anybody working that way, I certainly work that way as an IC. And so, you know, you don't often get the time to go in and learn all of the nuance of Figma and all of the bells and whistles there to make your workflows more efficient and more streamlined. And so we really did invest that time this year, and that's really starting to pay off as well.

Elyse:

That's awesome. So I know that folks are curious, Tyce, I just wanna hear a little bit about how did you actually set up these local systems, systems of systems, both on the design and engineering side in a way that's actually been able to stand up to this level of effort and be successful?

Tyce Clee:

Yeah, I can talk to how we started, where we're at the midpoint, and where we're going now,'cause they're all different. So in the beginning, the core system was a standalone repo and we had noticed that a few other people had just forked the repo, which is a classic, rather just forked it and then messed with it, and then published their own package. And we're like, wow, chaos. You know, can this be better?

Elyse:

Literally anything's better than forking the repo, though.

Tyce Clee:

Yeah, I agree, I agree. I think they agree too, but they were like, what's the alternative? And I go, you got me there. That's a good point. How about read this document, here's what we think we want to do. So the pitch was, move in with us, we will take the pain when it comes to infrastructure, the deployment cycle, you need to follow some rules. You could extend the household analogy. You can't just leave your dishes in the sink, like wash them, put them in the dishwasher or you're out. We actually had some pretty strict rules around, we will take the pain of X, Y, Z, but you need to do A, B, C. So there were some things that were non-negotiables, around the way that you would structure your component, the level of state perhaps that you might have in there, and definitely the look and feel being powered by tokens. But then the idea was that because they had their own folder in the repository, which is semi monorepo, you could kind of do whatever you want in there. Now, that, over the years, has actually become one of the sticking points. Because you attach yourself to the train, you can't get off. That is tricky because the core team is releasing majors every six months or so, and the local system has to come along for the ride, which means technically they couldn't break anything until the next major. Now you know this Elyse, but like distributing a system across the entire company means you move slow so others can move fast. A local system is a weird in-between where they're actually moving a lot faster. So here in 2025 what's happening is the core team are talking to us and some others about what the future looks like. And I believe it will evolve. So instead of potentially living in the same repository, there might be another world where we're not doing that, but still following guidelines and following the rules. But on our own track, and our own release schedule, which enables them to get back to that slower pace that they they need, and allows us to probably move a little faster, so that we're not applying pressure on them and they're not feeling the pressure from us. And I believe it's modeled fairly similarly from the toolkit side of things, Smith, in Figma, where you'll have the core toolkit and then it gets republished as a localized version of that. So everything is one-to-one. There shouldn't be anything that is in the NPM package for our local system that doesn't exist in the Figma equivalent and vice versa.

Smith Schwartz:

Yeah, on the Figma side, we did invest in some architecture updates there, which have been really, really helpful. Before the redesign and this big effort, there were two libraries that designers had to go to. One was like, the Encore core library and then our ads business library. And so it would be like, okay, go look in this one first to see if it's there, And then go over to this one. And so it was a lot of flipping back and forth. And then if you had local components, you know, you had to manage those and deal with those. When we had the designer from Encore embedding with us, he spent a bunch of time consolidating those libraries. So now we have the core components and our local system components in one library. And so it's very clear which one you're supposed to be using and we can maintain that. And it's been a huge win and efficiency for us.

Elyse:

How does that work in Figma with the global library file and then having that stuff duplicated in your local design system file? I'm curious how that works.

Smith Schwartz:

Yeah, that is a question I, cannot answer, I, because I did not do that work and I don't know how we did it. We were told no for so long that it wasn't possible, and something has changed in the last year that made that possible. I'm not sure if that was on the Figma side, or on the Encore side, to allow this work to happen, but, um, I could find out, and email you.

Elyse:

Inquiring minds. If you can find out, I think people would be really curious. So looking back on all the work that you did for this redesign, for the local design system, integrating with the global design system, what might you do differently, or what do you still hope to do to make that process go even more smoothly in the future?

Smith Schwartz:

One of the things that I want my design team to really invest in this year is a systematic approach to communication. We did a pretty good job of communicating, when we were in the weeds of the redesign, but like, I really needed folks to be heads down and actually doing their work. I filled in a lot of those gaps for them. But as we move away from this big push, I think we need to invest in those ways of working and the systems around the systems to support it. And so really developing a robust comms practice. Like at which points during the projects are we reaching out to who? Who are the right stakeholders? What are the right channels? And how do we make that repeatable and easy, so you don't have to think about it or invest too much time there. That's definitely one of the things that we wanna invest in going forward. There's a bunch of new surfaces that we know we're going to have to bring in, and I want design systems at the forefront of those surfaces, so we're going to be looking and investigating and like understanding how we get involved there. Um, and just, you know, also a very typical design systems roadmap of like, what are the missing parts and pieces and things we need.

Elyse:

What about you, Tyce? Any things you would have done differently or things you're looking forward to in the future?

Tyce Clee:

I think the process of what we were calling Bye Purple, that six to 12 months of work to implement the design system, it really surfaced champions in each of the teams that really loved this sort of work. So, particularly front end engineers that are in feature teams that gravitated towards the work. And they were the ones that were scouring the PRs and helping us get things approved. They were the ones finding time in their feature work to help us ship this thing. I think we need to stay engaged with those champions so that as we do the next piece of work, whatever it may be, we have that group of people here in our space that care more than most and are good at what they do. And I think that's something that we need to not let fall by the wayside just because we've finished this really huge piece of work. They were so essential to us being able to ship so quickly last year, so I think we just need to keep tabs on that and show'em where we're going, and then probably encourage some more embeds to come through our squad. Bringing people to us, giving them some experience and empathy for a platform way of working. And then they go back to their team and, and take all those learnings, and, you know, we've had really good success with that.

Elyse:

I think a lot of people believe that that's really important, but having that set up in a formal way requires a lot of organizational support in actually making that happen. So I'd love to hear more about that. Well, you know what time it is. It's the best time of this whole podcast, which is spicy take time. So I ask everybody who comes on the podcast to give us a spicy take on design systems. Let's hear it.

Tyce Clee:

Okay. So mine, so I, I think we need to apply the KISS principle more to design systems. Which is keep it simple stupid. And, and what that means in reality is, here in the year of 2025, there are so many fantastic solutions out there for complex components. Stop building them yourself. Take them off the shelf, apply your lick of paint, and move on. Move on with life. Because adoption matters more than creation. Avoid the itch to build another date picker, to build another, like, you know, complex dropdown. There are so many robust open source options out there that we should be investing in, and I mean, literally like, like donating money to those people that are building those open source components. So if I was at a company starting from the beginning, I would be looking at the simplest things, getting out there in front of people as quickly as you can, and then anything that's complex, just take it off the shelf, apply your paint and move on.

Elyse:

Amen.

Tyce Clee:

Later when you've got a team of 20, maybe you want to tackle building a date picker, but I'd still say you're mad. Don't do that. That's my spicy take.

Elyse:

Amen. I, yeah, no, that's, I'm, I'm fully on this spicy take train because honestly, there are teams out there who are doing such a good job building core component libraries, headless components, Material UI, Shad CN, Chakra, Ant Design, like, I'm not even naming like hundreds, but like, how many ways are there to build an input? I think the only teams that should be building this stuff for themselves are global multi-platform, right? If you're doing web components so that you can support, React, and React Native, iOS, Android, Vue, like all the things because your business actually requires that, fine. If you have a team and you're building React, for the love of God, you do not need to be rebuilding your own input.

Tyce Clee:

I think you can have such a faster win by applying your look and feel and getting it out there, and you can get more insights as to like, who are the people that you're shipping for? That's where I would move the needle, invest more time in working with your people, going to them and talking to them and helping implement. That's where you should be spending your time, because there are so many great options out there. And I think in the earlier days, maybe the late 2010s, there was a level of competitiveness and sort of like, oh, I don't want to use Material because, you know, it's, we're not Google. But now I'm like, I don't care anymore, if it's great and it's robust, just use the thing. Like our time is finite. We should spend it in the places that matter, and that's the people that are building the product at our company.

Elyse:

I love that. I'm, I'm on board. Smith, spicy take.

Smith Schwartz:

My spicy take kind of building upon Tyce's spicy take is, I think like the next generation of design systems is beyond components. It's beyond the tokens. It's really thinking about, how do we scale information architecture, how do we scale content? How do we scale all of those things that design systems have traditionally stayed out of? How do we make those decisions logical, scalable, and again, taking that off the plate of the feature team so that they can go solve the problem that they need to solve quickly. And not worry about like, oh, should this open a side sheet or should this open a modal, or should this open a page or a tab? Like there should be a system in place, as a designer, that you know and understand, and can work with really well. So that as you're solving your problem, those decisions aren't blocking you from moving forward.

Elyse:

Absolutely agree, and I think that is the hardest and most valuable frontier in design systems, because the problem that we were solving, again a decade ago was how do we share a component?

Smith Schwartz:

Right.

Elyse:

How do you share, you know, the kinds of design language rules that make your product feel like your product? That is a people problem, that is a process problem, that it's a communication problem.

Smith Schwartz:

Yep.

Elyse:

Um, and, and I do think that, that is the challenge because we're not gonna solve that in React.

Smith Schwartz:

No.

Elyse:

Or Figma.

Smith Schwartz:

No.

Elyse:

Or anything else.

Tyce Clee:

I believe that's where the core team at right now. They're at the point where like we have mass adoption, we are a household name at Spotify, we have the bulk of the components you need to build product. But what we don't have is like, what's what's a cohesive way to put these things together in a way that feels like Spotify. And I think that's where we'll probably go next too. I'd love to see more of that in this community moving forward, and if any companies out there are having success with that, I'd love to see how, what, how are you doing that? How's it work?

Elyse:

Yeah, me too. I would love to. Well, thanks both of you for coming on the podcast. You know, I feel like the design system space has been, I don't wanna say only negative the past couple of years, but you get in design system spaces and there's so much frustration and understandably right? Sure, like, there's a lot to be frustrated about. But it's so nice to hear in depth about a project that's working. Because we also are all still in design systems because we believe that it can work, and it should work, um, and to know that that's happening out there is just a real delight. So thank you for sharing, some fun stuff with us, some successes, and congratulations on all of the success on your end.

Smith Schwartz:

Well, thanks so much, Elyse.

Tyce Clee:

Thanks for having us.

Elyse:

Thanks for listening to On Theme. This is a brand new podcast, so if you like what you're hearing, please subscribe now on your favorite podcast platform and at DesignSystemsOnTheme. com to stay in the loop. See you next episode!