Design Systems at Scale // Episode 6: Maintaining and Evolving Your Design System

It's important for a design system, and really any product to have a set of guiding principles that will govern the decisions that the team is going to make. Why is this product the way that it is? Why are we going to make the decisions that we're going to make? And so a big way that we do that is by creating design principles for the project. And design principles are things that emerge from a combination of the business goals, the user promises that we make. You know, what do we need to do for users, what do we need to do for the business? And you kind of marry those into principles that say something about what the product is or does. The importance of design principles is to actually help people make a decision when there are two viable paths. So a design principle like clean and simple is probably not going to be very useful because no one wants messy and complicated as their byword. Instead, we want to sort of have some principles that help to make decisions when you're at a fork in the road where a reasonable person could go in one direction or another. And so design principles become these things that are rallying cries in a sense, or reminders of what is in our path and help us to make decisions when there are competing directions that we might go in.

We put all of this work into this thoughtful, component driven system and there's all this great thinking baked into this thing and nobody uses it or it becomes outdated. The whole thing, all of that effort just gets thrown in the trash can. Cause as soon as all of that knowledge locked up in that style guide website ceases to reflect the reality of how your products actually get things done, it ceases to be useful. We've encountered many organizations that have sort of a graveyard of design systems sort of littered throughout their history. Sometimes you're going back almost a decade where it's, oh yeah, here's this first pattern library effort and here's where we tried it again. And here's where he tried it again. So governing a system is probably the most critical piece to get right.

When we talk about governing a system and what is design system governance really? What we're talking about is how do we make sure that it keeps up with the needs of product? And likewise, as the design system improves, how do we roll those changes into product? So I guess then let's get down to brass tacks. How do you, after you've built a system with a few pilot projects, start to build additional projects with it and roll those changes back into the system, into the design system, and vice versa?

Maybe one of the Obvious things that maybe needs to be said is that if pilot projects are what got you to a design system, maybe pilot projects will keep that design system running. So I think again, the design system serves products and it's supposed to help you. It's supposed to be a product that helps you make products. So keep making products, but don't keep making products in isolation. Keep making products with an eye toward how does this affect our design system? Does it change it? Does it edit it? Does it modify it? Do we need to remove things from it that we don't need to support? Do we need to add things to it that we now do need to support? So one thing that's a really actionable step is keep making products. But maybe build into your process one or two checkpoints, maybe in the middle of your project to go, are we using all the things we need to use from the design system? And then at the end of that process going, okay, what can we actually take out of this product harvest back into the design system, either by adding it or by changing something that's already there.

Who's doing that work of auditing products and sort of harvesting them for design system improvements or additions?

Yeah, so there's a couple of models for that.

Right?

And there's lots of good writing on this. Gina Ann has written some really great stuff. Nathan Curtis has written some really great stuff about this. I'll start with the first one that maybe you guys can fill out. So maybe the most obvious one is your design system might not get a lot of love when it's first at your company. Maybe you've gotten buy in from everybody, but then everybody's forgotten about it while you're building it. So typically what happens is like there's one person and it's just that person's baby that could be a product director or it could just be like one fledgling designer or developer that just like really is passionate about this stuff. And that's cool, that's great. At least somebody is passionate about it. What we find is very rarely does that person actually be able to sustain a design system. One person having oversight of the design system. Because if all things go well, if you've done all these things, they will go well. You very quickly get inundated with lots of emails, people going, how do I use this? Or how do I maintain it? Or how do I update it? So one person is a good start, but it's not a sustainable model for one person to have oversight over the design system. What else? What are some other ways to do it.

I think that another team model that can work well at an organization is sort of a centralized team model. So you have a dedicated product team that is responsible for making, grooming and maintaining and evolving the system. That kind of team structure has this sort of systems view, right? All of those people are thinking about the entirety of their product ecosystem at the organization. The risk with that model though is that it can lose that on the ground perspective, right? That individual product need sort of perspective. There's another team model which is the federated team model. And so this is where you don't have a centralized team doing all of that production work, but rather representatives that work on different products scattered across the whole organization. So you might have a front end developer working on this product and a designer working on this other product. And all of those people are sort of representatives that are sort of maintaining the system. The risk with that though is that product roadmaps always take priority, right? So those people's attention are split between sort of serving real product needs. And so as a result, the actual system and that bird's eye perspective is lost and the whole thing sort of just gets swept away. Another model, and this is Gina talks about this, this is the model that they put in place at Salesforce whenever she was working on the lightning design system. It's called the cyclical model or the Salesforce model, which is basically it's sort of a combination of a centralized team and federated members. And there's close pairing that happens between those teams. So you have a centralized team that's doing a lot of work, but then there's also federated members that are able to sort of feed that in the weeds perspective to the design system.

It is a diverse model, right? Where there's representation from all around the organization. You got some, some bird's eye view people, you've got some on the ground view of people that are making products with the design system, both makers and users. And I think it's worthwhile to populate that with other people from the organization. So maybe you have people that are executives on that team and you have people that are makers doing the work as well. So you get kind of different views of the organization too. I don't know that we've particularly seen this model, but I think it scales well too. Where you can have potentially you could even have some people who don't even work in your organization as part of an advisory board for that.

That's exactly what the team at Etsy established a design system committee that met regularly I think it was once a month or continues to meet, hopefully once a month, where they have representatives from a bunch of different areas that sort of get together. So there's a committee leader, but then they also bring in different owners from different products. So you have different products represented as sort of stakeholders in the system. And then they have different platform representatives. So people working on their Web properties, their iOS properties, their Android properties, their email properties, all sort of with a seat at the table. But then also they brought in, I think this is especially clever, bringing in subject matter experts that might be sort of working on specific products. But if you have an accessibility guru and a performance guru and a responsive design guru, each sort of scattered across the organization, they come in as an expert and sort of lend themselves to this committee. And so what you end up with is this really nice cross section of stakeholders and experts, all sort of dedicated to growing and maintaining the system and making sure that it continues to serve all the different products and platforms successfully.

So I think one of the changes too, as we think about governance, is that there's a cultural shift of how do we encourage people to think about. We're creating together this common body of design philosophy and standards and interactions that we can all commonly use from which individual applications will spring.

But we have seen organizations that go, that's kind of opposite of our culture, right? So it's not that they're opposed to it, but they're just like, we couldn't flip a switch. And then all of a sudden we've got this open source model and culture here. And so I think it's important to say that there are steps to get to that too. Right. We've seen all different permutations of that. Where some organizations go, yeah, we can do that because we have something like that already existing here. And so that folds in naturally. We've also seen. Well, let's just first set up an email address so that people can email us if they have questions about this. Okay. That's a good first step too. We've seen groups set up, yammer communities or intranet groups, or private Facebook groups, or Slack channels dedicated to the design system as a way of going. We can't really go kind of full open source yet because of the politics of our organization, which are very real. But we can do some semblance of that. I think that's okay because that's a way to build up to that point where we're starting to create that culture. You don't create culture overnight. Maybe in a year. We'll get to that point. And in the meantime, we'll have open contributions via email or a forum or something like that. So it's not all or nothing. It's definitely stages to be able to get there.

I think one of the things that we want from a design system as we make these is for people to be enthusiastic about it. Be like, yes, I want to use this. I recognize myself in the way that I want to do design and development in this system. And the biggest way that you can get people to feel invested is to let them invest in it and signal we are open to improvements on this. Again, humility is such an important part of creating a design system. This is not something of us telling you the best way to do something. It is, we are here to support you. What do you need to do your job the way that you want to do it?

That's right. And I think that there are, as Dan said, a number of different communication channels, just having a Slack channel that's dedicated to it. And the team that is invested in making and maintaining the system hangs out there and is eager to answer any questions. There's good customer support, but also regular State of the Union meetings, like updates on the roadmap whenever you do a release. We've seen regular email campaigns where every month the team sort of says, here's what's new to the design system. And oh, here's this sort of MVP person that just really killed it on this product. And look at this really cool contribution that they made, or look at how they use the design system in a novel way. And all of that sort of helps sort of foster this sense of shared ownership and contribution and sort of encourages this culture.

The amazing thing is once you have a design system in place, you have a common set of components that everyone understands. Designers, developers, UX designers, and a common set of names. So what that means is that when we're all working together, I can just call it by name. We need a carousel here, we need a slideshow here, we need a card list there. Whatever names we've come up with, we can just refer to them. I think an interesting thing is that we're actually now we're talking about creating a shorthand for visual design systems where, sure, I can write it down and we've got the names there, but it's like, wow, what if we could actually speak this out loud? Or what if we could take our wireframe and sort of take a picture of it and know those symbols and actually just even the machines could start to translate it we're starting to see that happen with companies like Airbnb experimenting with taking wireframe drawings and using machine learning to map those to design components that you can actually put into a page. I think that that shows the importance of being fluent in multiple platforms when you're designing for design systems, but also multiple inputs. And I think it's important to remember that we're designing not just for the screen now, but we design for keyboard only experiences or voice only experiences. At the same time, there's also a lot of excitement about emerging channels and emerging interactions about speech and about augmented reality and all these different new ways that we're able to talk to the machines. And a design system can capture those conventions too, as companies start to build those out. So for a speech interface, you may have a bot or an interface that has a certain personality, and that's something that should be recorded with common phrases, for example, for how you do confirmations, and different language around that. You could even have sort of some things like Alexa has, which are called speechicons, but a Bing, believe it or not, Alexa knows how to say. And so you can sort of build in these sort of flourishes as a set of libraries. In the same way that we have icons that we have in a system, you can have things like speech icons as a collection. All of this is to say that for every different channel that you use, there are likely to be guidelines and conventions that you want your designers and developers to use. And as much as possible, get that as close to the code. So here is actually the code snippet that you use for that SpeechIcon in your speech interface. For example, a design system consists of more than just a UI kit and a pattern library and a code library. It's also all of the different ways that you communicate and interact with customers. So it can include things like a writing style guide or voice and tone. If you think about voice and tone, that's also especially important as we have this emerging future of speech assistants and bots. What is the tone of your bot? How does it talk? Should it have a big personality or should it be sort of a neutral assistant? All of these things are things that as an industry, we're starting to figure out. But your company needs a point of view, and the design system should have that point of view too.