Episode 5 - Proven strategies for scaling your design system

Episode 5 - Proven strategies for scaling your design system

Josh Clark: 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.

Josh Clark: So Brad, 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?

SPECIAL SNOWFLAKES

Brad Frost: Yeah, sometimes there are special use cases that are product-specific. Maybe that's the self-contained mortgage calculator widget or something like that that only makes sense to one product. 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 special use-case components that only live with that product.

But the trick is to be able to audit that stuff and manage that stuff so that things don't get out of control because very quickly it can 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 the 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, so it's like "oh, I just want these form labels to be bold rather than normal font weight" 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 reduce the slow creep away from our visual standards, right?

And if a change should be made, 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 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 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 with the grain of the system rather than detracting from the system.

But then there are other use cases that, whether it's that mortgage calculator or that 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 build that component as a one-off.

But one thing that I've been advocating is for teams to 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 standardizes all of those unique special snowflake components.

So, then the design system team can come around and audit "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 elevate that out into the system." So, you're able to manage these one-offs in a way that still works with the grain of the design system process.

INTRODUCING VARIATIONS

Brad Frost: The workflow that we've tended to do is through the lens of real projects. We plug in the components as-is, as it currently lives in the design system, and see how it holds up.

If it needs some massaging, or we find that it's lacking some behavior, some style, then that might be an opportunity to, not necessarily tweak the core component, but to 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 would actually be really great if we had some sort of zebra-stripe patterns, so every alternating row in this data table has la 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, a pattern that says “dash-dash-striped” or something like that. Now we have this extra option if we need it. So it adds another tool to the toolkit or adds a new feature of an existing component that therefore makes it more flexible and robust and can travel to more places.

ENABLING CHANGE

Brad Frost: If something isn't working, then you shouldn't have to square-peg-round-hole it and force this component to do a job that it was never supposed to do. Rather think: how can this system include something else that helps solve this problem in a better way?
And what you're able to do is codify your contribution process and the process for changing a component or adding a component and to 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 say "okay, what does it look like if we need a new component? Who does that work? What if something similar already exists?"

So, that means that even the first users of the design system are able to, if they get stuck or if they're finding things not doing exactly what they need them to do, they know the path forward for making modifications or improvements or additions to the system.

DESIGNING ACROSS BRANDS

Josh Clark: Often you'll see something where it's, like, well, great. We have several brands that we need to address underneath our umbrella. We've seen that, for example, in publishing companies that have different media titles.

So, there could be a high-end fashion magazine, for example, and over here some sort of political magazine. Very different 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 this same design system could serve both those.

Yet when you go to their function of what they do underneath the hood, they are both reading experiences, media experiences that have 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.

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.

Dan Mall: When I think about different brands that exist in a design system, they should look like a family. Some of them can be siblings, some of them can be cousins, but they should be recognizable as part of the same family.

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 also what are the things that should be different?

That's a great way to think about themes. Every product in your design system could be a theme or be its own theme or adopt from a theme or inherit parts of a theme.

So, a lot of times we'll see an organization that has the need to make marketing products, right? Things that look really beautiful, really gorgeous and polished and spaced out and open and airy. But then at the same time, might have very dense apps that process a lot of data and things that 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 can be conceptual themes, they can be visual themes. I think part of a designer's job is to go, alright, 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. So that's one way to think about, “what are the commonalities across all of the different themes and the products that could inherit from those themes?”

DESIGNING ACROSS PLATFORMS

Josh Clark: 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.

There are a few different layers that you have to think of 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 platform language where things work a little bit differently on iOS versus Android versus the web. And you have to respect those native conventions.

Brad Frost: So, how you go about doing that? There's a bunch of different ways. What we've found is, it's helpful to create a technology-specific flavor of the design system. 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 as a project dependency.

This allows teams to grab that code and start building, using the design system's components, without having to manually copy and paste things over. So there is still some connection between the system and the products.

Josh Clark: So when you're thinking about a design system that goes across all these, first you have to create a consistent visual language and really nurture that, really work with the marketing and brand-focus 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. Those can be expressed as design tokens.

DESIGN TOKENS

Brad Frost: 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 Color Brand Red. So if you're Target, you have Color Brand Red is Target Red. 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 can 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 work in the tools that they're comfortable with, tools like InVision Studio or Sketch, and define the brand's color palette, neutral color palette, font styles, and things like that, and 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 pull that change down, which becomes a part of my normal dev build process, and I will receive that updated green.

This is really really powerful. This gets designers closer to working in the actual finished software product, but it also gives developers the power to control those variables and to thoughtfully integrate them into their code base.

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 have those changes propagate out anywhere those design tokens are utilized.

Josh Clark: 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.