Config 2025: Building design systems together with Jake Albaugh & Chad Bergman | Figma

[Music] [Applause] [Music] We're so excited to be here.

Hello, my name is Chad. I am a designer advocate here at Figma. And I'm Jake, a developer advocate at Figma. And as advocates, we work in the

Figma. And as advocates, we work in the community with customers, sharing best practices while learning how folks are working with Figma so we can bring that back to our product

teams. Today, we're going to be talking about building design systems together. We're going to break it up

together. We're going to break it up into two sections. In this first half, we're

sections. In this first half, we're going to be talking about design and design systems. And in the second half, we're going to hop into some files and the codebase to see how it all plays out.

So, let's get started. All right, Jake. So, design

started. All right, Jake. So, design

systems, huh? They're drivers of consistency, efficiency. We don't have to reimagine

efficiency. We don't have to reimagine everything every time. But sometimes we

time. But sometimes we do. We do, right?

do. We do, right?

Why is it just because we want to? Or

maybe we don't really have a system yet. Today we're going to be talking

yet. Today we're going to be talking about building design systems, but we're not going to talk about starting from scratch. All right, defining our color

scratch. All right, defining our color and our type ramps, building our very first components because there's already a ton of fantastic content out there around that. Whether that lives on

around that. Whether that lives on Figma's blog, Shortcut, designsystems.com, and so many places all over the internet, where maybe you've even created some of that content

and shared it with the world. But Chad, before we go any

world. But Chad, before we go any further, I've got something I'd like to get off my chest. All right, Jake, I'm going to let you get to that.

Amazing. The future is very exciting.

We have so much to look forward to in product design and in development. But the

development. But the present, it's kind of feeling a little bit chaotic. New

chaotic. New technologies shifting paradigms, artificial job applicants, and an alarming number of sci-fi plot

points playing out in real life.

We're left asking ourselves what changes, what stays the same, and I think most

existentially, what is our place in it all? Well, we have some

all? Well, we have some answers. We know that design is

answers. We know that design is important. I know. I know. Controversial

important. I know. I know. Controversial

take for a Figma conference.

pick those jaws up off the floor. But in

a time where so much about what we do and how we do it is rapidly changing, I think it's important to start with the one thing that will

always stay the same.

Design is important to designers, to developers, and to those who hear the phrase boolean properties and

think. I don't know if I've seen that

think. I don't know if I've seen that one yet. We all desire to be

yet. We all desire to be considered and good design is considerate. And this is a deeply human

considerate. And this is a deeply human thing.

And that's why design is bigger than simply the way things look. Design brings

look. Design brings consideration into a product. And this

is so much greater than a theme or something you can just handwave around and dismiss its core purpose. We also know it's never been

purpose. We also know it's never been easier to make something. And that's

incredible news, too. But we know standing things up is

too. But we know standing things up is the easy part, but making meaningful things is hard. What delights a user? What enders

hard. What delights a user? What enders

them to our products? Well, we know that touch makes

products? Well, we know that touch makes products meaningful. Touch is how we

products meaningful. Touch is how we consider the experiences of those that we design for.

So when we ask ourselves what should be automated, a framing that I prefer is what should be left to touch. And boy is that a question we

touch. And boy is that a question we hear all the time in design systems. Walking the line of flexibility and

consistency is hard and ultimately a question of touch.

So design is important, arguably more now than ever before, and design systems are the abstractions that help make that design

real. That's the good

real. That's the good news. But let's be honest, design can

news. But let's be honest, design can often be a very inefficient a part of product product development. Despite its importance,

development. Despite its importance, design intent can be hard to see through to production. And this is because

production. And this is because designing and building are different. Product design requires

different. Product design requires expression discovery iteration. It's far easier to iterate on

iteration. It's far easier to iterate on things in a malleable state, and design tooling provides that flexibility. With

new tools like Figma make code can also be a medium for discovery and increase the fidelity of the experience. But that's very different

experience. But that's very different than production code. Production code is about precision

code. Production code is about precision and execution more than it is exploration. And in this sense, two

exploration. And in this sense, two distinct environments are required to make a good product real. And this is why pixel perfect code

real. And this is why pixel perfect code is often not the right code. The perfect

code is aligned to design intent, not pixels. Here's a simple

pixels. Here's a simple example. There are many ways to describe

example. There are many ways to describe these four columns visually. We can see fill container 400 pixels quarter

25%. There are also many ways to

25%. There are also many ways to describe this in code. If we were to refer to this kind of flexible behavior with flex and CSS, we can account for

that with something like flexbox. Or we can do calculations that

flexbox. Or we can do calculations that account for the size of those three two REM gaps between each column. But these quarters might

column. But these quarters might transform into thirds on different devices. And now our nice round values

devices. And now our nice round values are looking pretty gnarly. In code, we have to now go and

gnarly. In code, we have to now go and change these values that are in our calculation cuz this is now two gaps split three ways. And so what ends up happening is

ways. And so what ends up happening is we abstract this on the code side. And

our calculation might look something more like this. It's more flexible. It's

more complicated, but it's more flexible. And as we can see, this has

flexible. And as we can see, this has made quite a departure from the paradigm that we had in design.

It's because design and code are optimized differently. Even in that last

optimized differently. Even in that last example, the patterns we build around design and development had discrepancies and variance. This isn't a

variance. This isn't a problem. It's actually a good

problem. It's actually a good [Music] thing. We're approaching the same

thing. We're approaching the same destination from different points of origin.

Therefore, not all of our routes towards that destination are going to be parallel. While our abstractions may

parallel. While our abstractions may occasionally be at odds, it's helpful to recognize that we actually share a love for patterns. There's nothing worse than

patterns. There's nothing worse than spending a bunch of time crafting something than changing your mind and needing to manually update things across many different places. patterns. Get

this out of that problem. We make abstractions to make

problem. We make abstractions to make building easier. Whether this is

building easier. Whether this is behavioral patterns, typography patterns, file structures, naming conventions, information architecture, these are all examples of the ways

designers and developers build abstractions.

Patterns also make things usable for people and that is a human- centered pursuit. In the case of design systems,

pursuit. In the case of design systems, designers and developers, we consider the future maintenance of what we are creating that some future designer or

developer are going to have to perform on our code or our design.

We also consider the experience of the people that will be using those same patterns as users in the product. Design

product. Design systems are where we can apply our consideration for people and passion for patterns towards

a shared outcome. They're a perfect blend of codebase and design abstraction that when executed well are easy to

maintain, iterate on, and hand off to others. So, what is an approach to this

others. So, what is an approach to this look like? I'll hand it to you,

look like? I'll hand it to you, Chad. Thank you, Jake. That was awesome.

Chad. Thank you, Jake. That was awesome.

Oh thanks Chad.

All right. So, as Jake was saying, the first

right. So, as Jake was saying, the first thing we can do is start recognizing and leading into the patterns around

us because patterns create efficiency. They stem from our aligned,

efficiency. They stem from our aligned, repeatable decisions that were made at least at some point along the way. And

when we can repeat things, it helps us to get faster, hopefully with less frustration because it's already been done at least once. All right, question for y'all.

once. All right, question for y'all.

Raise your hand if you've reused a color, a button, spacing, value, whether this is in design or

code. All right, seems a lot of us have

code. All right, seems a lot of us have reused stuff, right? Well, great. You've

used a repeatable pattern. And after

all, as Jake said, designers and developers, we love patterns. We're both

pattern-minded. We design our reusable patterns around things like typography, spacing, scale, layout, and color. And

then we reusable patterns to make our design language come to life in a product.

And though design and code are different languages, we have the same goal and we're building the same thing. As designers, developers, we want

thing. As designers, developers, we want to reduce rework. We want to make sure that we are staying consistent in the work we're doing. And we ultimately want

to move faster as we build. I think it's safe to say that we want to make it so that the next thing is easier to build than the last.

So instead of orienting our perspective around, well maybe I'll get 70% of what I intended with this design, we should think about achieving

100% of what we can build when we do it together. And yeah, design systems are

together. And yeah, design systems are great for helping with this. Whether

we're building a system or we're consuming assets from a system in our designs, if we're working together towards the same goals, we should be

able to get to 100% of what we intended when we're doing it together. All right, one more question

together. All right, one more question for you. Do you have a design system?

for you. Do you have a design system?

We've reused patterns, but raise your hand if you work with a formal recognized design system with your organization. Maybe you have some

organization. Maybe you have some dedicated resources including teams of one. All right, awesome. Now raise your

one. All right, awesome. Now raise your hand if you have something that maybe it's not a formal design system. Maybe

it's something scrappy or informal. You

question if it's a system or not, but it helps you out. All right. Awesome.

out. All right. Awesome.

Well, like I said, if it's repeatable pattern of some kind, if it helps bring efficiency to your work, it's kind of a system in some way, shape, or form. And

I think we can say that we're kind of all on a design systems journey in one way or another. Maybe right now you have a

another. Maybe right now you have a halfozen, maybe a dozen color styles.

You might have some variables, handful of components, t-shirt size, naming conventions. Your buttons, they might be

conventions. Your buttons, they might be blue. Not for any given reason other

blue. Not for any given reason other than your brand team said, "Hey, let's have blue buttons." And it may not look like other

buttons." And it may not look like other design systems that we learn from. UI

kits in the Figma community. Checking

out public-f facing code repos and documentation sites. The ones that we

documentation sites. The ones that we love to gain inspiration from semantically named variables, intuitive component architecture, clear guidance

documentation with product use cases already accounted for. The dream or is it? Keep in mind that your design system

it? Keep in mind that your design system in whatever state it's in, it's real and it's addressing your current needs and those for your organization at this

point in time today. That's what's

important. Solving for the needs of today. You don't need to build out a

today. You don't need to build out a meticulous system in anticipation of any future well what if use cases that may

not actually come to be. After all, I mean, product teams,

be. After all, I mean, product teams, they're generally going to move faster than design system teams. So, if you're working on a design system, it's okay to address those future needs as they

happen in the future once you know what those real use cases are.

And no matter what size or shape that your system starts in, there's going to be time at some point, whether that's months later, weeks, maybe even days or

hours, your system will run into some new use cases and it's going to need to grow. And I think it's important to

grow. And I think it's important to acknowledge that when a system is growing, it could introduce friction.

You know, things they start to happen one by one. They may seem innocent. We

start to add some variables to the library. Maybe we create a few new

library. Maybe we create a few new components. Those blue buttons now have

components. Those blue buttons now have eight more variants for use in different product areas. And our t-shirt sizing scale. We

areas. And our t-shirt sizing scale. We

need to add a new value in between medium and large. I mean, we could shift our values, but that could break things, right? Well, we'll just introduce a new

right? Well, we'll just introduce a new size like midarge. Or what about when we need

midarge. Or what about when we need something that has to exist outside of any existing convention in our system because marketing experimentation,

right? The system starts to hit its

right? The system starts to hit its limits in its current state because it's shifting to meet the real use cases of those who are using the system. It

doesn't mean that the system is broken.

It's all right. It means that the system is maturing because hitting the limit can be a sign of growth.

After all, we're not just reusing colors or components anymore, but we're starting to build these larger, more connected, more composable patterns. Things we think of like maybe

patterns. Things we think of like maybe different variations and treatments for cards, modals that have different behaviors or notifications that need to show a specific icon or call to action

depending on the context that they're used within. These are just a few examples

within. These are just a few examples that we may be familiar with. really the

list can go on and on. And as we start to increase that

on. And as we start to increase that complexity, it it's okay. It can feel a bit overwhelming because now you make a change in just one place and it might touch five

others. That little simple variable

others. That little simple variable update, well, it might break a pattern or a new variation. We have to make sure that we're accounting that it'll work

across a light mode, dark mode, high, low, contrast, maybe four different densities, all while ensuring that all of our accessibility standards are

met. So when systems are evolving,

met. So when systems are evolving, collaboration and alignment become even more essential. So where are some areas that

essential. So where are some areas that we can align as we start to evolve our system?

Well, first and foremost, we need to make sure there's alignment around the scope of these updates and our responsibilities. How are decisions

responsibilities. How are decisions going to be made? Like Jake said, what's flexible and what's fixed? What makes a pattern useful and scalable? And also the question of, hey,

scalable? And also the question of, hey, should this even exist in our design system or should a product team own this for the time being?

We also need to make sure that we have alignment on working within our constraints. What that means is planning

constraints. What that means is planning for the impact of cascading changes across the system and anywhere that those are used in designs. We ultimately

want to mitigate breaking changes as much as possible. Think about typography as an example. If we change our base font weight from regular to medium,

that's going to cascade through nearly everything in the system. Also, we need alignment on how

system. Also, we need alignment on how we're going to plan for and address invisible states. Teams, they implement

invisible states. Teams, they implement forms differently across different features or what happens when there's user provided content that maybe we

haven't considered in our design systems concepts.

And finally, you know, make sure that we're aligned on how we're optimizing our patterns for where and how people are going to interact with them. If

we're building something responsively, is it pixels or percentages, flexbox or grid? How are we going to refflow

grid? How are we going to refflow content across different screen sizes?

We also need to align on items that are often not factored in to our designs, but they're required in code. focused

visible states, tab ordering, Arya labels and roles. We need to make sure we have alignment around this because ultimately what I'm trying to say is we want to make better

decisions for our design systems together. And that's one of the real

together. And that's one of the real unlocks for a mature system. It's not just making more

system. It's not just making more components to have a bunch in there, variables, tokens. While automation

variables, tokens. While automation documentation is cool, it's not that either. It's the shared understanding

either. It's the shared understanding and responsibilities between us as designers and developers as we're working

together. So, let's take a look at what

together. So, let's take a look at what this collaboration can look like in practice. Yay, demo

practice. Yay, demo time. Nice job, Chad. Thank you,

time. Nice job, Chad. Thank you,

Jake. All

right, so here's what we're building. Chad and

I put together a nice little uh company called VHS Vault where you can rent VHS tapes through physical mail. Um you

might have seen some trailers for these movies uh and and be interested in watching later. Um but we also have in

watching later. Um but we also have in addition to a homepage, we have a nice product page. We can see Boolean

product page. We can see Boolean Properties 2 just came out. That's

exciting.

Um, we also have a checkout flow uh and uh an account page as well. We're using

grid in here which is really exciting.

Um, but in addition to kind of these product designs um we also have it working over here. So we've built out a very basic design system in code using

web components to represent this. Um, we

didn't build an entire design system.

That would be a really wild idea to try and do that before config. Who in their right mind would do that? I don't think we're at that scale. But we do have kind of a basic one right here. Um, and so we have just a couple components that we're going to talk about today as well as

some text styles represented. But let's go back over to

represented. But let's go back over to the design file and introduce you to rewind, our design system for VHS vault.

Um, so this is rewind. Uh, and we're gonna rewind back in time historically to the beginning of our design system, Chad, where we were doing styles and color palettes. Ah, it was a much

color palettes. Ah, it was a much simpler time. It was a simpler time.

simpler time. It was a simpler time.

Remember, it was like it was yesterday.

I know. I mean, I think you know these styles we had this color palette. It was

very easy. Oh, that naming very simple green 300. It was perfect. But as we

green 300. It was perfect. But as we started to grow, we realized that on the development side, we had already started to factor in dark mode and we were using

design tokens. So we started to think,

design tokens. So we started to think, should we maybe introduce some parody in our design assets and go start introducing variables? You know, we were

introducing variables? You know, we were okay at the time having a little bit of a difference there, but we decided that we're we're going to hit fast forward.

we're going to need to introduce our light and dark mode in our design files as well. So, we started to create variables

well. So, we started to create variables and look at that, we started to have some semantic naming in there, drawing inspiration from the code that we already had. But where this started to

already had. But where this started to introduce some complexity for designers is that we have the same colors

represented multiple places.

So, we wanted to make it so that way we could make it easy to find what colors designers needed to use. And this is where with our library, we decided, let's scope these so that way when

people are using them, they're only going to see the colors that they need to see in that moment. For example, here we have our container. And if we scroll

down here, we're using a color background primary, but we still have a hex value here for the stroke. I'm going

to go ahead and pull this up. And we can see I'm only seeing my border variables here, which is perfect. That's all we want people to see. So, we can easily

apply that. Same thing if we were to go

apply that. Same thing if we were to go into the text and maybe want to change it. We have just our text showing here

it. We have just our text showing here for us. Now, this didn't mean that we had to

us. Now, this didn't mean that we had to completely get rid of our styles yet because they're still in use across some other explorations. But what we did do

other explorations. But what we did do to optimize the designer experience is we applied those variables as the background for each of these styles. So

when we decide in the future that we're going to deprecate those color styles, we can make sure we push on update. We

can remove those and then those consuming files will have the variables right there. Now the other thing that we have

there. Now the other thing that we have with this and everything being bound is if we flip over to dev mode right here and we start to take a look, you know, I

changed this to our we're in swift UI right now. Ah I was doing some special

right now. Ah I was doing some special demo work earlier today. Let's switch

over to CSS. Yeah, we're not ready to build a mobile app yet. Not yet. We

don't even have a mobile screen design.

So, we will get there. Yeah. And so, we can see here we've got our variable. All

right. Color, text, brand. We've got our fallback here. I mean, Jake, this is all

fallback here. I mean, Jake, this is all we need, right? You would think so, Chad. You would think so. So, we've got

Chad. You would think so. So, we've got some cool little variables over here.

and and Figma's kind of default code syntax is pretty great to have, especially if we're going to be creating these tokens over on the codebase side, but I'm going to rewind a little bit to

kind of where we started on the code side. And a lot of times teams that find

side. And a lot of times teams that find themselves in this place where they have styles in Figma and are using hex codes over in the codebase somewhere. Your

developers are likely creating their own patterns, whether you know it or not, around these things at that early stage.

Now, as design systems people, we might look at that and be like, well, that's, you know, that's design systems for babies, but this is actually emblematic of a app and a stage in an app's growth

where you're considering the user, you're iterating, you're learning exactly what it is you're building. Um,

and so I think it's actually a really healthy thing to find yourself in this sort of a state. Um, so on the code side, we have some variables representing those styles that we had.

um as well as kind of the color palette for some of those primitive colors. Um

but eventually Chad, we're going to move over to something that looks a little bit more like this where we have these custom properties described for our um primitives, but then we use aliasing and

map custom properties in CSS to other custom properties. Um this is what

custom properties. Um this is what aliasing looks like if you uh know the if you're familiar with it in Figma, but not in code. Um, but then we also have our dark mode defined here as well. Um,

with the same tokens described just within the context of of dark mode, uh, as well as some typography down here.

But for a lot of folks, these files can get pretty massive, right? And so I've actually using the plug-in API written a script that can export all of our

variables as JSON. And then I wrote a script that can parse that and create this file for us. So that's a way where collaborating across design and development can help create some of these patterns on the code side. They're

a lot easier to maintain once you're in this initial state. But also, you may have noticed

state. But also, you may have noticed that we have a prefix in here, the RW for rewind. And this is something that

for rewind. And this is something that happens all the time in code bases. We

have lots of variables describing lots of things and only some of them are scoped to the design system. So we add a prefix to them to make sure that everybody knows this is the one from the design system. It's easier to keep

design system. It's easier to keep things organized that way. But when we come over to Figma, Figma doesn't have any idea that that concept exists, right? And so one school of thought would be, well, we

should just force Chad to start adding that prefix arbitrarily on the Figma side in order to kind of have that autogeneration map. We don't need to do

autogeneration map. We don't need to do that. Um, we have a feature inside of

that. Um, we have a feature inside of Figma called code syntax. Anyone aware

of code syntax? It's my favorite Figma feature. Um, you can kind of come in

feature. Um, you can kind of come in here and for any of your variables, I saw like four hands. That's amazing. Um,

and in the variable editing dialogue, you can manually add code syntax for all the different platforms we have. Um, uh,

native codegen support for. So, the web one, we could come in here and we could start writing uh, we could say var rw brand subtle if we wanted to. Um but

doing that for every single one of our variables little time consuming. So on

the code side when I have a script that generates this file that script knows what the name of the variable is. So,

one of its other outputs is this handy dandy little plug-in API uh piece of a uh plug-in API that we can now copy and we can come over to Figma and we can

open the JavaScript console which is my favorite Figma feature and we can run this and we have just set code syntax programmatically for every single one of

these variables. And isn't that nice?

these variables. And isn't that nice?

Now, when we come over here and we click on this container, thank you for the clap.

No more clapping. There's so many other things. Okay. So now we can see over in

things. Okay. So now we can see over in dev mode our uh CSS code generation in Figma now has the context of your codebase, right? Which is often very

codebase, right? Which is often very different than the context that only lives inside of Figma. Um we can click on these which is awesome. So if we want to see how these variables behave and different themes um we can see any code

syntax that's been applied to them here which is super exciting.

I'm checking my notes. I want to make sure I'm not forgetting anything. So,

Chad, we've replaced styles kind of with variables here. What what why do we

variables here. What what why do we still have styles? Oh, I mean, we could probably get rid of the color ones, but you know, we'd still have a good use for them. And that is with typography. I

them. And that is with typography. I

mean, typography. So, typography is a great place for us to still use styles because our styles kind of act like composite tokens. We can have multiple

composite tokens. We can have multiple variables bundled together and they are distributed via a style. Now, on the designer experience side, nothing really

changes. We still apply our styles

changes. We still apply our styles exactly as we would. If we want to change our display here to title, we could. But let's just change that back

could. But let's just change that back to display. But what we have is the

to display. But what we have is the ability to use some variables in there.

So we have our font family set. We have

our font weight. But maybe we want precision to always say that our line height is going to be fixed at 56. Or we

could put a percentage there. Maybe our

letter spacing is going to be a negative percentage. We can combine variables and

percentage. We can combine variables and raw values. put them together in a style

raw values. put them together in a style and they're used just the same as they are today. But there is a bit of a

today. But there is a bit of a difference here when it comes to applying typography in code. While we

have friendly titles for our styles in Figma, we're usually going to apply them via a CSS class name in code. So we

documented that in our library here. And

that's great if we are working with semantic HTML and CSS, but it can be a bit different. It's a completely

bit different. It's a completely different medium, right? So here we have an H1 and that has meaning for both the hierarchy and for

accessibility. Just because it's an H1,

accessibility. Just because it's an H1, it doesn't mean, hey, this is big text.

that H1, it could be our display style, it could be our title, it could be our heading. It all depends on the context

heading. It all depends on the context that it's used within. So here we've applied a class to

within. So here we've applied a class to make the H1 our heading style. But then

we also have things like our paragraph tag or strong or M where they're going to likely inherit our base body style by

default. So we don't need to apply a

default. So we don't need to apply a class for that. But our developers, they might

that. But our developers, they might also build out components for typography. And in this case, it's not

typography. And in this case, it's not using that class name directly. Rather,

it's going to apply a prop. And that may have a very similar name to our style in Figma. So we make sure that our designer

Figma. So we make sure that our designer experience hasn't really changed using styles in there. You know, Jake, how does this improve our developer experience? So, people build typography

experience? So, people build typography stuff in so many different ways in codebases, and it's often aligned to what is most easiest for developers to

author text styled the right way most easily. Um, and I think that like this

easily. Um, and I think that like this is a great example that we're looking at here of how, you know, we optimize to the same thing from very different

points of origin, right? Um, so yeah, I I have another component that I think we should we should dig into. Are you cool with that, Jake? I thought we weren't going to do that. Okay. Well, now it's

time for everybody's oversimplification of design systems in one component, and that is the button. All right. So, I'm actually

button. All right. So, I'm actually going to start over here in the codebase. And we've described this

codebase. And we've described this button. And this button has a few

button. And this button has a few different variants, a disabled state, and it also has this state with an icon.

The developers in the room might be like, "Yeah, no big deal. I see you."

Um, but one little interesting thing here is that the padding on the left hand side of this button is different when there's an icon than when there is an icon. We have this optical alignment

an icon. We have this optical alignment here. When we think about how this is

here. When we think about how this is constructed over in Figma, as we go to add this to our button, as a developer, this is all I'm really thinking about,

Chad. I'm thinking about what is the

Chad. I'm thinking about what is the padding left for the button by default.

In this case, it's a variable we called button padding x. And then when there's an icon, we just do a calculation that cuts it in half. We could also assign a smaller

half. We could also assign a smaller padding there, too. True. But it's

ultimately this simple. How are you thinking about it? Well, I'm glad that we talked about this and you know, I I agree. You know, let's let's take a look

agree. You know, let's let's take a look at what this looks like in practice here. So, we have our button. Yeah, in

here. So, we have our button. Yeah, in

here chevron. All right. Well, that

doesn't look great. And I agree, you know, it looks a lot better and I'm glad that we're going to go ahead and change that. Now, on the design side, it's

that. Now, on the design side, it's optimized differently, right? So we have a few different ways to think about this. We could take the approach of

this. We could take the approach of creating a variant because it is a completely different visual approach to it. Variants are appropriate when you

it. Variants are appropriate when you have visual changes. But when we think about this

changes. But when we think about this and we look at our instance right here and we want to change it, it's not immediately clear if we can add an icon

to our button. you know, if we're coming into the library, it's being used as a sticker sheet. Sure, we know that we

sticker sheet. Sure, we know that we have icons there, but maybe it lives in design here. Okay, cool. There's a

design here. Okay, cool. There's a

primary and an icon. But if we rewind and we think

icon. But if we rewind and we think that, hey, we need to add those additional colors, right? We're now

going from having 16 variants in our button. Do the math. We're now looking

button. Do the math. We're now looking at 80 variants to have an icon there.

And what if we want to do an icon at the end and we're already down that path of the variant approach? Well, we now have 160 variants that we need to maintain.

That's nuts. And I guess what if you did both? Well, we'll let you do the math

both? Well, we'll let you do the math there, right? So, we're likely going to

there, right? So, we're likely going to go with more an approach like this where it's more similar to code and we're using props. Now, this does create some

using props. Now, this does create some burden for us on the design system side of it because we have to think how we're going to do that. We can't just simply

drop an icon into the button and say, well, if it has an icon, let's then change the padding on there. So, we're

going to put the icon in a frame here and then we're going to offset it. So,

you know, we'll do that in the system.

So, that way designers don't have to override things or start detaching it, but we can see that it's self-documenting in a way that all right, does the button have an icon? All

right, it does. It's there. We can also add that instance swap prop on there.

Change out the icon. And

perfect. Now, let's see. That's a lot more line to code. Absolutely. And if we take a look at what that looks like in practice here, let's go

in. It looks like here we've got our

in. It looks like here we've got our buttons and we click into that. Awesome.

We can change that out. Maybe go to a cart instead of the basket. And if we toggle into dev mode

there, code connect. Yeah.

So, we have that in there. And you know, while we're here, let's just go ahead and take a look around at may what else we can take a look at

here. Uh oh. Uh oh. All right, Jake. I

here. Uh oh. Uh oh. All right, Jake. I

know we don't have this as a background.

Yeah, I don't recognize that either. Who

did that? Let's take a look. Uh oh.

Detach component on there.

M but I mean I I think that you know we go back and we look at the library here and we

default to that success state and we have a warning here we have or an alert we have danger on there. Um we can't

default to success but it looks like maybe we need to look at adding another variation here. Um Jake what does this

variation here. Um Jake what does this look like on the code side? What are we doing by default today? Well, I've taken a preview peak and it's actually kind of

gnarly, Chad. Um, so if we look over at

gnarly, Chad. Um, so if we look over at how this has been implemented, a developer actually ended up creating this, which is great on their end. They

did technically do what was designed.

Um, but there are some things here. They

actually ended up finding a workaround in order to achieve this. When we go and we look over at how the developer built this out, they are using the right

component here with our little notification. But they've used the CSS

notification. But they've used the CSS custom properties to override the internal style to bring in that custom hex color. They're using our system.

hex color. They're using our system.

They're using tokens. Good on them. Um,

but they've kind of exposed a little bit of an exploit in how this component was actually defined in the codebase. And

what it is, when we come back over here to the library, we'll see that there's this weird no man's land zone for this

notification component. And in this

notification component. And in this state, there's no real background color, but you can customize the icon in a way that you can't with these other three.

It turns out in our system, we've associated an icon with the emphasis variant, which is the color, and we don't want that to change. But some

developer realized if you don't provide an emphasis, you can actually provide a custom icon. I don't know who wrote that

custom icon. I don't know who wrote that code, but that's something that we want to consider when we think about the designer and developer experiences and why designers are creating notifications

with custom icons. But what we want to do is we want to make it so that that pattern is considered in our system. And

what we would probably want to do in this case is continue the three patterns we have of enforcing that an emphasis and an icon are an important pairing,

but then create another variant for maybe custom notifications that might have distinct icons and distinct text.

But we don't necessarily want it to look like this. What we probably want it to

like this. What we probably want it to look like would be something like this that I have pre-baked. And I'm just going to add a custom info variant

here. Oh, I'm sorry.

here. Oh, I'm sorry.

Emphasis. Thank you,

co-pilot. There we go. Right. So, this

is what we're going to try to build. And

within that, we can still change the icon. So, if I come in here and I write

icon. So, if I come in here and I write lock, we get the lock. But if a developer comes in here and tries to do something sneaky and say the emphasis is

success, that gets defaulted back to the icon that is associated with that. Now,

how hard, Chad, is it for you to build a pattern like this in Figma? Well, I

mean, the system is growing, so I think we need to do that. And, you know, if we were to jump back over here and take a look at our library, it's actually pretty straightforward for me to do

this. Yes. Do you want me to do a

this. Yes. Do you want me to do a countdown? Let's go for it. All right.

countdown? Let's go for it. All right.

Three, two, I'm done. Ah, that was easy. All

right. So, actually, I already made them, but still, we're just adding another variant in this case, and we are applying our variables to it. Now, this

gives us the flexibility where we can add that icon swap on there. So, similar

to in code, we can specify a different icon for it. So, if we were to I'm just going to take a copy from right here and let's go into our

designs and we will go ahead here and replace

that keyboard shortcuts. The keyboard

shortcuts. So, we have right here our old notification. Let's just paste our

old notification. Let's just paste our new one in there. There it is.

And we have that new notification in there. We could go ahead and customize

there. We could go ahead and customize that. We can change out that icon to

that. We can change out that icon to something else that we want to have on there. Uh we could go ahead and fill the

there. Uh we could go ahead and fill the container and start to build this out.

Yeah. But like Jake showed, you know, maybe we want to ensure that this is the only one that has our instance swap.

Now, we didn't have that available to us on our other ones. So if we do the same thing and switch over to success, we can see that it's still showing us our check

mark there. So we can start to align our

mark there. So we can start to align our pattern here between design and code.

And if we switch this back and let's go to that info and we switch over to dev mode here, we can see ah look at that.

I've already written code connect for it. So we already have that there. We

it. So we already have that there. We

now have par on the design side and the code side. It's pretty

code side. It's pretty cool. So, one more thing. Let's like

cool. So, one more thing. Let's like

let's get into something a little bit more complex as well and how we might actually look at building this.

So, I got a uh request to take a look at the image gallery here. And, you know, curious about could this maybe be turned

into a pattern for the library? And I

think that there's some different pieces that we're going to need to think through here. You know, we have some

through here. You know, we have some images right here, but what happens if maybe there's eight images? Do we

continue to wrap this? Um what does that experience look like on mobile? you

know, I think we can start to define the requirements for it, but maybe we just want to get some ideas of what we could possibly do. So, I'm just going to copy

possibly do. So, I'm just going to copy this and I'm glad that uh we have make now and maybe we'll just use this to get some inspiration for alternate ways that

we can approach this.

So, I'm going to just take that design that we already have, and I have a prompt here already to say, maybe give me a few new ways to consider approaching this with an accessible

image carousel that can have up to eight images and shows the selected image at 16x9. Now, we'll let that do its thing.

16x9. Now, we'll let that do its thing.

And if we come back and we take a look at the design, you know, I I think Jake, here is where we start to think, well, how would we maybe design this? How

would we build this?

Like do we show all the images? I, you

know, this is something we talk to product designers and developers about all the time is when you're designing something new, one of the best things you can do is bring your developer in

early to expose opportunities for design, right? opportunities to consider

design, right? opportunities to consider end users um and potential limitations that you might run into down the road.

Because the last thing you want to do is design something and go down a road and then find out when you hand it off that it's gone in the wrong direction or that there's some limitation or some area

that you haven't considered from a design perspective. And so bringing

design perspective. And so bringing developers in early can help you do that. Make can actually help to that

that. Make can actually help to that exact same goal, right? It can help you uncover opportunities for design early.

You know, in the case of this gallery, let's see if it comes up with any. But

there's there might be some buttons for toggling things back and forth. There

might be keyboard interactivity that this will show us uh either through its omission or through its presence. The

things that we're going to want to have be specked out as we're designing this experience. This is a great way to kind

experience. This is a great way to kind of sandbox those ideas to give yourself the most opportunity to design something. Yeah. And I think that this

something. Yeah. And I think that this is where it comes into the touch side as well, right? Like we can just use this

well, right? Like we can just use this to get some quick ideas out there and then ultimately apply the touch of our system to make it feel like it's all one

cohesive piece here. All right, it looks like we are going to get something here.

All right, so Jake, great. We got a carousel here. How many options did it

carousel here. How many options did it give us? It looks like it gave us uh

give us? It looks like it gave us uh three options here. So we have a carousel gallery on here. Uh, we can use keyboard navigation on there. That's

nice. Um, but you know, I think it has the images at the bottom. And what is it going to do? Is it going to continue to shrink the previews? Maybe we want to do

an overflow container there. Do we want to snap the scroll so that it locks to the thumbnail? That's another thing.

the thumbnail? That's another thing.

Yeah, I think also then we need to figure out well, however wide it is, how wide should each preview be? How do we ensure that we have enough peak there?

Um, let's actually see what else we have for just some inspiration here. Full

screen fingers. Full screen gallery.

There we get the arrows on hover. That's

that's kind of cool. And then these buttons don't exist, but should they exist? That's another opportunity for

exist? That's another opportunity for design. All right. So, kind of similar

design. All right. So, kind of similar there. Yeah. Maybe uh I kind of like

there. Yeah. Maybe uh I kind of like when we're in full screen, it has the count of how many there are. Maybe we

could look at putting the count into our component. At the very least, we can

component. At the very least, we can make a decision about it. Absolutely.

Yeah. And then a masonry gallery. Well,

this is kind of what we have today.

Well, this is going to really expand that. I don't think this is quite what

that. I don't think this is quite what we are looking for here. I hope not. So,

but I think we can use some of these learnings to actually build this. So,

let's go into our work in progress here.

And look at that. We've already started to build our component. We're going to do that overflow on there. And we've

assigned some props on here. And I think if we do this on the code side as well, you know, let's just show those nav controls on hover. Um, I think account would be a good idea to include in

there. Sure. So, if we were to go and

there. Sure. So, if we were to go and put this into our design instead, let's uh get rid of that gallery and we will

use our component here instead. We can

actually see we took some inspiration from what we got and we incorporated account into there. We have those. Um ah

Jake, I think we need to make sure that we're still showing the cover on there.

Oh yeah, there was uh there was that interesting dynamic of the uh the portrait photo on top of the blurred background photo. Do we still have that

background photo. Do we still have that functionality? Yeah, I called it show

functionality? Yeah, I called it show cover focus. Oh, nice. So there we We

cover focus. Oh, nice. So there we We can just toggle that prop on if we want to show the cover, apply that blur background on there. And yeah, what we do from here is obviously we've designed

it. We've talked through what we need to

it. We've talked through what we need to consider as we're building this in code.

You know, I think we would build this out and decide is this in the system or is the product team who is doing the product detail page going to continue to

own this. Very

own this. Very cool. All right. So Jake, I think that

cool. All right. So Jake, I think that we've addressed some of these growing needs for our system and I think the key thing is that we're ensuring we're

optimizing for designer experience and developer experience at as many touch points as we can throughout it. So you

know Jake, I think are there other benefits of having aligned systems?

Yeah, one great example that I'd love to plug is the simple design system. Has

everyone heard of the simple design system? Shout out Louie who's out there

system? Shout out Louie who's out there somewhere. Louie and I built this

somewhere. Louie and I built this together both in design and code for last year's config and we've been using it a ton to test out all these things.

Um, but this is a great example I think Chad of like a bunch of integrations matched with a bunch of variables that are aligned between design and code.

Components that are perfectly aligned between design and code that that state that's more aspirational for most folks.

It's kind of like our little Tonka truck sandbox version of a design system.

There's a lot of cool stuff out there.

Uh you can go to github.com/figmads if you want to play

github.com/figmads if you want to play with any of that stuff. Look at the plug-in API code to do some of the stuff we were doing today. Um or REST API integration examples. Um but yeah,

integration examples. Um but yeah, that's uh that's all we have here.

There's also a whole bunch of code connect in there, which is my favorite thing. Um but yeah, let's move on over.

thing. Um but yeah, let's move on over.

Yeah. All right.

All right. So, kind of wrapping things up, you know, when we build out our design systems and we have alignment.

You know, I think if we recap what we've done here today, um let's hit next slide. We want to acknowledge and

slide. We want to acknowledge and remember that design is important because it makes a product meaningful, right? Design is deeply human and it's

right? Design is deeply human and it's not just the way that things look as Jay said at the beginning right it's at the core of the code we write and the

experiences that we curate and friction is inevitable but it's there for good reason design and development are different things. Design

is arguably more important now than ever before. So making it efficient is also

before. So making it efficient is also very important. Anything you do today to

very important. Anything you do today to make it easier for people to use your system will help will be helpful for any tools that you end up using as

well. And we talked a lot about

well. And we talked a lot about alignment and how alignment is not a one-time thing. It's essential for us to

one-time thing. It's essential for us to have alignment with one another before we design or build things, during, even afterwards.

And our alignment, it has to be constant, especially from a systems perspective because our aligned decisions, they are what become our patterns. And leaning into those

patterns. And leaning into those patterns is what's going to help us move faster, hopefully less friction, and give us more confidence. They're what's going to help

confidence. They're what's going to help us make the next thing easier to build than the last.

And design systems are the best way to make that design intent real at scale.

They make meaningful decisions repeatable, not just through tangible assets, but by fostering a culture of shared understanding. And while shared

understanding. And while shared understanding is key for a design system, it really applies to all of product development as a whole because it's oriented around considering the

experiences of people, whether they're designers, developers, or the ones that hear boolean operation, and think, "Oh, wow. I

haven't seen that one yet either." Well, Jake, I have a spoiler.

either." Well, Jake, I have a spoiler.

The ending is that our best work is done together. We even wrote an article about

together. We even wrote an article about this Chad about working better together. The article, it's a tactical

together. The article, it's a tactical guide for designers and developers all the way through handoff.

And it talks about some common pitfalls you may encounter, some practical tips for collaboration, and guidance on when to lean in on one another's expertise.

You can check out that article if you haven't already on our Figma blog shortcut by scanning the QR code here or using this handy link that Jake you uh

you had a great idea on this. Yeah,

design systems deep dive 25. And that's

actually the color if you're interested in what that is as a hex color. All

right, thank you everyone. Thank you.

[Music]