Season 2
|
Episode 3
Strategies for using variables in Figma
Luis Ouriach
Designer Advocate @ Figma
Aug 10, 2023
Aug 10, 2023
|
43 min
43 min
music by Dennis
About this Episode
If you're looking to level up how you use variables in Figma then this episode is for you ✌️ Luis goes deep into strategies based on team size, provides naming guidance, and even breaks down how he thinks about structuring libraries with variables in Figma. Lastly, Luis shares a behind-the-scenes of his journey as a designer advocate and even gives a unique prediction for how AI will take shape inside of Figma.
Don't forget to follow Luis on Twitter and check out his awesome files in the Figma community
Deep Dives
Get every episode
Free lessons from the top designers 👇
Fonz Morris
Lead monetization designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Jorn van Dijk
CEO @ Framer
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 6K+ designers
HC
HC
HC
HC
Deep Dives
Get every episode
Free lessons from 👇
Fonz Morris
Lead designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 6K+ designers
HC
HC
HC
Transcript chapters
Luis’s journey as a designer advocate
[00:00:00] Luis: I started in Figma in June 2020. I had also originally been on the Figma professional plan before joining.
[00:00:08] So I joined. I'm joining customer calls, everybody's on the organization plan, which I'd never seen before. They're all talking about design systems at scale, which again, was kind of alien to me. At that moment, I knew that something needed to change. And that meant that really knuckling down on just learning components inside out. Fast forward maybe a year or so, there's more people using, firstly using Figma, but secondly, way more interested in design systems. And that to me was a, an opportunity for knuckling down even further.
[00:00:40] My attitude immediately to become way more component focused, give practical advice, guides, structures, organizations based off the year of stuff I've just done. So that pivoted massively into just providing resources endlessly. Publish, publish, publish, publish, publish every single day.
[00:00:55] Then, as more people become interested in design systems and the more people I talk to about [00:01:00] design systems, the more this phrase keeps coming up, tokens.
[00:01:04] Another thing that I really didn't know much about are new styles in Figma and arguably not too dissimilar in concept. But that was my next biggest rock to climb.
[00:01:16] So I started to just pay attention. Ask every single person I spoke to what they're doing.
[00:01:22] What tokens are you implementing?
[00:01:24] Are they synchronized across design development?
[00:01:26] What's your naming architecture?
[00:01:28] Do you how many levels of aliasing do you use?
[00:01:31] Really drilling in to understand what the largest customers or companies in the world are doing just to let that sit in my brain
[00:01:38] And then I need to be confident advising other people about it. We had our conference, Config, and we started to get really close to people giving best practice advice on what to do in this space. As that conference finished, we knew what the next year's releases were likely to be, which included [00:02:00] variables, or tokens as we would have called it then.
[00:02:02] Well, I've got this, like, two and a half years of really knuckling down on systems architecture, components, all these guides that I've been doing.
[00:02:12] People are now kind of expecting that something needs to come out of my mouth that tells them how to approach this topic. So I signed up to an internal project, which was to prepare the assets for the conference. That allowed me to dedicate a lot of time to scoping this out really applying some of the key principles. I'd spent two and a half years absorbing and Then put it to everybody in the crowd at a live Biggest conference I've ever seen in my entire life,
[00:02:41] and then I got asked if I wanted to talk about it myself And that meant like really hibernating nobody saw me for a couple of months and I dove really deep into practical applications of token slash variables in Figma and just shared and try to fail as much as possible [00:03:00] internally and externally.
[00:03:02] And then that kind of ended up with me being on stage in front of 4, 000 people talking about something that I technically didn't know about very much, 3, 6, 9, 12 months before, but felt confident to do it because of those two and a half years of absorption mode.
Luis’s journey as a designer advocate
[00:00:00] Luis: I started in Figma in June 2020. I had also originally been on the Figma professional plan before joining.
[00:00:08] So I joined. I'm joining customer calls, everybody's on the organization plan, which I'd never seen before. They're all talking about design systems at scale, which again, was kind of alien to me. At that moment, I knew that something needed to change. And that meant that really knuckling down on just learning components inside out. Fast forward maybe a year or so, there's more people using, firstly using Figma, but secondly, way more interested in design systems. And that to me was a, an opportunity for knuckling down even further.
[00:00:40] My attitude immediately to become way more component focused, give practical advice, guides, structures, organizations based off the year of stuff I've just done. So that pivoted massively into just providing resources endlessly. Publish, publish, publish, publish, publish every single day.
[00:00:55] Then, as more people become interested in design systems and the more people I talk to about [00:01:00] design systems, the more this phrase keeps coming up, tokens.
[00:01:04] Another thing that I really didn't know much about are new styles in Figma and arguably not too dissimilar in concept. But that was my next biggest rock to climb.
[00:01:16] So I started to just pay attention. Ask every single person I spoke to what they're doing.
[00:01:22] What tokens are you implementing?
[00:01:24] Are they synchronized across design development?
[00:01:26] What's your naming architecture?
[00:01:28] Do you how many levels of aliasing do you use?
[00:01:31] Really drilling in to understand what the largest customers or companies in the world are doing just to let that sit in my brain
[00:01:38] And then I need to be confident advising other people about it. We had our conference, Config, and we started to get really close to people giving best practice advice on what to do in this space. As that conference finished, we knew what the next year's releases were likely to be, which included [00:02:00] variables, or tokens as we would have called it then.
[00:02:02] Well, I've got this, like, two and a half years of really knuckling down on systems architecture, components, all these guides that I've been doing.
[00:02:12] People are now kind of expecting that something needs to come out of my mouth that tells them how to approach this topic. So I signed up to an internal project, which was to prepare the assets for the conference. That allowed me to dedicate a lot of time to scoping this out really applying some of the key principles. I'd spent two and a half years absorbing and Then put it to everybody in the crowd at a live Biggest conference I've ever seen in my entire life,
[00:02:41] and then I got asked if I wanted to talk about it myself And that meant like really hibernating nobody saw me for a couple of months and I dove really deep into practical applications of token slash variables in Figma and just shared and try to fail as much as possible [00:03:00] internally and externally.
[00:03:02] And then that kind of ended up with me being on stage in front of 4, 000 people talking about something that I technically didn't know about very much, 3, 6, 9, 12 months before, but felt confident to do it because of those two and a half years of absorption mode.
The value of learning in public
[00:03:18] Ridd: It's, it's cool to hear you talk about the like, sharing and hitting publish, publish, publish. Because one of my favorite places to learn about variables right now is you and what you put on Twitter.
[00:03:29] And I think a lot of that is because you can see that you are actively learning. You're just hungry to learn and you put something out there and inevitably somebody on Twitter Comments and like well, what about this?
[00:03:40] Why'd you do this and your responses to those comments? I think it's like the best place to learn about tokens or variables on the internet right now You are a learner who's a couple steps further along in the journey And that's kind of how you portray yourself, which I appreciate
[00:03:56] Luis: Yeah, what I really want to do is take this exposure that I have. [00:04:00] of three months arguably ahead of people seeing something and knowing that they're going to hit the same roadblocks, hit the same walls I hit as I was trying to learn about it, and just open that door as wide as possible to then talk with people in public transparently.
[00:04:19] But I also think it's really important to not really necessarily be attached to this perception of being right or wrong. I will try to preface as much as possible that I am still figuring it out and try to share. If I come across a really good resource, I'll share it for sure.
[00:04:38] So it's a combination of... Constantly sharing, asking for feedback by sharing, and then sharing other people's resources which means that you're just creating this like loop, feedback loop of share, feedback, share, feedback, publish. And before you know it, you've just created loads of stuff without even really realizing.
[00:04:59] And like you said, [00:05:00] the responses that I get... Uh, because I have this platform, whereas people who are doing really, really good work don't necessarily get that response back either. And I feel like that's my responsibility to share what they're doing around as well.
The value of learning in public
[00:03:18] Ridd: It's, it's cool to hear you talk about the like, sharing and hitting publish, publish, publish. Because one of my favorite places to learn about variables right now is you and what you put on Twitter.
[00:03:29] And I think a lot of that is because you can see that you are actively learning. You're just hungry to learn and you put something out there and inevitably somebody on Twitter Comments and like well, what about this?
[00:03:40] Why'd you do this and your responses to those comments? I think it's like the best place to learn about tokens or variables on the internet right now You are a learner who's a couple steps further along in the journey And that's kind of how you portray yourself, which I appreciate
[00:03:56] Luis: Yeah, what I really want to do is take this exposure that I have. [00:04:00] of three months arguably ahead of people seeing something and knowing that they're going to hit the same roadblocks, hit the same walls I hit as I was trying to learn about it, and just open that door as wide as possible to then talk with people in public transparently.
[00:04:19] But I also think it's really important to not really necessarily be attached to this perception of being right or wrong. I will try to preface as much as possible that I am still figuring it out and try to share. If I come across a really good resource, I'll share it for sure.
[00:04:38] So it's a combination of... Constantly sharing, asking for feedback by sharing, and then sharing other people's resources which means that you're just creating this like loop, feedback loop of share, feedback, share, feedback, publish. And before you know it, you've just created loads of stuff without even really realizing.
[00:04:59] And like you said, [00:05:00] the responses that I get... Uh, because I have this platform, whereas people who are doing really, really good work don't necessarily get that response back either. And I feel like that's my responsibility to share what they're doing around as well.
The problem with copying other systems
[00:05:17] Ridd: When you were originally Just kind of positioning yourself as a sponge and trying to soak up as much of like what's working and what different companies are doing How much variance were you seeing between how these different big established companies were handling tokens?
[00:05:32] Luis: The common thread that I do see is people mostly copying publicly available systems, which is great, but also kind of problematic because they have figured it out for their company. And what applies to one company doesn't necessarily apply to another. There are some really good foundational pieces of work out there that allow you to Get to grips with something or at least something like a naming convention pretty quick. But it's also going to have loads of [00:06:00] variants according to your implementation as a design team. So really it is go and play around. Take your existing work and try to retrospectively build the variables to support it.
[00:06:13] That will force you into realizing what you need to support based off what you don't currently have. No other company is going to be able to provide you with the answer to those questions unless you spend the time to figure it out.
The problem with copying other systems
[00:05:17] Ridd: When you were originally Just kind of positioning yourself as a sponge and trying to soak up as much of like what's working and what different companies are doing How much variance were you seeing between how these different big established companies were handling tokens?
[00:05:32] Luis: The common thread that I do see is people mostly copying publicly available systems, which is great, but also kind of problematic because they have figured it out for their company. And what applies to one company doesn't necessarily apply to another. There are some really good foundational pieces of work out there that allow you to Get to grips with something or at least something like a naming convention pretty quick. But it's also going to have loads of [00:06:00] variants according to your implementation as a design team. So really it is go and play around. Take your existing work and try to retrospectively build the variables to support it.
[00:06:13] That will force you into realizing what you need to support based off what you don't currently have. No other company is going to be able to provide you with the answer to those questions unless you spend the time to figure it out.
How strategies differ by team size
[00:06:29] Ridd: One of the challenges of being someone who is looked to for advice on this topic is. It varies so much between the size and how well established a given team is.
[00:06:40] What are like the lenses that a product owner should have when they're evaluating what makes sense for their team specifically.
[00:06:49] Luis: Firstly, you need to ask yourself if you need to be doing it. You need to really think, is this going to have a positive impact on the business? Right away. If the, if the answer is no, [00:07:00] let's deprioritize it for now and come back to it when it makes sense. There is a real hard problem of giving advice to different sizes of team, different sizes of business, different platforms different industries, but I do genuinely think that there is a baseline level of advice that everybody can get. I generally give similar advice to people regardless of their industry, team size, scale. It's just the amount that you might be doing and the amount of process that surrounds it. So you might have more people involved making or helping to make that decision about the name of your variable.
[00:07:42] But you still need to name it and you could still rely on a strong foundation that I could hopefully help you figure out. I think a UI kit would be way more successful if it gave you some sort of foundation rather than the answer.
How strategies differ by team size
[00:06:29] Ridd: One of the challenges of being someone who is looked to for advice on this topic is. It varies so much between the size and how well established a given team is.
[00:06:40] What are like the lenses that a product owner should have when they're evaluating what makes sense for their team specifically.
[00:06:49] Luis: Firstly, you need to ask yourself if you need to be doing it. You need to really think, is this going to have a positive impact on the business? Right away. If the, if the answer is no, [00:07:00] let's deprioritize it for now and come back to it when it makes sense. There is a real hard problem of giving advice to different sizes of team, different sizes of business, different platforms different industries, but I do genuinely think that there is a baseline level of advice that everybody can get. I generally give similar advice to people regardless of their industry, team size, scale. It's just the amount that you might be doing and the amount of process that surrounds it. So you might have more people involved making or helping to make that decision about the name of your variable.
[00:07:42] But you still need to name it and you could still rely on a strong foundation that I could hopefully help you figure out. I think a UI kit would be way more successful if it gave you some sort of foundation rather than the answer.
Using variables at a startup
[00:07:55] Ridd: What about for startups specifically? Is there a line [00:08:00] where you feel like it doesn't make sense to cross? Should, how much should teams that are just starting out even be thinking about variables and primitives? So how do you think about the right level of adoption when a team is just starting out?
[00:08:15] Luis: Yeah, you're right in that you're going to need that product market fit before you introduce levels of complexity that... And maybe, uh, larger company things to think about. But you can still be efficient, and efficiency is at the core, I think, of any designer's job. Where, if you can reduce margin of error, you're doing a really good job.
[00:08:37] And that might mean introducing border radius variables to ensure that when it goes to dev, they're all consistent. Introducing spacing variables in your auto layout containers means that you can predict what something's going to look like. When it gets used and when it gets implemented by your developers, they're massive wins and that's something you couldn't do six months ago.
[00:08:59] So [00:09:00] if we can improve the consistency of our design, we're going to be way happier because we have to fix less things that go wrong in production. And of course you can get around that with More communication, it's just a dream, dream state to have a really over communicative team. And sometimes we have to rely on the pixels to make that happen.
[00:09:21] So implementing those more simplistic variable structures means you can sprint towards less errors in your production environment, which is hugely beneficial to a business.
Using variables at a startup
[00:07:55] Ridd: What about for startups specifically? Is there a line [00:08:00] where you feel like it doesn't make sense to cross? Should, how much should teams that are just starting out even be thinking about variables and primitives? So how do you think about the right level of adoption when a team is just starting out?
[00:08:15] Luis: Yeah, you're right in that you're going to need that product market fit before you introduce levels of complexity that... And maybe, uh, larger company things to think about. But you can still be efficient, and efficiency is at the core, I think, of any designer's job. Where, if you can reduce margin of error, you're doing a really good job.
[00:08:37] And that might mean introducing border radius variables to ensure that when it goes to dev, they're all consistent. Introducing spacing variables in your auto layout containers means that you can predict what something's going to look like. When it gets used and when it gets implemented by your developers, they're massive wins and that's something you couldn't do six months ago.
[00:08:59] So [00:09:00] if we can improve the consistency of our design, we're going to be way happier because we have to fix less things that go wrong in production. And of course you can get around that with More communication, it's just a dream, dream state to have a really over communicative team. And sometimes we have to rely on the pixels to make that happen.
[00:09:21] So implementing those more simplistic variable structures means you can sprint towards less errors in your production environment, which is hugely beneficial to a business.
How to leverage text string variables
[00:09:33] Ridd: I love the text string example. It brings back a very specific memory where just a few months ago I was working on a project at Maven. It was so copy heavy and the copy was very educational in nature and I could throw the ball as far as I could, but like, I was not going to be the person that owned that copy and I tried all these different ways of like, I tried making them an editor and figma.
[00:09:54] I had a notion document that we were referencing and then you get all of these like hanging single [00:10:00] words on the three lines and it breaks the UI. And I feel like I dropped the ball on the entire process, honestly, where Text strings are something that's very, very interesting to me because I'm using these same strings in lots of different places and having that source of truth and having it live more closely to Figma rather than me being responsible for referencing Notion at the end of each week.
[00:10:24] It's something that I'm excited about and I feel like I have barely scratched the surface of, obviously.
[00:10:30] Luis: Yeah, there is some very practical advice that we probably want to talk about with regards to things like text string variables. It's very easy to think of them as a content database. And they could be, but that's not necessarily how it should be used or what it was initially designed for. It's great for testing things out
[00:10:48] on a sort of where do they live question as well, I would look at them as being as close to the design as possible, unless they need to be used globally, in which case they might not even need to exist.[00:11:00]
[00:11:00] It's great for testing out in, in the context of what you're doing. However, you might have a global text string database of translations for a button or something like that, in which case that does deserve to live more globally. So there's a decision about, in general, where variables should live. It's all about application in the same way that you'd have that advice for components. Does this component live in one file, three files, or every single file? And that would impact where it gets stored. Similar way to a string variable.
How to leverage text string variables
[00:09:33] Ridd: I love the text string example. It brings back a very specific memory where just a few months ago I was working on a project at Maven. It was so copy heavy and the copy was very educational in nature and I could throw the ball as far as I could, but like, I was not going to be the person that owned that copy and I tried all these different ways of like, I tried making them an editor and figma.
[00:09:54] I had a notion document that we were referencing and then you get all of these like hanging single [00:10:00] words on the three lines and it breaks the UI. And I feel like I dropped the ball on the entire process, honestly, where Text strings are something that's very, very interesting to me because I'm using these same strings in lots of different places and having that source of truth and having it live more closely to Figma rather than me being responsible for referencing Notion at the end of each week.
[00:10:24] It's something that I'm excited about and I feel like I have barely scratched the surface of, obviously.
[00:10:30] Luis: Yeah, there is some very practical advice that we probably want to talk about with regards to things like text string variables. It's very easy to think of them as a content database. And they could be, but that's not necessarily how it should be used or what it was initially designed for. It's great for testing things out
[00:10:48] on a sort of where do they live question as well, I would look at them as being as close to the design as possible, unless they need to be used globally, in which case they might not even need to exist.[00:11:00]
[00:11:00] It's great for testing out in, in the context of what you're doing. However, you might have a global text string database of translations for a button or something like that, in which case that does deserve to live more globally. So there's a decision about, in general, where variables should live. It's all about application in the same way that you'd have that advice for components. Does this component live in one file, three files, or every single file? And that would impact where it gets stored. Similar way to a string variable.
Difference between primitive semantics & component-level tokens
[00:11:31] Ridd: I'd love to get into the weeds and variables even more and maybe we can kind of create this separation between More blank, um, more green pasture. You're just starting off. There's less constraints. How would you kind of do it from scratch? And then separately we can kind of talk about, okay, you probably have this existing system.
[00:11:51] How can we think about like a transition plan and chunking that out into milestones? So let's start with the former. And maybe just as [00:12:00] like a really quick primer just to make sure that everyone listening is On the same page. Can you give us like a little rundown around just the difference between primitive semantics and even component level tokens?
[00:12:13] Luis: Sure, the primitive level is the, call it what it looks like. So it is the green slash 300, or green strong, or however you're defining those, but it's still green. It's the green color that you have in your system, that's probably been provided by the brand team, or the external agency that you got to provide your style guide.
[00:12:34] Green, purple, yellow, orange. This is the list of colors that you probably have stored somewhere. You may have those in Figma at the moment as styles. But, in the world of semantics, we would prefer not to use the token or variable as it's, as it's called, that it's looked like. So the green would be, in the semantic world, something like background success.
[00:12:59] Or it might be border [00:13:00] success, text success, something like that. It might even be more semantic in its background, uh, positive. It might be border positive, text positive. However, there's still that translation. So you've got the primitive layer, which is what does it look like? That might also be on a sizing level, something like size 4 for 4 pixels, size 4 green 100.
[00:13:23] You know exactly what you're going to get. You then alias those into the semantic layer. Separate collection in Figma. Maybe even a separate file in Figma. We can talk about that a bit later. Primitive goes aliased into semantic. You've got your background success. You've got your size compact. Which might be aliasing that primitive size for.
[00:13:48] So you've got a layer in between, which is the alias. primitive goes into semantic. Now the argument about component tokens is contentious. People don't necessarily align with [00:14:00] it as an industry because it can easily be seen as creating more work that is not necessarily required. is more common in the sort of engineering space but not necessarily exposed.
[00:14:13] So you might have component level tokens for example Input background might be something that you have because all the inputs share the same background color in the default state. But that could also just be handled at the semantic level. The default state of the input could be background inactive. You see it's less specific but more global in its intention. The component for the input field which has input background might be something you create because you might need a fork which allows you to do versioning in a different way. So you might need to version a specific component in a different way.
[00:14:49] release, in which case pointing another level down in the aliasing system means you can version that real specific component instead of versioning everything in the semantic level. [00:15:00] So if you need to go down to that level, component tokens might make sense. If you don't, the semantic level is probably more what you need.
[00:15:08] Ridd: Do you think it's safe to say that for the vast majority of designers who are starting off on a new system, they can safely ignore component level tokens?
[00:15:15] Luis: That should be my answer, but I really like it. I find it really valuable. to know that an input background is an input background. If I am going to create a new screen and I'm creating a new type of input field, I'm probably going to search input in my style picker. I'm probably not going to instinctively think background inactive.
[00:15:40] Is that the right token? Is that what I should be searching? So, personally, I really like them, but I totally understand how there could be an interpretation where it's... Too much work. You're creating too many variables to support. We don't need to go to that level. If I was to advise somebody though, I would say maybe consider having [00:16:00] primitive at the top always, but that might get split in a fork so you support semantic and component at the same level.
[00:16:06] Instead of going primitive down to semantic down to component, you might have primitive into semantic and primitive into component. That way you're supporting component and primitive at the same level. But very different specificities That's what I would probably advise somebody to do if they really wanted to go to that level But as I said The industry is kind of aligned on semantic layer being the only one you need
Difference between primitive semantics & component-level tokens
[00:11:31] Ridd: I'd love to get into the weeds and variables even more and maybe we can kind of create this separation between More blank, um, more green pasture. You're just starting off. There's less constraints. How would you kind of do it from scratch? And then separately we can kind of talk about, okay, you probably have this existing system.
[00:11:51] How can we think about like a transition plan and chunking that out into milestones? So let's start with the former. And maybe just as [00:12:00] like a really quick primer just to make sure that everyone listening is On the same page. Can you give us like a little rundown around just the difference between primitive semantics and even component level tokens?
[00:12:13] Luis: Sure, the primitive level is the, call it what it looks like. So it is the green slash 300, or green strong, or however you're defining those, but it's still green. It's the green color that you have in your system, that's probably been provided by the brand team, or the external agency that you got to provide your style guide.
[00:12:34] Green, purple, yellow, orange. This is the list of colors that you probably have stored somewhere. You may have those in Figma at the moment as styles. But, in the world of semantics, we would prefer not to use the token or variable as it's, as it's called, that it's looked like. So the green would be, in the semantic world, something like background success.
[00:12:59] Or it might be border [00:13:00] success, text success, something like that. It might even be more semantic in its background, uh, positive. It might be border positive, text positive. However, there's still that translation. So you've got the primitive layer, which is what does it look like? That might also be on a sizing level, something like size 4 for 4 pixels, size 4 green 100.
[00:13:23] You know exactly what you're going to get. You then alias those into the semantic layer. Separate collection in Figma. Maybe even a separate file in Figma. We can talk about that a bit later. Primitive goes aliased into semantic. You've got your background success. You've got your size compact. Which might be aliasing that primitive size for.
[00:13:48] So you've got a layer in between, which is the alias. primitive goes into semantic. Now the argument about component tokens is contentious. People don't necessarily align with [00:14:00] it as an industry because it can easily be seen as creating more work that is not necessarily required. is more common in the sort of engineering space but not necessarily exposed.
[00:14:13] So you might have component level tokens for example Input background might be something that you have because all the inputs share the same background color in the default state. But that could also just be handled at the semantic level. The default state of the input could be background inactive. You see it's less specific but more global in its intention. The component for the input field which has input background might be something you create because you might need a fork which allows you to do versioning in a different way. So you might need to version a specific component in a different way.
[00:14:49] release, in which case pointing another level down in the aliasing system means you can version that real specific component instead of versioning everything in the semantic level. [00:15:00] So if you need to go down to that level, component tokens might make sense. If you don't, the semantic level is probably more what you need.
[00:15:08] Ridd: Do you think it's safe to say that for the vast majority of designers who are starting off on a new system, they can safely ignore component level tokens?
[00:15:15] Luis: That should be my answer, but I really like it. I find it really valuable. to know that an input background is an input background. If I am going to create a new screen and I'm creating a new type of input field, I'm probably going to search input in my style picker. I'm probably not going to instinctively think background inactive.
[00:15:40] Is that the right token? Is that what I should be searching? So, personally, I really like them, but I totally understand how there could be an interpretation where it's... Too much work. You're creating too many variables to support. We don't need to go to that level. If I was to advise somebody though, I would say maybe consider having [00:16:00] primitive at the top always, but that might get split in a fork so you support semantic and component at the same level.
[00:16:06] Instead of going primitive down to semantic down to component, you might have primitive into semantic and primitive into component. That way you're supporting component and primitive at the same level. But very different specificities That's what I would probably advise somebody to do if they really wanted to go to that level But as I said The industry is kind of aligned on semantic layer being the only one you need
Strategies for starting from scratch
[00:16:34] Ridd: So if you're starting from scratch, what are the core primitives that you think designers should be thinking about?
[00:16:41] Luis: So if you're starting brand new, Firstly, do you have a product market fit on what you're trying to do? And do you need to start using variables? If you do, figure out the least amount of variables that you need to support the most amount of cases. So that would just be relying on that semantic [00:17:00] layer. So that is a case of taking one of your screens, and if you're in a team, run a workshop. Ask people what they would call every single color that you have on that screen.
[00:17:10] And then try to do some sort of grouping of the themes that you're finding in the results that people are giving you because that's going to be incredibly important for adoption. You're going to need to know that people can actually find the variables that you've created. In the search panel, if they can't, we have a big problem.
[00:17:27] And this is where design teams would often find themselves with those adoption problems, because that piece of research internally hasn't happened. Maybe you've aligned with an external third party system or something, which isn't the way your team works. So my example of background success might be that it needs to be called background positive in your team.
[00:17:49] So that abstraction of what does this mean for our team is incredibly important for what then you go and name anything in your system, let alone the variables that are powering the whole thing.[00:18:00]
Strategies for starting from scratch
[00:16:34] Ridd: So if you're starting from scratch, what are the core primitives that you think designers should be thinking about?
[00:16:41] Luis: So if you're starting brand new, Firstly, do you have a product market fit on what you're trying to do? And do you need to start using variables? If you do, figure out the least amount of variables that you need to support the most amount of cases. So that would just be relying on that semantic [00:17:00] layer. So that is a case of taking one of your screens, and if you're in a team, run a workshop. Ask people what they would call every single color that you have on that screen.
[00:17:10] And then try to do some sort of grouping of the themes that you're finding in the results that people are giving you because that's going to be incredibly important for adoption. You're going to need to know that people can actually find the variables that you've created. In the search panel, if they can't, we have a big problem.
[00:17:27] And this is where design teams would often find themselves with those adoption problems, because that piece of research internally hasn't happened. Maybe you've aligned with an external third party system or something, which isn't the way your team works. So my example of background success might be that it needs to be called background positive in your team.
[00:17:49] So that abstraction of what does this mean for our team is incredibly important for what then you go and name anything in your system, let alone the variables that are powering the whole thing.[00:18:00]
Red flags to look out for
[00:18:01] Ridd: What are some of the red flags or signals that might indicate that you're over architecting your system and arriving at a level of specificity that's actually doing more harm than good?
[00:18:14] Luis: It would be loads of variables that have the same value. Either that is a really good thing or a really bad thing because it could mean that you are building for a future that never exists or your, your current reality is that loads of people have different names for the same thing.
[00:18:35] The biggest red flag that even I have done when I've been playing around is predicting variables that I end up never needing. Does every single variable need a hover focus disabled state, or do you want to build those when you need them? So, as I said, just figure out, based off a screen, for example, what variables you need to support right now, and just build them and release them as they come up.[00:19:00]
[00:19:00] Instead of spending months in the corner figuring out something that maybe you don't need yet.
Red flags to look out for
[00:18:01] Ridd: What are some of the red flags or signals that might indicate that you're over architecting your system and arriving at a level of specificity that's actually doing more harm than good?
[00:18:14] Luis: It would be loads of variables that have the same value. Either that is a really good thing or a really bad thing because it could mean that you are building for a future that never exists or your, your current reality is that loads of people have different names for the same thing.
[00:18:35] The biggest red flag that even I have done when I've been playing around is predicting variables that I end up never needing. Does every single variable need a hover focus disabled state, or do you want to build those when you need them? So, as I said, just figure out, based off a screen, for example, what variables you need to support right now, and just build them and release them as they come up.[00:19:00]
[00:19:00] Instead of spending months in the corner figuring out something that maybe you don't need yet.
Luis’s approach to semantic naming
[00:19:06] Ridd: If you were in your own Figma file and you're building this new system for a startup, what is your semantic naming system? And how would you even think about the number of variables that you would need to create?
[00:19:19] Luis: I would break, break down things into, I focus a lot on color, so I'd break down into different types or application. Background, text, icon, and border. Then take an example of our screen and just apply, or split I should say, up a screen into the different color types. Then think about the different states of those different color types.
[00:19:43] Then think about the different modes of the states of the different color types that we have. So, we've got four different color types. The background, the border, the text, and the icon. Some of those might need a hover. Some of those might need a focus. Some of those might be fixed values across light and dark mode.[00:20:00]
[00:20:00] Some of them might not. We've already introduced tons of complexity and I've been talking for 30 seconds about it. So, what we need to do is nail down a mode. If you work in light mode or dark mode as default, nail that down. And make sure we've got that primitive layer feeding into all those different variables that we have in an example screen. Duplicate the screen, create another mode for dark, flip it over to dark mode, and start to pick apart each individual variable, and change the value so that firstly the color contrast works, when you're pulling in a primitive, and that the pairs work, and that all those fixed values, maybe you have white text that should always be white text.
[00:20:42] Make sure that also works in the reverse. It might mean you need to create more variables, it might mean you need to create less variables, but the practical application of them as you're building them, so you're kind of doing this side by side dance of variables, panels, screen, quick, back and forth, back and forth, you'll know very quickly whether something's working or not. [00:21:00] But importantly, you've got the primitives being fed down, which you can choose a different value if it needs to be different across different modes. For example, your background success might be way lighter in dark mode than the darkness it is in light mode. That's totally fine if you're feeding it in from a primitive color ramp.
[00:21:20] As long as you've got those pairs and those relationships set up, you can decide the visual differences in different themes based off the color contrast you want to achieve. So fundamentally, you've got this goal underneath of people being able to use it, minimum amount of variables, and different states that you want to cover.
[00:21:37] And that's a lot of work in itself to go and keep yourself busy for a while. Sure.
Luis’s approach to semantic naming
[00:19:06] Ridd: If you were in your own Figma file and you're building this new system for a startup, what is your semantic naming system? And how would you even think about the number of variables that you would need to create?
[00:19:19] Luis: I would break, break down things into, I focus a lot on color, so I'd break down into different types or application. Background, text, icon, and border. Then take an example of our screen and just apply, or split I should say, up a screen into the different color types. Then think about the different states of those different color types.
[00:19:43] Then think about the different modes of the states of the different color types that we have. So, we've got four different color types. The background, the border, the text, and the icon. Some of those might need a hover. Some of those might need a focus. Some of those might be fixed values across light and dark mode.[00:20:00]
[00:20:00] Some of them might not. We've already introduced tons of complexity and I've been talking for 30 seconds about it. So, what we need to do is nail down a mode. If you work in light mode or dark mode as default, nail that down. And make sure we've got that primitive layer feeding into all those different variables that we have in an example screen. Duplicate the screen, create another mode for dark, flip it over to dark mode, and start to pick apart each individual variable, and change the value so that firstly the color contrast works, when you're pulling in a primitive, and that the pairs work, and that all those fixed values, maybe you have white text that should always be white text.
[00:20:42] Make sure that also works in the reverse. It might mean you need to create more variables, it might mean you need to create less variables, but the practical application of them as you're building them, so you're kind of doing this side by side dance of variables, panels, screen, quick, back and forth, back and forth, you'll know very quickly whether something's working or not. [00:21:00] But importantly, you've got the primitives being fed down, which you can choose a different value if it needs to be different across different modes. For example, your background success might be way lighter in dark mode than the darkness it is in light mode. That's totally fine if you're feeding it in from a primitive color ramp.
[00:21:20] As long as you've got those pairs and those relationships set up, you can decide the visual differences in different themes based off the color contrast you want to achieve. So fundamentally, you've got this goal underneath of people being able to use it, minimum amount of variables, and different states that you want to cover.
[00:21:37] And that's a lot of work in itself to go and keep yourself busy for a while. Sure.
Deep Dives
Get every episode
Free lessons from the top designers 👇
Fonz Morris
Lead monetization designer @ Netflix
Mia Blume
Past leader @ Pinterest, Square
Jorn van Dijk
CEO @ Framer
Femke
Design lead @ Gusto
Kenny Chen
UX lead @ Google
Join 6K+ designers
HC
HC
HC
HC
Ⓒ Dive 2023
