Season 4

|

Episode 6

Building with the latest Figma features

Molly Hellmuth

Creator of UI Prep

Jan 25, 2024

Jan 25, 2024

|

46 min

46 min

music by Dennis

About this Episode

In this episode we’re talking with Molly Hellmuth who is the creator of UI Prep where she has an incredible newsletter, design system, and course where she’s taught hundreds of designers all over the world. This discussion gets into the nerdier side of Figma 🤓 We talk all about:

  • When it does and doesn’t make sense to adopt variables

  • How to make sure you don’t invest in a Figma strategy that you later regret

  • Molly’s favorite Figma plugins for design systems

  • How she’s building components differently in V8 of her UI Prep design system

  • Her journey as an independent creator

    + a lot more

Share on Twitter
Share on Twitter
Share on LinkedIn
Share on LinkedIn

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers 👇

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

Deep Dives

Get our weekly breakdowns

Free lessons from 👇

Lauren LoPrete

Lead designer @ Netflix

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers 👇

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

Transcript chapters

[00:00:00] Catching up with new Figma features

Molly: After config, there was so many new features to just wrap our heads around and start using and yeah, so it's an overwhelming process to update an entire system using all these features. So I actually took things a little bit slower than I normally might and really experimented with all the different features.

I even worked on one or two side projects just to really experiment with variables and the new auto layout wrap features and all these different things just to make sure I understood them fully. I understood the limitations of them and like, are they actually doing what I think they're doing? And how can I iterate on these new things?

I think with every new. feature, it can be easy to just like really quickly jump in and start updating everything and kind of play with like a new toy, but it's so important to, to really take your time and learn how to use these features in a way that's going to like really serve you and your team. So I took like a month or two, which surprised me how long I wanted to take to like fully understand these new features before I started incorporating them into UI prep.

And of course , the biggest one is color variables. That's just like, such a massive thing to introduce to any system if you've only been using styles so far, which of course everyone has been. And yeah, that took the bulk of my time and effort and it's like brain power to kind of wrap my head around how should we use these new features, especially these new variables, and make them as powerful as they can be while also being intuitive and easy to learn for both you and like a new person on your team and also maintain long term. So that kind of sweet spot of complexity that you want to hit. And so I really started there and just like really diving into especially just like naming conventions for things like color variables and like, until then semantic naming seemed kind of optional in Figma and now it seems like almost mandatory with like the way we're using these new features or at least highly suggested.

And so just making sure that those made sense and were easy to to use and to learn and just kind of going through like a Couple of different ways this might work and how should we structure things and then flipping all on its head and just seeing you know Do I like that better? Do I not like that better?

Showing it to a few other designers seeing you know, if they think it seems intuitive to them because of course when it makes sense to You might not make sense Initially to someone else so just gain that initial feedback as well and then of course, you know, we're still learning about variables. Variables are still evolving. We've only had this kind of like first wave of updates with them. And I have to imagine there's at least one or two more coming. , just like we saw with Other huge changes like our component variables where we didn't even have, you know, exposed nested instances or Properties the way we have them now.

And so the way we use things is just Evolving so much. So I'm still very much keeping open mind of should the variables be used on their own? Should they be fed into color styles? There's just still so many things to Really think about with them. So like still keeping an open mind and I think I jumped into number variables next.

Those are just an easy win for any system, I think. Because we didn't have them before. And so adding them into any system is just kind of a net positive because you're not having to replace anything or compete with like an existing system of how you Saved and reused certain elements. And, they're also a lot easier to adopt. Especially with the plugin, I think it's Variables Pro. It does a pretty good job of selecting a component or a design and, like, automatically applying number variables. Where I think it's just a lot harder with color variables because You might have the same blue color that's used for a text and a background and a border.

And identifying which one is which is, has a little more nuance to it. So that, I think, is a little more manual still. So Yeah, it took a little while, longer than I was expecting to update it, because these most updates have been so foundational. They really touch. Everything in a design system. So, yeah, definitely worth taking the time to, like, fully explore the new features before adopting them in a new system, just to make sure you really know kind of what you're getting into and, like, what you're going to get out of the feature.

Something I recommend to a lot of my students is fully learn variables, and then also decide if they're right for your system. I think some systems are small enough where they might be adding more complexity Then this is worth it to, , add to your system. Maybe just sticking with some of the original features is actually the kind of more strategic move for your team.

[00:00:00] Catching up with new Figma features

Molly: After config, there was so many new features to just wrap our heads around and start using and yeah, so it's an overwhelming process to update an entire system using all these features. So I actually took things a little bit slower than I normally might and really experimented with all the different features.

I even worked on one or two side projects just to really experiment with variables and the new auto layout wrap features and all these different things just to make sure I understood them fully. I understood the limitations of them and like, are they actually doing what I think they're doing? And how can I iterate on these new things?

I think with every new. feature, it can be easy to just like really quickly jump in and start updating everything and kind of play with like a new toy, but it's so important to, to really take your time and learn how to use these features in a way that's going to like really serve you and your team. So I took like a month or two, which surprised me how long I wanted to take to like fully understand these new features before I started incorporating them into UI prep.

And of course , the biggest one is color variables. That's just like, such a massive thing to introduce to any system if you've only been using styles so far, which of course everyone has been. And yeah, that took the bulk of my time and effort and it's like brain power to kind of wrap my head around how should we use these new features, especially these new variables, and make them as powerful as they can be while also being intuitive and easy to learn for both you and like a new person on your team and also maintain long term. So that kind of sweet spot of complexity that you want to hit. And so I really started there and just like really diving into especially just like naming conventions for things like color variables and like, until then semantic naming seemed kind of optional in Figma and now it seems like almost mandatory with like the way we're using these new features or at least highly suggested.

And so just making sure that those made sense and were easy to to use and to learn and just kind of going through like a Couple of different ways this might work and how should we structure things and then flipping all on its head and just seeing you know Do I like that better? Do I not like that better?

Showing it to a few other designers seeing you know, if they think it seems intuitive to them because of course when it makes sense to You might not make sense Initially to someone else so just gain that initial feedback as well and then of course, you know, we're still learning about variables. Variables are still evolving. We've only had this kind of like first wave of updates with them. And I have to imagine there's at least one or two more coming. , just like we saw with Other huge changes like our component variables where we didn't even have, you know, exposed nested instances or Properties the way we have them now.

And so the way we use things is just Evolving so much. So I'm still very much keeping open mind of should the variables be used on their own? Should they be fed into color styles? There's just still so many things to Really think about with them. So like still keeping an open mind and I think I jumped into number variables next.

Those are just an easy win for any system, I think. Because we didn't have them before. And so adding them into any system is just kind of a net positive because you're not having to replace anything or compete with like an existing system of how you Saved and reused certain elements. And, they're also a lot easier to adopt. Especially with the plugin, I think it's Variables Pro. It does a pretty good job of selecting a component or a design and, like, automatically applying number variables. Where I think it's just a lot harder with color variables because You might have the same blue color that's used for a text and a background and a border.

And identifying which one is which is, has a little more nuance to it. So that, I think, is a little more manual still. So Yeah, it took a little while, longer than I was expecting to update it, because these most updates have been so foundational. They really touch. Everything in a design system. So, yeah, definitely worth taking the time to, like, fully explore the new features before adopting them in a new system, just to make sure you really know kind of what you're getting into and, like, what you're going to get out of the feature.

Something I recommend to a lot of my students is fully learn variables, and then also decide if they're right for your system. I think some systems are small enough where they might be adding more complexity Then this is worth it to, , add to your system. Maybe just sticking with some of the original features is actually the kind of more strategic move for your team.

[00:04:36] How to approach adopting variables

Ridd: Let's drill into that because I think that's a very interesting topic where I kind of did the same thing. Like variables came out. I started immediately trying to think about, okay, how do I teach these? And I realized, geez, I don't actually know yet. Like I ended up building literally like a full system and dummy product just as a way to learn.

So I think it's interesting to hear you talk about like side projects and experiments. One of the things that became really clear early in the process is that it is super easy to over architect a system where, yeah, maybe everything's really connected and it's super cool, but it's kind of a pain to use and ends up getting in the way a little bit.

And so maybe you could talk about how you think teams should go about finding where that line is, like how. Much does it make sense to adopt variables and maybe what are some of the signals where you might realize, okay, maybe actually we have gone too far, or this doesn't make sense given our setup. Can you help teams think about that challenge a little bit?

Molly: Yeah. I think it all really comes down to like scope and complexity of your system. if you know, you need theming for like light and dark theme, or, you know, you want to support multiple brands and you want all those brands to share some files, then I think. Go ahead and start using variables. That's going to have like clear value right away.

But most teams don't need either of those. I would say. Most teams think of it as like a nice idea for maybe in the future. But they just don't need multiple themes or multiple brands. They're just one product. And things are pretty straight forward. I think it makes sense to at least practice, make like a really small dummy project, and go through the process. Especially since right now Figma's suggestion is to create variables for colors and then feed them into color styles. Which can feel like a really kind of tedious and difficult process.

, and people can be scratching their head like, How is this making this easier again? Like, can we go over the pros of , you know, why are we going through all these steps just so we can like make this one thing blue? , and so I think going through the process and fully understanding what's involved in it and also deciding, okay, is this going to make things easier or harder for us?

For some teams, it even comes down to like, do we even need really specific semantic naming? Or can we combine some of these categories? Can we just have, you know, backgrounds and borders share the same color that we use? Or is it helpful to keep them separated? So I think kind of going through like a practice project and just thinking about like, okay, where do we want to be in five years?

And like, is this going to help us get there or just be kind of like an interesting distraction right now? That being said, once you do find a good system and it doesn't work for you, once it's set up, it's like a lot of front loaded work, where once it's set up and you like the system, then you're just kind of using it as you would with like a simple, straightforward style system.

if you're a little on the fence, you can always give it a try, and then, , it's kind of easy to walk back, especially if you are feeding the variables into styles, because you're only ever using those styles. So you can always just remove the variables and keep the styles as is, so it can be relatively lower risk if you kind of add an extra layer of functionality.

[00:04:36] How to approach adopting variables

Ridd: Let's drill into that because I think that's a very interesting topic where I kind of did the same thing. Like variables came out. I started immediately trying to think about, okay, how do I teach these? And I realized, geez, I don't actually know yet. Like I ended up building literally like a full system and dummy product just as a way to learn.

So I think it's interesting to hear you talk about like side projects and experiments. One of the things that became really clear early in the process is that it is super easy to over architect a system where, yeah, maybe everything's really connected and it's super cool, but it's kind of a pain to use and ends up getting in the way a little bit.

And so maybe you could talk about how you think teams should go about finding where that line is, like how. Much does it make sense to adopt variables and maybe what are some of the signals where you might realize, okay, maybe actually we have gone too far, or this doesn't make sense given our setup. Can you help teams think about that challenge a little bit?

Molly: Yeah. I think it all really comes down to like scope and complexity of your system. if you know, you need theming for like light and dark theme, or, you know, you want to support multiple brands and you want all those brands to share some files, then I think. Go ahead and start using variables. That's going to have like clear value right away.

But most teams don't need either of those. I would say. Most teams think of it as like a nice idea for maybe in the future. But they just don't need multiple themes or multiple brands. They're just one product. And things are pretty straight forward. I think it makes sense to at least practice, make like a really small dummy project, and go through the process. Especially since right now Figma's suggestion is to create variables for colors and then feed them into color styles. Which can feel like a really kind of tedious and difficult process.

, and people can be scratching their head like, How is this making this easier again? Like, can we go over the pros of , you know, why are we going through all these steps just so we can like make this one thing blue? , and so I think going through the process and fully understanding what's involved in it and also deciding, okay, is this going to make things easier or harder for us?

For some teams, it even comes down to like, do we even need really specific semantic naming? Or can we combine some of these categories? Can we just have, you know, backgrounds and borders share the same color that we use? Or is it helpful to keep them separated? So I think kind of going through like a practice project and just thinking about like, okay, where do we want to be in five years?

And like, is this going to help us get there or just be kind of like an interesting distraction right now? That being said, once you do find a good system and it doesn't work for you, once it's set up, it's like a lot of front loaded work, where once it's set up and you like the system, then you're just kind of using it as you would with like a simple, straightforward style system.

if you're a little on the fence, you can always give it a try, and then, , it's kind of easy to walk back, especially if you are feeding the variables into styles, because you're only ever using those styles. So you can always just remove the variables and keep the styles as is, so it can be relatively lower risk if you kind of add an extra layer of functionality.

[00:07:47] Avoiding feature adoption regrets

Ridd: you said something kind of interesting, which is. Basically just a reminder to keep in mind that this is still wave one of a really large feature set and inevitably not only are things going to change and we're going to have additions to this feature, you know, we've talked about like typography variables and image variables and things like that, but also the strategies inevitably will change as we put the feature set to the test a little bit.

And it reminds me of Component properties where all of a sudden we had boolean properties available to us and we just said, you know what, we're going to boolean property everything and remove all of our variants and we're going to create these super components that can do. Everything. And the more we went down that path, we kind of realized like, Oh shoot.

Like that doesn't actually make sense. Like there's no discoverability. You can't actually see how this is being used. It's more clicks for everyone consuming the components. Do you have a sense that we're going to be feeling a similar way about variables in the future where we're like, okay, we just went all in and applied them everywhere or we use them this way.

And then maybe it didn't make that much sense. Like, how do you even think about keeping that open mind and making sure that you're not going too far and down a direction that doesn't really work?

Molly: I think about this often, this is what keeps me up at night, is what's going to be the thing we regret in six months from now? And there's definitely going to be something, for sure. Um, I often remind my students, like, hey, remember base components? And when we thought making a button with, you know, a hundred variants was like a really cool idea.

And then like a few months later, it wasn't. I think that's going to be a similar case here. Hopefully not as extreme because the space components were a little painful to undo. , but at the time they were the best practice given that first wave of the feature sets for our new components and how we were building them.

So at the time it did make sense, but we were using an incomplete feature and I think that we're I guess variables are incomplete in terms of they don't even have, , text variables or images or gradients or all the categories, but even just the best practices for how to use the variables that we do have really haven't been established.

If you look online for a good guides on them, there's not much to be honest because people just don't know yet. We're still figuring it out, even the top. Creators or teams or like Figma themselves, there just aren't that many resources right now. Other than like just the basics of like announcing the features.

To really go into like, okay, here's the best way to do this, here's the best strategy. Because we're all still kind of feeling it out, we're all still kind of waiting for those, you know, that second, main, third wave to drop on how we're going to use these a little bit differently, how we're going to like add to them.

When variables first came out, the expectation was like, oh, we're just going to use color variables and apply the variable to an object. And now there's this like, possible idea that maybe it's best to feed them into a style and then apply the style to the object.

So even that is like a massive shift in how we're using this feature, just within the first few months of the feature being released. So I think it's important to start exploring and experimenting early, but maybe Adopt a bit slowly, and just be really cautious. Start experimenting, see what's possible, have some practice projects.

Think about what might be possible, and like how the current features might serve your team, , long term. But maybe don't apply them just yet, maybe apply them in small stages, in small steps, or just in like ways that feel safe. Like I think adding number variables is fairly safe, I don't see that one changing too much.

And you'll see us ever having like number styles to compete with our variables. So that one feels like a pretty safe place to start.

[00:07:47] Avoiding feature adoption regrets

Ridd: you said something kind of interesting, which is. Basically just a reminder to keep in mind that this is still wave one of a really large feature set and inevitably not only are things going to change and we're going to have additions to this feature, you know, we've talked about like typography variables and image variables and things like that, but also the strategies inevitably will change as we put the feature set to the test a little bit.

And it reminds me of Component properties where all of a sudden we had boolean properties available to us and we just said, you know what, we're going to boolean property everything and remove all of our variants and we're going to create these super components that can do. Everything. And the more we went down that path, we kind of realized like, Oh shoot.

Like that doesn't actually make sense. Like there's no discoverability. You can't actually see how this is being used. It's more clicks for everyone consuming the components. Do you have a sense that we're going to be feeling a similar way about variables in the future where we're like, okay, we just went all in and applied them everywhere or we use them this way.

And then maybe it didn't make that much sense. Like, how do you even think about keeping that open mind and making sure that you're not going too far and down a direction that doesn't really work?

Molly: I think about this often, this is what keeps me up at night, is what's going to be the thing we regret in six months from now? And there's definitely going to be something, for sure. Um, I often remind my students, like, hey, remember base components? And when we thought making a button with, you know, a hundred variants was like a really cool idea.

And then like a few months later, it wasn't. I think that's going to be a similar case here. Hopefully not as extreme because the space components were a little painful to undo. , but at the time they were the best practice given that first wave of the feature sets for our new components and how we were building them.

So at the time it did make sense, but we were using an incomplete feature and I think that we're I guess variables are incomplete in terms of they don't even have, , text variables or images or gradients or all the categories, but even just the best practices for how to use the variables that we do have really haven't been established.

If you look online for a good guides on them, there's not much to be honest because people just don't know yet. We're still figuring it out, even the top. Creators or teams or like Figma themselves, there just aren't that many resources right now. Other than like just the basics of like announcing the features.

To really go into like, okay, here's the best way to do this, here's the best strategy. Because we're all still kind of feeling it out, we're all still kind of waiting for those, you know, that second, main, third wave to drop on how we're going to use these a little bit differently, how we're going to like add to them.

When variables first came out, the expectation was like, oh, we're just going to use color variables and apply the variable to an object. And now there's this like, possible idea that maybe it's best to feed them into a style and then apply the style to the object.

So even that is like a massive shift in how we're using this feature, just within the first few months of the feature being released. So I think it's important to start exploring and experimenting early, but maybe Adopt a bit slowly, and just be really cautious. Start experimenting, see what's possible, have some practice projects.

Think about what might be possible, and like how the current features might serve your team, , long term. But maybe don't apply them just yet, maybe apply them in small stages, in small steps, or just in like ways that feel safe. Like I think adding number variables is fairly safe, I don't see that one changing too much.

And you'll see us ever having like number styles to compete with our variables. So that one feels like a pretty safe place to start.

[00:11:28] How Molly uses number variables in her design systems

Ridd: Can you talk to me a little bit about how you use number variables in your system? Cause you can kind of like define them almost as a primitive, like you'd see in like a tailwind or just, you know, your four, your eight point scale, or you can kind of make them more like use case. And how do you think about aliasing?

Like, I think it's an obvious starting point because it is kind of simple, but also if you push on it, it gets kind of complex and there's a lot of different strategies. So I'd love to hear how you think about it.

Molly: That is true. I think, yeah, on one level it is simple, but you can make it complex, just like with anything else you can end up with, you know. 100 plus number variables, that's probably not where you want to be for most teams. Um, again, you can start with a primitive collection, feed it into a semantic collection, then apply that semantic collection of variables to your designs.

I think unless you're a really huge team and you're really going all in on number variables, maybe both collections make sense for you, but I think for the majority of the teams, skipping straight to the semantic collection and just adding in like raw numbers to , those values. I think it's fine. I think we're pretty much all using an 8 point grid and we can all just kind of figure out what the numbers should be.

We don't need a list of like multiples of 8 to choose from. , and if we do we can just update them like manually. If for some reason 6 becomes like the magic number we could always go in and make those updates manually. I don't think it would be that difficult. , so I think you can simplify it first by only using one collection.

And then I think you can also simplify it by not getting too component specific aside from any like very small instances where you need a component specific number. I think you can do more general big topics like spacing and sizing or maybe just like sizing for height and sizing for width and then space between for your auto layout components.

, so even these kind of general like that and then being really Be mindful when you do get component specific, because you obviously don't want a whole set of numbers for like every component in your system. It's going to be a lot. , but some things like, maybe you have a few sizes just for your icons.

That's technically kind of component specific, but I think it's really valuable to say, hey, icons can be one of three sizes. They're going to be 24, 16, or 32. Something like that. That's really straightforward. I think that's really an easy one to use, and like corner radius is pretty specific. But I think just naturally specific.

So I think keeping things as simple as possible. I always remind myself of, you know, KISS. Keep it simple, stupid. Just always find a way to iterate and make something even simpler than however you first made it. Just to make it that much easier to like adopt and maintain. Because the second you start getting really specific in one area, you're going to be really tempted to get specific in all these other different areas.

And that's when things get a little off the rails.

Ridd: I couldn't agree more. And it's kind of validating actually to even hear you come to those kinds of conclusions because in the same way, like I started off and I was like, well, I'm just going to define my primitive size values. And then you get in there and you're like, man, but I have to publish this.

And it's getting in the way every time I open up like a dropdown menu So I also really like this idea of just building the smallest possible system. And it's really awesome to hear how you think about it. I have a few other Figma related, just quick getting questions because I can't pass on this opportunity to pick your brain.

[00:11:28] How Molly uses number variables in her design systems

Ridd: Can you talk to me a little bit about how you use number variables in your system? Cause you can kind of like define them almost as a primitive, like you'd see in like a tailwind or just, you know, your four, your eight point scale, or you can kind of make them more like use case. And how do you think about aliasing?

Like, I think it's an obvious starting point because it is kind of simple, but also if you push on it, it gets kind of complex and there's a lot of different strategies. So I'd love to hear how you think about it.

Molly: That is true. I think, yeah, on one level it is simple, but you can make it complex, just like with anything else you can end up with, you know. 100 plus number variables, that's probably not where you want to be for most teams. Um, again, you can start with a primitive collection, feed it into a semantic collection, then apply that semantic collection of variables to your designs.

I think unless you're a really huge team and you're really going all in on number variables, maybe both collections make sense for you, but I think for the majority of the teams, skipping straight to the semantic collection and just adding in like raw numbers to , those values. I think it's fine. I think we're pretty much all using an 8 point grid and we can all just kind of figure out what the numbers should be.

We don't need a list of like multiples of 8 to choose from. , and if we do we can just update them like manually. If for some reason 6 becomes like the magic number we could always go in and make those updates manually. I don't think it would be that difficult. , so I think you can simplify it first by only using one collection.

And then I think you can also simplify it by not getting too component specific aside from any like very small instances where you need a component specific number. I think you can do more general big topics like spacing and sizing or maybe just like sizing for height and sizing for width and then space between for your auto layout components.

, so even these kind of general like that and then being really Be mindful when you do get component specific, because you obviously don't want a whole set of numbers for like every component in your system. It's going to be a lot. , but some things like, maybe you have a few sizes just for your icons.

That's technically kind of component specific, but I think it's really valuable to say, hey, icons can be one of three sizes. They're going to be 24, 16, or 32. Something like that. That's really straightforward. I think that's really an easy one to use, and like corner radius is pretty specific. But I think just naturally specific.

So I think keeping things as simple as possible. I always remind myself of, you know, KISS. Keep it simple, stupid. Just always find a way to iterate and make something even simpler than however you first made it. Just to make it that much easier to like adopt and maintain. Because the second you start getting really specific in one area, you're going to be really tempted to get specific in all these other different areas.

And that's when things get a little off the rails.

Ridd: I couldn't agree more. And it's kind of validating actually to even hear you come to those kinds of conclusions because in the same way, like I started off and I was like, well, I'm just going to define my primitive size values. And then you get in there and you're like, man, but I have to publish this.

And it's getting in the way every time I open up like a dropdown menu So I also really like this idea of just building the smallest possible system. And it's really awesome to hear how you think about it. I have a few other Figma related, just quick getting questions because I can't pass on this opportunity to pick your brain.

[00:14:51] Molly's favorite updates to the UI Prep system

Ridd: So maybe we can just move into a little Figma lightning round here. And the first one is when you look at. The UI prep system and all the updates you made for 8. 0. What is your favorite update that you've made?

Molly: That's a tough one. I mean, I think the color variables, just because they were so huge, and , I could have light and dark themes in one file, which is something I hadn't done before. I'd always had two separate files people could use. I'd always been tempted to use Token Studio, but I felt It's just quite a huge learning curve, , even though it's like so powerful and such a great tool, it's just not for everybody.

And I think now having the ability to just like keep these multiple themes in one file and just be able to do one little switch at the top of the page and have everything switch over just feels like magic. I think the first moment I got that working exactly how I wanted to and I had all the colors set just right, it was like so rewarding to just see everything kind of switch over.

So that was like the best like kind of magic moment I think of these updates. And then. Also, auto layout wrap is just so cool. First, applying that to just like a few different components. Even with just like a simple little list of chips, it's just so satisfying to see. Cause you know, we've all like, just like beat our head against the table every once in a while.

Like, uh, if I could just make this like, move down once there isn't enough room. Like, it would be so much better. Like, I guess I'll create like a second component. Like, This one's for a long list, this one's for a short list, or, you know, whatever it is. , that was just like such a small, like, little win for me, I think, with certain components, where I could finally have them have, like, the exact behavior that I wanted.

[00:14:51] Molly's favorite updates to the UI Prep system

Ridd: So maybe we can just move into a little Figma lightning round here. And the first one is when you look at. The UI prep system and all the updates you made for 8. 0. What is your favorite update that you've made?

Molly: That's a tough one. I mean, I think the color variables, just because they were so huge, and , I could have light and dark themes in one file, which is something I hadn't done before. I'd always had two separate files people could use. I'd always been tempted to use Token Studio, but I felt It's just quite a huge learning curve, , even though it's like so powerful and such a great tool, it's just not for everybody.

And I think now having the ability to just like keep these multiple themes in one file and just be able to do one little switch at the top of the page and have everything switch over just feels like magic. I think the first moment I got that working exactly how I wanted to and I had all the colors set just right, it was like so rewarding to just see everything kind of switch over.

So that was like the best like kind of magic moment I think of these updates. And then. Also, auto layout wrap is just so cool. First, applying that to just like a few different components. Even with just like a simple little list of chips, it's just so satisfying to see. Cause you know, we've all like, just like beat our head against the table every once in a while.

Like, uh, if I could just make this like, move down once there isn't enough room. Like, it would be so much better. Like, I guess I'll create like a second component. Like, This one's for a long list, this one's for a short list, or, you know, whatever it is. , that was just like such a small, like, little win for me, I think, with certain components, where I could finally have them have, like, the exact behavior that I wanted.

[00:16:25] Strategies for grays in a color system

Ridd: You mentioned the themability and my next question is, okay, let's say that you're starting out, you're building this themable system. You're going to have a light mode and a dark mode. Are you pulling from a single set of gray primitive colors to power both of those modes, or do you have a set of grays specifically for light and then a set of grays specifically for dark?

Molly: When I was updating the UI Prep system for these new variables, I really studied the Adobe Color Spectrum system and all the documentation on color, which I thought was, like, Really straightforward, and like, really made a lot of sense. And I love how they handle their light and dark themes, and I essentially copied it exactly where they have themable, , color palettes.

So they have an entire palette for, let's say your light theme, and a completely separate color palette for your dark theme. And what's great is that, at first glance, it looks like you just inverted everything. You just made 1 through 10 go 10 through 1. But when you look at it a little closer, you can see that each color is actually optimized just a little bit to have even higher and, like, better contrast with either a light or a dark background.

So it's just going to be, like, even more accessible and even more just attractive, because it's going to just pop more.

So these little optimizations, I think, really go a long way.

[00:16:25] Strategies for grays in a color system

Ridd: You mentioned the themability and my next question is, okay, let's say that you're starting out, you're building this themable system. You're going to have a light mode and a dark mode. Are you pulling from a single set of gray primitive colors to power both of those modes, or do you have a set of grays specifically for light and then a set of grays specifically for dark?

Molly: When I was updating the UI Prep system for these new variables, I really studied the Adobe Color Spectrum system and all the documentation on color, which I thought was, like, Really straightforward, and like, really made a lot of sense. And I love how they handle their light and dark themes, and I essentially copied it exactly where they have themable, , color palettes.

So they have an entire palette for, let's say your light theme, and a completely separate color palette for your dark theme. And what's great is that, at first glance, it looks like you just inverted everything. You just made 1 through 10 go 10 through 1. But when you look at it a little closer, you can see that each color is actually optimized just a little bit to have even higher and, like, better contrast with either a light or a dark background.

So it's just going to be, like, even more accessible and even more just attractive, because it's going to just pop more.

So these little optimizations, I think, really go a long way.

[00:17:39] Where Molly gets inspiration

Ridd: I love that. You mentioned Adobe as like a source of inspiration, and that kind of begs the next question for me, which is like so many designers, like tens of thousands of designers literally are plugged into your Friday 5 newsletter as like a source of inspiration and learning. And like, if you're not subscribed, you should go to UIPrep's website and check that out because it's awesome.

I read every edition. My question then is like, what sources are you plugged into to keep learning and growing

Molly: yeah, that's a good question. Every week I'm thinking of five new tips for the newsletter, which , which I'm surprised like it's been years and it still doesn't get old. I don't run out of resources because there's just so many great things to look to like creators or other frameworks or design systems.

I always, you know, my Kind of go to people are like, , Brad Frost, Dan Maul, Nathan Curtis. All these really huge people in the design system space having like such really rich, valuable resources whenever they do come out.

I wish they would post more, but whenever they post something, I know it's gonna be gold. So I'm always, , definitely looking there and just like studying how other design systems are doing things. Even if they don't really have like a public, , Like an article or a resource about how they do things, just like going through and like actually studying like a tool and like seeing like, Oh, how is this company, like their live product?

How are they tackling this and kind of digging into it? , I think that can be such a huge source of learning. It's just kind of like digging into how someone else did something.

Ridd: It's cool that you mentioned products and not just open source systems. Cause that is something that always kind of bugged me a little bit. It's like, if you're a small medium sized business and you want to learn about doing a design system, the only. True publicly available resources are from like the biggest players, which have a totally different set of challenges and constraints.

And maybe some of those don't make sense for your 12 person design team or something like that. But one of the most helpful. Things that I did when even thinking about how different colors could map is I did study a few different products. I actually went into linear. I know it's like so cliche, but I just looked at their theming and I took screenshots and I just, I dropped to see how they were changing their grays across themes and I almost learned as much from that as going to design systems.

com or something like that. You know,

Molly: yeah, I know when I was updating UI prep for new variables, I also try to figure out the best way to name all the colors I don't, it definitely was like Taking screenshots of like demo videos from I think it was like Asana and Atlassian and Ford from their talk at config and just like even in a talk when they kind of really discuss something like going in like pausing and like taking a screenshot like okay how'd they named this like why would they do that when like this company did that like I'm thinking through like Maybe their reasoning and like what they consider pros and cons and just kind of like figuring out the, you know, the average of them.

I often think about creating a design system like cooking. When you're cooking something, maybe I'll look at like five different recipes and see how all of them tackle things and like, you know, why they did it. Cook at low temperature for this time or high temperature for that time or add these different ingredients.

And I almost never go with an exact recipe, but I will in my mind kind of calculate all of them. Take an average factor and like what I need and like what I have in the fridge and then build something there So even though it's not Directly copying or like leaning too much on like one particular source.

I think just like being exposed to as many systems as possible Helps you make better decisions in your own system, a question I get a lot in my course is about using kind of unconventional colors some students like My team is using yellow and like, I can't, I can't give it some otherwise, like, yellow is our brand color and like, I gotta make it work, like, please help me because it's impossible.

Um, we all have a moment of silence for this one designer and then we start, and then we start brainstorming and I, it always comes down to like, hey, team, like, Amazon, their button is yellow, like, if they can do it, you can do it, like, if you can find, Unconventional solutions. I'm sure a number of, like, big teams and small teams and medium teams who are doing something similar.

And you can do the same thing. You can kind of see how all of them are tackling it, take an average of that, factor in, like, what you need, and then make a decision based on all of that rich information.

[00:17:39] Where Molly gets inspiration

Ridd: I love that. You mentioned Adobe as like a source of inspiration, and that kind of begs the next question for me, which is like so many designers, like tens of thousands of designers literally are plugged into your Friday 5 newsletter as like a source of inspiration and learning. And like, if you're not subscribed, you should go to UIPrep's website and check that out because it's awesome.

I read every edition. My question then is like, what sources are you plugged into to keep learning and growing

Molly: yeah, that's a good question. Every week I'm thinking of five new tips for the newsletter, which , which I'm surprised like it's been years and it still doesn't get old. I don't run out of resources because there's just so many great things to look to like creators or other frameworks or design systems.

I always, you know, my Kind of go to people are like, , Brad Frost, Dan Maul, Nathan Curtis. All these really huge people in the design system space having like such really rich, valuable resources whenever they do come out.

I wish they would post more, but whenever they post something, I know it's gonna be gold. So I'm always, , definitely looking there and just like studying how other design systems are doing things. Even if they don't really have like a public, , Like an article or a resource about how they do things, just like going through and like actually studying like a tool and like seeing like, Oh, how is this company, like their live product?

How are they tackling this and kind of digging into it? , I think that can be such a huge source of learning. It's just kind of like digging into how someone else did something.

Ridd: It's cool that you mentioned products and not just open source systems. Cause that is something that always kind of bugged me a little bit. It's like, if you're a small medium sized business and you want to learn about doing a design system, the only. True publicly available resources are from like the biggest players, which have a totally different set of challenges and constraints.

And maybe some of those don't make sense for your 12 person design team or something like that. But one of the most helpful. Things that I did when even thinking about how different colors could map is I did study a few different products. I actually went into linear. I know it's like so cliche, but I just looked at their theming and I took screenshots and I just, I dropped to see how they were changing their grays across themes and I almost learned as much from that as going to design systems.

com or something like that. You know,

Molly: yeah, I know when I was updating UI prep for new variables, I also try to figure out the best way to name all the colors I don't, it definitely was like Taking screenshots of like demo videos from I think it was like Asana and Atlassian and Ford from their talk at config and just like even in a talk when they kind of really discuss something like going in like pausing and like taking a screenshot like okay how'd they named this like why would they do that when like this company did that like I'm thinking through like Maybe their reasoning and like what they consider pros and cons and just kind of like figuring out the, you know, the average of them.

I often think about creating a design system like cooking. When you're cooking something, maybe I'll look at like five different recipes and see how all of them tackle things and like, you know, why they did it. Cook at low temperature for this time or high temperature for that time or add these different ingredients.

And I almost never go with an exact recipe, but I will in my mind kind of calculate all of them. Take an average factor and like what I need and like what I have in the fridge and then build something there So even though it's not Directly copying or like leaning too much on like one particular source.

I think just like being exposed to as many systems as possible Helps you make better decisions in your own system, a question I get a lot in my course is about using kind of unconventional colors some students like My team is using yellow and like, I can't, I can't give it some otherwise, like, yellow is our brand color and like, I gotta make it work, like, please help me because it's impossible.

Um, we all have a moment of silence for this one designer and then we start, and then we start brainstorming and I, it always comes down to like, hey, team, like, Amazon, their button is yellow, like, if they can do it, you can do it, like, if you can find, Unconventional solutions. I'm sure a number of, like, big teams and small teams and medium teams who are doing something similar.

And you can do the same thing. You can kind of see how all of them are tackling it, take an average of that, factor in, like, what you need, and then make a decision based on all of that rich information.

[00:21:59] Molly's favorite plugins for design systems

Ridd: I love that moving along in my list of Figma curiosities here. If someone's working on a design system, I'm curious what other plugins you'd recommend they check out. You mentioned variables pro are there other ones that you find yourself using or recommending most often?

Molly: A lot of times I recommend when people are adding in color, especially if they're creating like a brand new system, to use a Super Palette. , that's a really great one. Copying directly like another palette from another system.

I typically point people to Adobe, but there's a ton of really great other design systems and like, their colors. You can also generate your own color using, , like a hex code from like your existing Uh, design system, if you have one. I know it is paid, but there's a free trial. , so take advantage of it.

And, yeah, that was a great one. I used contrast, it's really great for just double checking all of your contrast between layers, especially text on backgrounds. And, , 8 shapes is also really, really great. It makes documenting so, so, so much easier, and it really does a better job, I think most of us would do on our own, of just highlighting some of the important things like spacing and sizing and, you know, what's available.

I think it's right now the best one for documentation, and I have all my students using it.

[00:21:59] Molly's favorite plugins for design systems

Ridd: I love that moving along in my list of Figma curiosities here. If someone's working on a design system, I'm curious what other plugins you'd recommend they check out. You mentioned variables pro are there other ones that you find yourself using or recommending most often?

Molly: A lot of times I recommend when people are adding in color, especially if they're creating like a brand new system, to use a Super Palette. , that's a really great one. Copying directly like another palette from another system.

I typically point people to Adobe, but there's a ton of really great other design systems and like, their colors. You can also generate your own color using, , like a hex code from like your existing Uh, design system, if you have one. I know it is paid, but there's a free trial. , so take advantage of it.

And, yeah, that was a great one. I used contrast, it's really great for just double checking all of your contrast between layers, especially text on backgrounds. And, , 8 shapes is also really, really great. It makes documenting so, so, so much easier, and it really does a better job, I think most of us would do on our own, of just highlighting some of the important things like spacing and sizing and, you know, what's available.

I think it's right now the best one for documentation, and I have all my students using it.

[00:23:10] Strategies for creating tables in Figma

Ridd: Yeah. Same. It's really, really impressive. If you are going to create a table. Are you going to group your components by column, or are you going to group them by row?

Molly: An age old question. Um, it's funny, if you look in the history of UIPrep, I think every edition, I like flip flop, because I always go back and forth of what's better. So my short answer is, neither is right or wrong. After many iterations, I think columns, Suit the most amount of use cases and are typically going to be easier to work with because they're just a little more flexible Especially like resizing columns like adding a new column , I think it's just going to be typically easier However, if your team and you're like prototyping realistic prototype is like number one in our hearts and minds Maybe rows are better because you can really have those interactive components and have the rows highlight and be show a selected state really easily Or if you're like we have huge Data intensive tables that like need to expand and like almost like an accordion and show additional information You can't you just need a row So I think for those like specific use cases sometimes rows make more sense, but for I think the majority of people Columns are gonna be easier.

Also, there's no harm in having both if you have multiple types of tables like you can use both You don't need to you know, pick one and be like on team column or team row You can kind of pick and choose as they suit you

[00:23:10] Strategies for creating tables in Figma

Ridd: Yeah. Same. It's really, really impressive. If you are going to create a table. Are you going to group your components by column, or are you going to group them by row?

Molly: An age old question. Um, it's funny, if you look in the history of UIPrep, I think every edition, I like flip flop, because I always go back and forth of what's better. So my short answer is, neither is right or wrong. After many iterations, I think columns, Suit the most amount of use cases and are typically going to be easier to work with because they're just a little more flexible Especially like resizing columns like adding a new column , I think it's just going to be typically easier However, if your team and you're like prototyping realistic prototype is like number one in our hearts and minds Maybe rows are better because you can really have those interactive components and have the rows highlight and be show a selected state really easily Or if you're like we have huge Data intensive tables that like need to expand and like almost like an accordion and show additional information You can't you just need a row So I think for those like specific use cases sometimes rows make more sense, but for I think the majority of people Columns are gonna be easier.

Also, there's no harm in having both if you have multiple types of tables like you can use both You don't need to you know, pick one and be like on team column or team row You can kind of pick and choose as they suit you

[00:24:33] How the UI Prep system has evolved

Ridd: You've obviously been building design systems in Figma for years now. You mentioned flip flopping between tables and rows as your thinkings evolved. Are there other ways that the UI prep system has Clearly like evolved in terms of how you are thinking or your strategies for building, or maybe you're using different tactics that you weren't in the beginning.

Molly: I think the through line is always trying to make it as easy to learn and use as possible. I think a little blip in that was maybe trying to use, , the base components and properties because we were just caught in this like weird in between zone of a, you know, of a feature that was still taking form.

And so at times , trying to see, okay, let's make these components as powerful as possible, and then kind of coming back to the other side of the spectrum and making them as usable as possible. So now I really have components really split up into much smaller component sets to make them even more discoverable and like so much easier to use.

and it's funny seeing the difference between the UIPrep system and a system that I'll build out for a client. Because the needs are so different. In UIPrep, I'm trying to create a component that's as Powerful and usable for the most amount of people to make things really flexible and like intuitive For you know a new designer or an experienced designer where for a client the components means like hyper focused on like that One client's needs and like okay this button needs to do just the one thing This input needs to do this one thing versus trying to make it really flexible so even entire systems can be different for , just whatever they're working on and a lot a really large huge enterprise team might need Very flexible components because they're going to be used in like such a wide range of, you know, like multiple products.

So they need to really account for a lot of different use cases, whereas a much smaller team is going to be a lot more specific and, you like pinpoint an exact use case with each component, which makes it a lot easier to use. But of course it's a little bit restricting. So it's fun to see the differences just.

Even as like one designer, me, right now, I'll build a design system for three different clients in three, maybe completely different ways, just based on their needs and their scope.

[00:24:33] How the UI Prep system has evolved

Ridd: You've obviously been building design systems in Figma for years now. You mentioned flip flopping between tables and rows as your thinkings evolved. Are there other ways that the UI prep system has Clearly like evolved in terms of how you are thinking or your strategies for building, or maybe you're using different tactics that you weren't in the beginning.

Molly: I think the through line is always trying to make it as easy to learn and use as possible. I think a little blip in that was maybe trying to use, , the base components and properties because we were just caught in this like weird in between zone of a, you know, of a feature that was still taking form.

And so at times , trying to see, okay, let's make these components as powerful as possible, and then kind of coming back to the other side of the spectrum and making them as usable as possible. So now I really have components really split up into much smaller component sets to make them even more discoverable and like so much easier to use.

and it's funny seeing the difference between the UIPrep system and a system that I'll build out for a client. Because the needs are so different. In UIPrep, I'm trying to create a component that's as Powerful and usable for the most amount of people to make things really flexible and like intuitive For you know a new designer or an experienced designer where for a client the components means like hyper focused on like that One client's needs and like okay this button needs to do just the one thing This input needs to do this one thing versus trying to make it really flexible so even entire systems can be different for , just whatever they're working on and a lot a really large huge enterprise team might need Very flexible components because they're going to be used in like such a wide range of, you know, like multiple products.

So they need to really account for a lot of different use cases, whereas a much smaller team is going to be a lot more specific and, you like pinpoint an exact use case with each component, which makes it a lot easier to use. But of course it's a little bit restricting. So it's fun to see the differences just.

Even as like one designer, me, right now, I'll build a design system for three different clients in three, maybe completely different ways, just based on their needs and their scope.

Deep Dives

Get our weekly breakdowns

Insights + resources from top designers 👇

Lauren LoPrete

Director of Design Systems @ Cash App

David Hoang

VP of Marketing and Design @ Replit

Adrien Griveau

Founding Designer @ Linear

James McDonald

Designer @ Clerk

Femke

Design Lead @ Gusto

Join 10K+ designers

HC

HC

HC

HC

"

I've been binging Dive Club lately and the quality is nuts

Literally the only show about design I watch”

Eugene Fedorenko

"

I've been binging Dive Club lately and the quality is nuts

Literally the only show about design I watch”

Eugene Fedorenko

hello@dive.club

Ⓒ Dive 2024