Design Systems at Scale // Episode 5: Proven Strategies for Scaling Your Design System

Like a lot of companies, we started with a single brand on a single platform and a single product. And that was already enough work to sort of try to figure out how that goes. Over time, as we've seen this approach be adopted by larger and larger companies with more and more platforms or products or brands, sometimes all of those dimensions at once. You're seeing a design system used in all kinds of different ways and places, and that adds enormous complexity to the planning of this as well as to the use of it. A question that I hear a lot is, does every component in every project need to be in the design system in the first place? How do you decide what goes into the design system or does everything go in?

There are special use cases that are product specific. Maybe that's this sort of self contained sort of mortgage calculator widget or something like that that only makes sense to one product and it's fine to go ahead and build that as a one off component. And each product might have one or two or maybe even a handful of sort of special use case components that only live with that product. But the trick is to be able to sort of audit that stuff and manage that stuff so that things don't get out of control. Because very quickly it could be, oh, well, our product also needs this, or oh, we just need to make this one little tweak to this form component. Or oh, we just need to do this and then next thing you know, you're back to square one where each individual product is its own snowflake. And I think maybe the distinction is if you find yourself tweaking existing components, it's like, oh, I just, I want these form labels to be bold rather than sort of normal form font weight or something like that. Or I just need to increase the padding of these table rows just a little bit more. I think that those are situations that we want to avoid, right? We want to sort of reduce the sort of slow creep away from our sort of, you know, visual standards, right? And if a change should be made, right, if there's a rationale for why the team is trying to make that change, then they should coordinate with the design system to make sure that, hey, we, we actually need these things to be a bit more prominent or a bit more chunky. And here's the rationale for them. And collectively together you can sort of come up with a variation of a component that then serves that use case really, really well. So that's a way of doing that in sort of a, with the grain of the system. Rather than sort of detracting from the system. But then there are other use cases that, yeah, whether that's that mortgage calculator or that just really complex bit that only makes sense for one product. Sure, there's going to be times where the team that's working on that product can go ahead and put their head down and sort of build that component as a one off. But one thing that I've been sort of advocating is for teams to sort of build those one off components and place them into the same place in their product code bases. So maybe you have a folder called one offs or something like that across all of your different products. And what this does is sort of standardizes all of those unique sort of special snowflake components. So then the design system team can sort of come around and audit like, oh, how many one off components do you have? And like, oh, maybe this looks like a good candidate to extract into the system. Or oh, this one product is using it and this other team is asking for it. So maybe we can sort of elevate that out into the system. So it's sort of, you're able to sort of manage these one offs in a way that still works with the grain of the design system process. The workflow that we've tended to do is sort of through the lens of real projects. We sort of plug in the component sort of as is as it currently lives in the design system and see how it holds up. And if it needs some massaging or if we find that it's lacking some behavior or some style, then that might be an opportunity just to not necessarily tweak the core component, but to maybe create a stylistic variation of it. So let's say we create a data table pattern and we plug in all this data inside of it through the lens of one of our projects and it's like, wow, this looks like a lot of data. This is really hard to parse. And it'd actually be really great if we had some sort of zebra stripe patterns. So every alternating row in this data table has a light gray background, for instance. The current design system doesn't support that yet. So what can we do? Well, let's create a variation of that pattern so we can add a class onto our data table pattern that says dash, dash, striped or something like that. And now we have this sort of extra option if we need it. So it sort of adds another tool to the toolkit or adds a new feature of an existing component that then that therefore makes it more sort of flexible and robust. And can travel to more places. You know, if something isn't working, then yeah, you shouldn't have to square peg, round hole, you know, sort of four force this component to do a job that it was never supposed to do, but rather sort of think, how can this system sort of include something else that helps solve this problem in a better way? And what you're able to do is to sort of codify your contribution process and the process for changing a component or adding a component and to sort of bake that process into your style guide. Before the system even exists, before it even hits an MVP state or a 1.0 state, you're able to sort of say, okay, what does it look like if we need a new component, who does that work? Right? What if something similar already exists? So that means that like even the first users of the design system are able to, if they get stuck or if they're, you know, finding things, not doing exactly what they need them to do, they know the path forward for sort of making modifications or improvements or additions to the system.

Often you'll see something where it's like, well, great, we have several brands that we need to address underneath our umbrella. And we've seen that for example, in publishing companies that maybe have different media titles. So there could be a high end fashion magazine for example, and then over here some sort of more political magazine, very different sort of brand or feel. And you might look at that particularly from the inside, if you're attached to one of those brands as being like, there is no way the same design system could serve both of those. Yet when you go to their function, sort of what they do underneath the hood, they are both reading experiences, media experiences that have the same similar models of navigation. So you can create models that serve those functional uses and then create brand themes on top of those to address those individual brands. So a design system can serve multiple brands very well in the same way they can serve multiple products, even if they have a different look and feel.

And when I think about different brands that exist in a design system, they should look like a family. You know, some of them can be siblings, some of them can be cousins, but they should be recognizable as part of the same family. And so one of the ways that designers can think about how to do that well is to think about, well, what are the commonalities, what are the things that should exist across different products that we make? And, and also what are the things that should be different? And that's a great way to think about themes. Every product in your Design system could be a theme, could be its own theme, or could adopt from a theme, or inherit parts of a theme. And so a lot of times we'll see an organization that has the need to make marketing products, right? So that's things that maybe look really beautiful, really gorgeous and polished and spaced out and open and airy, but then also at the same time might have very dense apps that process a lot of data and things like that, and things that maybe are internal to a team or internal to a particular customer or on the enterprise side. That doesn't mean that both of those things can't exist in the same design system. It just means maybe you need two different themes, maybe you need a dense theme, or maybe you need a marketing theme and you can name the themes whatever you want. Some teams have a blue theme and a white theme.

That's fine too.

So they could be conceptual themes, they could be visual themes. I think part of a designer's job is to go, all right, what are the things that should be common across those. We all have the same eye color, for example, and what are the things that could be different? Some of us have beards and some of us don't. And so that's one way to think about what are the commonalities across all the different themes and the products that can inherit from those themes.

I think a trickier thing to handle, frankly, is how to build a design system that works across platforms. And here, I mean, a design system that will work for the web, but also for iOS and also for Android. And then there's a few different layers that you have to think of it there as the umbrella above all of this. You have the brand and the visual language of the brand, but then you also have this sort of platform language where things work a little bit differently on iOS versus Android versus the web. And you have to respect those native conventions.

So how you go about doing that, there's a bunch of different ways. What we found is actually it's helpful to create sort of a technology specific flavor of the design system. So let's say the REACT flavor of the design system and then individual applications that are using REACT to build the front end of their applications can then consume the REACT flavor of the design system and as a project dependency. And what this allows teams to do is to sort of grab that code and start building using the design system's components without having to manually copy and paste things over. So there is sort of still some connection between the system and the product.

So when you're thinking about A design system that goes across all those. First, you need to create a consistent visual language and really nurture that with, really work with the marketing and brand folks to make sure that that reflects that and then marry that to the individual platforms. A design language can be expressed in many ways, but at its core are these simple brand attributes, and those can be expressed as design tokens.

Design tokens are implementation agnostic design properties that might sound a little esoteric, but that's what they are. So any developer will know what a variable is, right? You say you know color brand red, right? So if you're target, you have color brand red is target red, Right. Or you might have a specific border radius value that you use for all of your digital products, or you might have a specific font face you use for all of your products. All of these design properties are what help build a brand. You could sort of refer to them as subatomic properties. Right? These are the properties that ultimately make up your user interface. So InVision Design System Manager is a tool for managing design tokens and integrating them into your team's workflow and tools. It's really exciting because it allows designers to sort of work in the tools that they're comfortable with, tools like Envision Studio or Sketch, and sort of define the brand's color palette, neutral color palette, and font styles and things like that, and just sort of beam those up to the cloud. So that means that if the brand green changes, the designer can make that change, sync that up to the cloud, and then as a developer, all I have to do is sort of pull that change down, which becomes a part of my normal dev build process, and I will receive that updated green. And this is really, really powerful. This gets designers closer to working in the actual finished software product, but also gives developers the power to sort of control those variables and to sort of thoughtfully integrate them into their code base. Yeah. Design tokens provide a single source of truth for these crucial design properties that designers and developers can change in one canonical place and then sort of have those changes propagate out anywhere those design tokens are utilized.

All these things are ways that basically want to say that the job of the design system is to reach out, curate, and pull together and collect all of the different guidelines and conventions that are used across every discipline, across every channel, across every brand, and have it in one place. So it's really easy to find and reach for and hopefully to put even into the path of my workflow so it's not some reference off to the side.