Reimagining Design Systems At Spotify

Gerrit Kaiser at UXDX Europe. Video: https://youtu.be/gkbXr0-tFOM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

What is an organization's shared approach to product design?

[00:00:00] My name is Gerrit and I've been making things on the internet since I was 16, as a designer, as a developer. Before that I was actually playing with LEGOs a lot, so I really enjoyed Sebastian's talk earlier this morning, and now that I think of it, it's maybe not that much of a coincidence that I'm doing design systems now. I currently lead design systems teams across our Stockholm headquarters and our major R&D hub in New York City.

[00:00:27] Today I'm going to talk to you about design systems. I'm going to talk about approaches to scaling design in larger organizations, give you a little bit of background about design systems, give you an overview of the journey that Spotify has been on over the last few years in this field, and introduce our new model of how we implement this kind of thing. I'm going to focus on the org design aspect specifically, because there's a lot more to talk about, and then hopefully along the way you might find some things that you think are relevant.

[00:01:06] If you're working in any kind of product organization, this kind of question comes up a lot, especially if it's a larger one or it works across multiple things. What do our products look like? What do they sound like? What's our voice, tone? How do you communicate in writing, or increasingly voice UIs? What should our patterns, our interaction patterns be? How do our products behave? How should they make people feel? In short, basically, what is an organization's shared approach to product design?

[00:01:36] That is a deeply philosophical question, but it's also a very logistical question. This includes things like what exact color should this one thing be, or what font size should be used for this other thing. Those are all really easy questions when you're an individual designer, when you're a small design team, and they become incredibly hard ones the more you grow.

Why people say design doesn't scale

[00:01:57] So people say design doesn't scale. One of the reasons they say that is perhaps because design as a discipline is rooted in craft, in individuals making artifacts by hand to a really high standard. Even though modern design is often considered a team sport, there's definitely evidence that it doesn't scale easily to arbitrarily large organizations, such as Uber's 450 or Spotify's 200 designers.

[00:02:32] This is not a new problem. Large organizations have tackled that throughout the 20th century in a variety of ways, and they fall into roughly two buckets. The one is kind of to organize, to focus on people and process. The clichéd example is the ad agency sign-off process, that art director with the red pen, the dependency on a singular authoritarian tastemaker or a small group. Apple is often cited as the canonical example of that. It produces a single kind of design and that can be desired, but it's hard to scale to larger groups. You end up having to implement rigorous hierarchical decision-making processes and throw away 90% or more of the work that your people produce, so you have to be able to afford that.

[00:03:17] It also produces a particular kind of aesthetic, very polished, sparkling. That's not the only one that has a right to exist now, and it might not be the one that's right for your organization, and you get different outcomes depending on your organization if you rely on that for design quality. There's a thing called Conway's law. It's meant for software, but essentially it states that organizations that make stuff are constrained to produce things that are copies of the organizational structure themselves. And as a design leader, if you want to retroactively change the organization and culture to increase design quality, you might be facing an uphill battle.

Writing it all down: the Vignelli standards manual

[00:04:03] The other approach is to document, to write down everything, to focus on guidelines, rules, to specify the desired outcomes in as much detail in advance. This is also an approach of centralizing the design to a smaller group of experts, but it does it asynchronously, and it does it before production rather than during or after. That's nice. These often take the form of super detailed, prescriptive specifications, hundreds if not thousands of pages long. The canonical, somewhat cliché example is Massimo Vignelli's graphics standards manual for the New York Metropolitan Transit Authority, from 1970.

[00:04:44] I'm going to show it regardless, even though it's in every second design systems presentation, because there are three things in this particular example that I really like. Despite these books now being somewhat pretentious collectibles — and I'm admitting that I of course have one at home — the original intent was quite the opposite. Note how this comes in a ring binder. That has three reasons.

[00:05:12] The first one is integration into the workflow. If you're a designer and you're printing a sign for the MTA and you have to go down to check the color accuracy[?] in the print shop, you don't want to lug around a thousand-pager, you just grab the single page that you need, you get onto the dirty shop floor and you come back. There are even other examples where these are perforated and you can rip out a little clip there.

[00:05:34] The second is updateability. So if there's new guidance that's issued, old guidance that's removed, you can just open your ring binder or add some new pages and you're done. The central authority doesn't have to reissue a few hundred thousand-page books.

[00:05:49] And underlying this all, it's kind of like, why go through these great lengths in specifying everything in this really minute detail? Why was Massimo Vignelli so anal[?] about everything here? People say he's a graphic design diva, but actually I think he was one of the earliest user-centric designers, and this is evidence of that. You realize that while you're in a subway station crammed with a few hundred sweaty people, a few tens of meters underground, moving metal trains, getting lost is the last thing you need. So legibility and consistent wayfinding was really paramount for their users.

What's different about digital material

[00:06:27] All of these things — user centricity, living standards, etc. — have been done before. So what makes our current situation different? What is new when working with digital material, when dealing with websites with thousands or tens of thousands of subpages in government or enterprise settings, apps with user-generated data that are used in ways that really cannot be imagined by their designers ahead of time? Digital material is interactive, time-based, it's evolving, and the products that we produce tend to be a little bit more complex than a sign, and in some cases, certainly in Michael's, Uber's, case, more complex than the entire New York City subway system itself.

[00:07:13] Another key difference is that digital products are never done, and that's probably a good thing. I think I'm preaching to the choir here with that. But as companies practicing iterative development add things to products, features, layers, they tend to not remove things and keep the old stuff around. There are not enough incentives for diligent cleaning, paying off design debt is understandably not prioritized over things that move business metrics. And mixing old and new is cute if you're making an architectural statement, it's less cute for your users.

[00:07:47] You've all been there when you try to change your phone number on your favorite auction house, where you put the phone number in twenty years ago and the form is still the same. You've been through that when you change the privacy settings in your mom's favorite social network, and there are many examples around. So even five-year-old digital products kind of become these generational layer cakes. We're turning users into involuntary archaeologists.

[00:08:17] This is caused by visual trends, by OS updates, and maybe by the fact that there is a crazy amount of designers working on digital products at this point in time. Rare is the piece of digital design that has a staying power of longer than five years, that still feels fresh today. And the subway signs at least had that going for them. We can lament that and pinpoint the reasons, but I don't want to go there today, because I think the right way to deal with that is acceptance. This is a natural thing that comes with digital products, and we as in-house designers need to find ways to really embrace the digital material.

Flattening the deterioration curve

[00:08:55] So this is what this talk is about: zooming out. I apologize for the crude model that's about to happen here, but maybe we can capture this kind of graphically. Bear with me. Let's imagine a parallel universe where we can capture some quantified idea of design quality that we can agree on, and for the sake of an argument let's also assume that this is a one-dimensional, not a multi-dimensional problem. So if design quality is up, time is to the right, I would say — you might recognize this — that every digital product of a certain scale goes through a series of cycles of deterioration, countermeasures, pendulum swings in its journey.

[00:09:39] There are pain thresholds here. You'll know you're on your way down when your designers start shouting, being upset. You should listen to them. They're kind of the bellwethers here, because their professional identity is really tied up with this. They know what's going down. Users will also notice this deterioration earlier than you think, and definitely earlier than they will tell you, and probably start leaving. So at some point, unless you've already started some countermeasures, this might escalate until someone high enough up has had enough and declares this needs to end. So congratulations, you have a big redesign project on your hands.

[00:10:23] Now, we've all been there, but this is an energy-draining, all-hands-on-deck effort. In a lot of cases it's risky. Users don't like change in general, even if they come to accept it thereafter. It's also risky because you might just miss the mark, no matter how much research you did, and it can lead to redesign fatigue, resignation internally. So this curve kind of trends down over time, your product deteriorates as a whole. This is disruptive to regular business, innovation and iteration work.

[00:10:56] So how can we learn from this? My proposal is we need to learn how to flatten this curve. We have to stop this from hitting the pain threshold for users. We have to operationalize design changes, even on the visual layer.

The BBC, Facebook's colors and SoundCloud's data

[00:11:13] Lots of people are trying and innovating in this field, and this is one example from the BBC. They've been real pioneers in this field. Apologies for the potato quality there. Essentially they found themselves in 2010 backed into a corner. They had hundreds of websites, they were different from each other. They printed them all out and both the problem and the solution became immediately apparent. They did a big redesign to solve this all, but they did it in a way that aligned all of their properties to a common standard. They operationalized the standard, and crucially they vowed to never let it deteriorate to this point again. They put a lot of resources and investment into making guidelines and having central teams of experts that write down the best possible way to do things and share that out.

[00:12:04] This, even though it's the gold standard for in-house guidelines to this day, in my opinion is the contemporary version of the MTA guide that you saw earlier. There's still a manual step. Every time you change something you need to convince everyone to adopt the new stuff, and then you need to verify that they've done that to your quality standards.

[00:12:29] A different example, going back to how digital design is different: even the smallest problem becomes incredibly intractable when you're at a massive scale. So even sticking to a small number of colors is a problem if you work for Facebook. Let's talk about Kevin. Kevin was a product designer at Facebook a few years ago, Kevin Arnott, and his team, they were tasked with simplifying the color system. An audit came back and found 10,000 colors in use across their application. Did they need 10,000? Probably not. So the task was to reduce that, but conventional methods at this point were completely impossible. Even if you did manage to internalize 10,000 colors and come up manually with the best system to replace all of that, how was he ever going to convince 50,000 managers to implement that?

[00:13:22] So Kevin wrote software. Kevin wrote tools. He went back to his art school color theory courses, he developed perceptual models of how colors are perceived to be similar to each other or different from each other. He automated both the work of generating a new model that would replace the old one and implementing the new model at scale. He then gradually migrated the entirety of Facebook from ten thousands of colors to less than a hundred, and he did that without telling anyone and not asking for permission, and only presented the results at the end. For me this is one of the most beautiful examples of the power of code in the hands of a designer. His team is now at Lyft and they've open sourced actually a lot of the thinking behind that. It's a great project that helps other companies take similar approaches: generative color models and gradual migration, accessible no less.

[00:14:21] Here's another example from my time at a company called SoundCloud in Berlin. SoundCloud, as you may know, is a user-generated music platform. That user-generated content is the point. If you remove it there isn't a lot left. This presents a lot of challenges if you have complex, data-heavy interfaces, especially for designers. Our design tools did not keep track with the reality that we were designing for, so it ended up that every designer had a folder of like the ten favorite album covers, and nobody ever bothered to put in real titles, and mock-ups ended up looking like this.

[00:15:01] We knew that wasn't enough, so my team and I started building plug-ins for our design tools, Sketch, that pulled in data from the API and integrated it into the design workflow, whether that's album art or people's heads, metadata, anything you can kind of live off. We were able to generate high-quality mock-ups much better, much faster, and we were able to generate a lot of variety and do justice to the content creators that we were designing for.

Design teams need to produce software

[00:15:34] So going back to what's different this time around: I would say designers really, really need code at this point. It's the fabric the digital surfaces are woven on. That doesn't mean that every designer needs to be a programmer, but you need to understand the digital material really, really deep on a fundamental level. And it also has to be the right kind of code. A CMS for a guidelines website is great, but it really is just a faster ring binder.

[00:16:04] So I would say it's not necessary that designers should code. It's the design team — and Michael was talking about that a little bit early on, it's his answer to the question over here — the design function in an organization needs to learn how to produce software. I would say a successful and progressive digital product design practice today can't limit itself to putting out two-dimensional pictures or click dummies. It has to produce code, whether that's in prototypes or design tooling like I showed before, doesn't really matter. That is necessary to tackle the complexity of digital products today. It doesn't mean doing the front-end development yourself. It means encoding design decisions in a repeatable way, in a scalable way.

Design systems at Spotify

[00:16:54] That brings me straight to design systems, and maybe I shouldn't have spoiled the surprise with my talk title. I'm going to talk a little bit about the journey at Spotify that we're doing with design systems right now, because we've made a significant investment in that field and we're really doubling down on that as a tool we believe is a really crucial and primary deliverable of our function at our company. We're not the only ones. In the last few years there's been a tremendous amount of innovation here: pattern libraries, UI toolkits, style guides, CSS systems. All of these kinds of fields and practices are converging and melting together into what's called design systems.

[00:17:35] Just to level set a little bit — I'm assuming a lot of you already know this — but it's hard to define what a design system actually is. It's a young field, it's not quite settled yet and it's hotly debated. There are many, many definitions. This is Alla Kholmatova's, who literally wrote the book on design systems. None of these are wrong and I'm not about to critique them. We just had to develop our own at Spotify, one that worked for our organization, worked for the context, worked for the people and our strategies. I think that's because design systems are meant to encode the character and personality of your brand and your company. They have to adapt to the organization, so everyone is different.

[00:18:16] And for us, not surprisingly maybe after 10 minutes of me rambling about code, that for us is the secret ingredient, the magic sauce that makes design systems materially different from any of the other previous efforts, that are all good and useful, they just don't scale. On a pragmatic level, it's the building blocks for products. It's not just for designers, we strongly believe it's for engineers, it's for writers, it's for product people. It's a way to unite every one of your practitioners around a common language. Stuff inside: basics, components, buttons, usual stuff. There are higher-level patterns on a more pragmatic level than the lofty patterns we heard about earlier: how our flows, errors, etc., how the users move through your product experience. All of that can and should be documented and encoded.

Painted Black, the rebrand, and GLUE

[00:19:14] Spotify has been on this for a while and we've had a few attempts. This is another one. It started 2013, roundabout. There was a big redesign effort, the first time the organically grown product portfolio that we were looking at, we tried to unify that holistically. We called this effort Painted Black. Huge effort, the intensity still reverberates through the hallways when we talk to some of the older folks in the company. There was a recognition clearly thereafter that a one-off model wasn't going to work and we had to operationalize.

[00:19:53] But then the next redesign rolled in, a rebrand that was targeted at the communications that had been lagging behind the product at the time, but they needed to be implemented in and represented in the product in a meaningful way. So one of the things that we had to do was change the shade of green, which users initially didn't quite enjoy.

[00:20:15] After that it was time to really do the right thing, and a team was born, a design system was born, called GLUE, the global language for a unified experience. The idea was to be the one-stop shop for all the building blocks for all the products: code, design, etc. However, after a few years of running this, we can say from today's perspective it didn't really stick.

[00:20:41] How come? There are two reasons. One is that it was both a design system, a product and a team. It was a centralized design systems team. It was very successful at what they did, to the point that it grew beyond a manageable scale. If you believe in small autonomous teams, as the introduction mentioned, if you grow past six to ten, maybe fifteen if you're lucky, people, you're not going to be effective. A single team, which is the de facto operating model that most companies do design systems with and therefore why would we do something different, didn't work out for us.

Ubiquity: 45 platforms and one brand

[00:21:16] Here's another example of how the reality also changed underneath the team. As a company, one of the big strategies is aiming for ubiquity, for Spotify to be everywhere. So I'll ask you to picture this scenario, you can close your eyes if you like. This is a possible scenario for a Spotify user today. Imagine you listen to music at your desk, your day is over, you pick up your phone so you can continue listening to that album that you were listening to. You go to your car, you change the music over to your car speakers before yelling at your car's voice assistant to put on a podcast. You get home, your connected sound system picks up where you left off, and your TV and the internet-connected fridge that of course everyone here has at home show what's playing. You control the whole thing from your smartwatch.

[00:22:10] This is not a future vision video, this is the technological reality of our Spotify product ecosystem, and it's used like that by millions of people. It's a really kind of unusual reality[?] in a way, from our point of view. So Spotify is not a website, it's not an application, it's not a piece of software, it's not a destination you visit, it's more a piece of your life. It's a constant presence that kind of hovers around you, it gives you access to the stuff we want to listen to, wherever.

[00:22:41] Not to sound like a digital prophet, but I think more and more companies will find themselves in a similar situation, if slightly less extreme. We're growing from an era of apps to an era of intangible, disembodied, yet ever-present services. And while the importance of individual apps is diminished, we still have to write software. In our case we have to write 45-plus in-house consumer listening experiences. iOS app is one, desktop is one, there are more: web browser, PlayStation, and so on. That's not counting 300-plus things that partners build with it for us, like your Sonos integration, or tens of thousands of API integrations that also play music.

[00:23:23] The main challenge here is around creating and evolving a cohesive experience across all of this. It's a tremendous design challenge, and for design systems that meant encoding what made Spotify Spotify in a way, so we can implement that consistency but also, crucially, evolve it over time. It can't just be the color green, it can't just be a logo.

Design tokens

[00:23:46] So what is it? We turned to an emerging technology and methodology called design tokens. This is a really simple but powerful concept, and it's a way to scale a visual language across different technologies and different platforms, because there was no way we could make a smartwatch and a fridge and a hero bill[?] use the same programming framework. Tokens are, again, a really simple thing. You give things names and things have values, and you can layer that as much as you want. This is a piece of fantasy UI to illustrate that. This is crucially done in a platform-agnostic way, stored somewhere centrally and then translated to artifacts that can be consumed directly by the applications.

[00:24:27] By building a component layer on top of that, you can then hopefully create continuous evolution of your visual language over time and centrally manage things. So the change of green I mentioned earlier, that took teams literally months to implement over the relatively modest monolith[?] we had at the time, we can now do centrally in minutes.

Twenty-two design systems and autonomous squads

[00:24:51] Now we had design systems that were connected. That was it, right? Actually the landscape turned out to be more like this. I did an audit of all of the design-systems-ish things we had at Spotify and the list went to 22, and I'm fully expecting to find more. Varying quality, maturities of maintenance, but they're all in production right now and they're real things. A lot of great work went into these. There was one issue: other than cheesy adhesive metaphors in the naming scheme, there wasn't a lot of things binding these together. So we knew we had to do better.

[00:25:31] But we also knew this was actually kind of by design. This is a result of how we choose to organize in autonomous squads, which is our main strategy to keep up with the company's scale, do parallelism and speed, innovate faster. A squad is a small cross-disciplinary group — I think most of you might be familiar with the concept — set up around a defined mission and staffed with all the people and skills needed to accomplish that mission, empowered to do whatever it takes to accomplish that as well. And if it takes a design system, this squad is going to build their own. It's a method of reducing friction by removing communication barriers and synchronization, but sometimes it means that people choose to optimize for their local speed rather than the global speed of the company. In the case of design systems this can be a counterproductive force.

[00:26:23] But we have a mechanism to deal with that, and it's not a thing that just occurs in design systems. We call those platforms. It's an organizational pattern, an important tool, where we extract common concerns that vertical teams have into a horizontal layer that's owned and evolved by its own squad, or squads, as an internal product. Relatively common sense construct. Spotify as a whole to the outside is a platform that empowers creators to reach their fans. Internally it's a whole incredibly complex stack of internal platforms itself. This empowers people to move faster, and you can think of an individual design system as a platform for feature teams.

[00:27:07] Already with the 22 number we knew we needed to build a platform for platforms, a platform to make design systems. These are the kinds of data points that we gathered to illustrate the magnitude of the challenge. But most crucially, and that's perhaps a different situation than some other companies and certainly than Uber earlier, all of this from a user's point of view is one brand and one service. So really the need to create a unified system on the inside was crucial, so this complexity wouldn't be outsourced to the user. We need to somehow unify our design systems across audiences, across all the 45 platforms, across the podcast stuff that we're doing now, 45 languages, etc., all of that dealing with Spotify autonomy.

Encore

[00:27:51] Jina, a design systems pioneer, is fond of saying design systems are for people. We always try to keep our end users top of mind when doing this kind of work, but the most important customers in this case are our internal customers, the designers, writers, product folks, etc. So we started talking to them and listening to them, and they told us the same thing that we kind of already knew from the data: that the complexity of 22 design systems was baffling, unnecessary, why did it exist? They want simple answers, not philosophical answers, to questions like, where do I find all the design resources, or what button should I use here? So we need to take our users seriously, we need to build a design system architecture that's unified and accessible, just like we aim for our products to the outside world to be.

[00:28:45] We started by establishing an internal brand, and we're calling it Encore. It's the integrated design system framework that would crucially take all of the existing efforts and put them on a path of long-term convergence rather than divergence.

[00:29:09] This is how it looks under the hood. There's the framework, it's what ties it all together. It's the brand, but it's also shared terminology, it's shared tooling, Sketch plug-ins, linters, internal documentation hubs, because we needed to create a unified experience for our internal users. At the center we have one core foundation. That's the visual language layer, the lowest kind of minimum bar for every Spotify product that I mentioned earlier. This is where our design tokens live now.

[00:29:40] But tokens by themselves aren't that useful, designers and developers need higher-level constructs. So how do we do that across 45 products? We chose to include a layer that is generic, tech-specific, breadth-first design systems. So everything that uses web technology under the hood, and it's not just websites, that's also your PlayStation app, fun fact, and the desktop app, they share a common layer of really agnostic stuff. The same is true for mobile, we have a bunch of native mobile apps for artists, for other people, for listeners.

[00:30:14] And then finally we can build higher-level local design systems on top of that, and that's the stuff that you will find in most companies, tailored parts that are really tailored to the specific context of the product. So for example we have dozens of applications targeting podcasters, labels, publishers, artists. They share a lot of concerns, and that is all living in one design system. And the same is true for what used to be called GLUE, our design system for our consumer mobile applications.

[00:30:50] We don't know that that's the final set, so we're building in strategies and processes to add and remove some of these things. The individual systems don't matter, the things in the individual systems, the artifacts, don't matter. It's the end-user experience, the velocity you gain from building on top of one another, that matters. We're happy for teams to spin up their new design systems if they choose so, if there's really a need, and we'll be there for the journey with them.

[00:31:19] Each individual circle here shares a common interface, a common API. It's owned and actively maintained by a single autonomous squad. Really crucially, they know their customers well and they iterate independently. It builds on other systems, so it includes all of this lower-level stuff, you get that for free. And it has a familiar internal structure, providing design, code and documentation.

[00:31:43] That really goes to the core of our beliefs here. Each individual one of those is extremely useful for an organization, but we feel you can get an order of magnitude more payoff if you integrate these things really, really closely. It's the connections between this stuff that removes the barriers between disciplines. By putting it all in one place you can put tooling, automation, shared practices around them, and you are more likely to end up with a shared language than if you treat the disciplines in isolation. Again, connections are what make this work. But there's really concrete stuff: your typical design toolkits, your typical component libraries and your typical documentation hubs as well. This is more than enough for a single team to handle, so we're also establishing a program layer to operationalize this, to coordinate multiple teams from multiple departments working on this together.

Takeaways

[00:32:37] Hopefully that was a really brief overview of Spotify's new generation approach to design systems. This is our approach that works for our organization. I believe it'll be very hard to copy for some others, but maybe there are aspects of this that are interesting. We'll definitely share more of this when the time is right, because we've learned so much from the community that publishes freely and openly about this, so look out for publications on the website, spotify.design.

[00:33:08] I'll leave you with three takeaways. No company is the same, and copying and pasting this or any other approach is likely to doom you. Do the work and analyze and adapt to your local context. Design systems also can't go against the grain. If you're trying to change the culture of the company, the ways of working, by introducing this kind of new method, you're facing an uphill battle. So embrace the culture, the differences, the characteristics and peculiarities, and go with the flow.

[00:33:43] Design teams should make software. Not every designer should code, but as a team you need to have that capability, whether that's by poaching designers and engineers and offering them pizza, by partnering with engineering partners, by hiring them yourselves, by upskilling. Doesn't matter. As a function today you're expected to have code literacy.

[00:34:03] And take internal products as seriously as you take our external products. This might seem like a lot of marketing overhead, but it is worth it if you're a large enough organization. Taking products seriously usually also means making sure you do the right thing, so run internal ethnography studies and run quant surveys and run qual tests. Do this research like you mean it, and release early and often. All of the things that come with external products should really also be applied on the inside. That's it for me, thank you very much for listening.