Test Gist

Oh_my_gosh_like_cre.txt

Oh my gosh, like creating a tooltip that automatically knows whether it's on the right or the left side of the page, no matter the actual device size. Like, if you're on a mobile, it will move to the left side. If it's closer to the right, if you're on a desktop screen, it will transition to where it needs to be. That was so much math. I didn't realize how much math was incorporated in these bits. So I would say the most rookie mistakes I have ever made was just creating a tooltip without thinking about what it would look like on smaller device sizes, etc. So yeah, that was a big rookie mistake that I kind of don't want to ever make again. So the next question is, how do you coordinate a design system with third-party vendors that have limited customizations? Our third-party design system vendor was Tailwind. And although Tailwind is mostly around CSS, it wasn't so much about, "Hey, here's the navigation," because unfortunately, if you use Bootstrap, it will give you an app. It's like, "Hey, here's everything you will need," with an F. That became a big issue when we wanted to add things or subtract things or change things about that actual system. There, you know, it became a problem. So we moved on to a system like Tailwind. The issues that we found with Tailwind was not having enough customization. So I feel like it depends, you know? Coordinating a design system with third-party vendors, it really depends on what's the right amount of customization that you need for your system and then what are things you actually do need from this system? Like, for instance, with us, we wanted a very cohesive color system. Our color system at the time was very dependent on exact values. Like, think about this, let's say you're trying to build a button, right? How do we do that? How do we make sure things are compatible to a certain extent that can be scaled? It depends on what you mean by scaling. But in my perspective, I feel like scaling will really depend on where you are going with your design system and what scaling actually means for you. If it just means building a new feature, or if it means how do we make sure that this particular navigation is compatible with all of our products, I think it just depends on what you mean by scaling. So I have to say, I don't know for sure what you mean, but I would say it depends. I know that's a bad answer. Oh, hi. Hi, amazing Cube You a, thank you so much. I wanted to pop up because we are hitting the half an hour, but there have been so many requests in my DMs and also in the chat to book around to all this sort of stuff. This went so quickly, and I apologize. So we might have to wrap it up, all right, but I will be in touch to see if there is an opportunity for around two, of course, I will be ready for it. Thank you so much, guys. See you later? Yes, please. Yes, please. Bye-bye. And with that button, you want to make sure the active state was a very slightly different, darker tone than the default state. And then with the hover state, you need a different color. Well, with those differences in hues, I wanted to create a system where we're able to use math to create the hues because unfortunately, with different devices like Android, iOS, just because you use a certain color doesn't mean that same color will be the color you will be using on Android. There will be a slightly different color variation within different devices. So I kind of wanted our system to create those colors for us. And to do that, we needed a system that could be flexible enough to calculate those colors for us. And yeah, we bootstrapped and did that. Unfortunately, we needed those systems like Tailwind or things like that to add a bit of math to it to keep consistency. When I moved to Skillshare, reusing material, I feel like that one did a bit more. I don't want to say damage, but it created more consistency issues for us. So Tailwind, in my opinion, was still the top-tier solution to use when it comes to consistency, and it was consistent no matter what device you're using. So that's kind of how we coordinated what customization we'll use and what kind of system we'll use to create that kind of consistency. We wanted a system that would allow us to create that consistency that we kind of couldn't create by ourselves. So I hope that answered that question. Thank you so much, Kristen. Next question, Fatima. All right. Do you use some plugins in Figma to make your work faster and Design Systems? If yes, which ones? Oh goodness. Now I need to go into my Figma file to see which ones I use the most. Now I know I definitely use there's a theme. I am actually checking right now to give me one second. Let me pull everything up. There is a plugin that I use that was vital when it came to theming, and that was me figuring out the name of it. Got five upvotes, how to maintain spacing cohesively in a design system, especially in a complex design system. I will leave it to you, then I will be back up to the next question. Perfect. So what we have done at Heroku/Salesforce is what we did was we used, I don't know if everyone's acquainted or knows about this system, but it's called "Tailwind" and we use Tailwind to keep our spacing cohesive. And yeah, we incorporated that same system with rims over to our actual design system as well on the Figma side. So yeah, that's how we created and maintained spacing cohesively on the system. Let us go to the next question. Next question, we have got Ricardo. How do you kickstart a design system project and keep it as practice inside a corporation company project? Ooh, so that was mostly about trying to figure out where to start, what was everyone's knowledge and understanding of what a design system was. Once we figured out what everyone thought it was, we're like, okay, here's what it is. Here's how we can start off with our designs. Then here are some things that we can start off doing on the design side. Then here's what we can do on the engineering side. It started with the design portion, of course, to just show, hey, here's what we're going to do with icons. Here's what we're going to do with the navigation bar. Here's what we're going to do with the component tree. Here's where we are going to do with all these different bits. And once we got that whole cohesive library set up, we moved on to the engineering team to say, hey, could we show this in any kind of way? And of course, a lot of folks use Storybook if you've ever heard of Storybook before, but yeah, we kind of started off with the design team first to get a, here's the sense, here're the visuals, here's our ideas of what we want, and then we moved on to the engineering team to show that, I guess the visual of what we are trying to portray. So I hope that answers that question. Yeah. So we had Skillshare Core, and then we had a Skillshare teacher form that we were creating. I wanted to create a different color theme and settings for those users. If you were just a regular member, you would have a certain view, but if you were a teacher, you would see Skillshare from a different standpoint. We used Themer to switch around those different things. We also used Token Studio for Figma. Token Studio has been a game changer when it comes to keeping your colors and component tree organized. I mostly leaned towards theming plugins and also used a plugin called Gist for documenting my components. Gist allowed me to communicate with designers about why they would want to detach or change a component. This allowed for better communication and collaboration. I recommended using Gist to create documentation and Themer to create component trees and themes. In your point of view, how does AI influence Design Systems as a discipline and as a process? Let me open up my design system now. Thank goodness, I still have access to some of them. I am going to open up my Skillshare system, right? And the plug-in was called, okay. There are two, there's one called Themur that one I found to be the easiest one to just quickly transition. So I was creating the theme around certain products that we had. So we had Skillshare Core, and then we had, you know, Skillshare, what did we call it? Oh, goodness, it was Skillshare Core, and then it was also a Skillshare kind of like a teacher form that we were creating. So I kind of wanted to create a different color theme and different settings for those users. So if you were just a member, then you would have a certain thing. But if you were a teacher, you would see Skillshare from a different standpoint. So we're using Themur to just switch around those different things. We also use Tokens Studio for Figma. I don't know if you have ever heard of Token Studio, but Token Studio has been like a game-changer when it comes to keeping your colors and keeping your actual component tree in a more of a seamless kind of process. So I was mostly leaning toward theming kind of plugins, and I also leaned toward this thing called Gist. So the Gist plugin was all around documenting my components, letting people know exactly how to use the component. If they ever stumble upon this component in the wild, it will literally show a little modal saying, "Hey, here's how to use this component." I am so happy. I said, "there were, right?" The first time when you started to get to that level, I feel like that's when it's time for a design system when you start to repeat yourself quite a bit. If you are never in a spot where you're repeating, I don't think a design system is for you. I just don't. But once you start to get to that repeating state, please, it would be in your best interest and the engineer team's to create a design system. So, yeah, that's what I am thinking. Next one is Christian for a company with an array of products. What is the best way to organize component libraries when there are unique components for each product? You're reading my mind, Christian. So at Skillshare, we had about three different products. At Salesforce, of course, there are so many products to pick from, and I made a design system for each product. I did not mix them. The great part about that was sometimes, let's say there is a product on the teacher platform. I was able to pull in especially tables. We needed a lot of tables. We needed a lot of analytics dashboards for our teachers to know, "Hey, this student is struggling," or "This student really loves this particular part of your video. You should do more of that." When it comes to creating that kind of table, we were able to also use that same table. Thank goodness for our student platform. So we pulled in those same components and graduated the components to our teacher and student platform to show them, "Hey, student, you're doing very well in this part." If you ever want to detach, this is how you do it. Let us know why you detached it, things like that. Allow me to know why a designer would detach, shock opponents, or why they would want to change a thing when they will need to request, "Hey, can we add a button here? Can we do something differently with this opponent?" Just really allowed that communication to happen. So I would definitely, oh I am sorry, I kind of hit the mic. They recommended using Jest to create documentation but also Themer, which was my favorite one to create that component tree and themes. So, hopefully that answered your question. Next one is, in your point of view, how can AI influence Design Systems as a discipline and as a process? So, in my opinion, I feel like AI would totally help us create the documentation that everyone hates. No one likes writing documentation. I don't care who you are. You do not like writing documentation. Documentation is probably the most time-consuming thing that ever happened when it comes to design systems and I feel as though maybe to a certain extent, AI can totally help there. When it comes to creating that customization, I don't think AI is best with that. But on the areas of Design Systems that are very repeatable, like buttons and navigation and tables, those kind of repeatable patterns, those repeatable components, can totally be taken away. I would actually love that, actually. All right, Nakia, how do you start to implement a design system with an established application? What are some best practices? I think an audit of the entire system is the best beginner's step. I think in Dan's book, he did talk about creating that initial audit. What does the nav look like on each page? What do buttons look like on each page? What do icons look like on each page? Hi amazing Cube You, thank you so much. I wanted to pop up because we are hitting the half an hour, but there's been so many requests in my DMs and also in the chat to, you know, book around to all this sort of stuff. This went so quickly, and I apologize. So we might have to wrap it up, all right, but I will be in touch to see if there is an opportunity for around two, of course, I will be ready for it. Thank you so much, guys. See you later? Yes, please. Yes, please. Bye-bye. So we are going to upload it to disco after. So if you need to stretch your legs or grab a cup of tea, feel free to do so. And if you're sharing this on social media, tag Dribble. We'll repost everything that you guys share, okay? Without further ado, I would love to introduce our first Q&A guest speaker of this course week one. We have got the new reporter seller. Nora is a senior product designer based in Miami. She's worked on design systems at Skillshare and Salesforce and is a super talented force to be reckoned with in the design systems world. So we're so grateful and happy that she is with us today. Start asking your questions. I already see one is in there. And without further ado, we will get Lenora up. Hello everyone. Hi, you're right. I have worked on Salesforce and on Skillshare. I am now with Digital Ocean working through their systems and their design, so it's been awesome working with them for about four months. So yeah, nicer. I guess, beginning steps of working on a new system, which is awesome. I am not proud of them. I made a lot of those mistakes on the cells for system, which to me was the best place to make the mistakes because with the cells for system, there was already an accessibility champion part of that system. So a lot of my time was spent on reaching out and saying, hey, is this how this thing works? Is this the best way to do this? What are the areas that I worked on? I will give you some background on me a little bit. I am sure you probably, I don't know if everyone went to my website and saw the little video resume I have on there, but I tried to give a quick one-minute video of who I am, but it kind of separates my experience. So the very first year or maybe two years, it was about two years of experience. I was on the engineering team on the design system and then I transitioned to the design team for the last two years. So two years on the engineering team, two years on the design team, four years in total of working on designing systems, and that experience taught me so much about how to compartmentalize my understanding of how to build a cohesive system from both sides. So, back to the question you asked, rookie mistakes. Rookie mistakes are about accessibility, and the areas that I kind of fumbled around with quite a bit were about tooltips. I know that's like the simplest area that you can ever think of, but tooltips were so hard. Oh my gosh, like creating a tooltip that automatically knows whether it's on the right or the left side of the page, no matter the actual device size. Like if you're on a mobile, it will move to the left side. If it's closer to the right, if you're on a desktop screen, it will transition to where it needs to be. That was so much math. I didn't realize how much math was incorporated in these bits. So I would say the most rookie mistakes I have ever made was just creating a tooltip without thinking about what it would look like on smaller device sizes, etc. So yeah, that was a big rookie mistake that I kind of don't want to ever make again. So the next question is, how do you incorporate? Notes. I know you probably don't want to hear that, but the way I kind of did it was created a note component where it says, "Hey, this is the button component, this is an app component, this is the table component," and explain that underneath that contains the actual container. I feel like those are the best ways to organize things. Don't put too much. Don't put all variants inside the same page. I feel like, you know, I usually limit my components to maybe six or five variants. I don't put too many. Of course, buttons might need a little bit more variance, but I think after you get past six, it gets confusing. So, I try to limit a lot of my component tree to at least six different components, and I hope that does help out because organizing can be a bit much when you're starting off with a design system. So, yeah, I would say keep it simple as long as you can. If you do need to add complexity, you know, do that. But try your best to keep it as simple as possible, not giving too many variants and not giving too many components at once. 

Next one is an early-stage startup. There isn't much time or resources to create or manage a design system, and the product-market fit isn't there. When do you suggest starting a real design system? This is a good one. Oh my gosh, for us on the Heroku team, when we started the design system was when we were starting to build new features or new areas of our platform. In the early stages, I do understand it's mostly like, "get it done, get it out, do not waste too much time on the little details." But when you get to a point where you're starting to repeat yourself, and you're starting to create some type of familiarity, here's the way we do this thing, and all of our users know this is the way we have our nav, all of our users know this is the way our buttons work, all of our users know this is where our tables work. You start to get to that kind of familiarity. I am sorry; I never can say that word right. Yeah, that's kind of how we coordinated. What customization will you use? What kind of system will you use to create that kind of consistency? We wanted a system that would allow us to create that consistency that we kind of couldn't create by ourselves. So, I hope that answered that question. Thank you so much, Kristen. Next question, Fatima. All right. Do you use some plugins in Figma to make your work faster and Design Systems? Yes, which ones? Oh goodness. Now I need to go into my Figma file to see which ones I use the most. Now I know I definitely use there's a theme. I am actually checking right now to give me one second. Let me pull everything up. There is a plug-in that I use that was like vital when it came to theming and that was me figuring out the name of it. Let me open up my design system now. Thank goodness. I still have access to some of them. I am going to open up my Skillshare system. Right. And the plug-in was called, Okay. There are two, there's one called Figma Themer that one I found to be the easiest one to just quickly transition. So I was creating the themer around certain products that we had. Those first steps would totally be around what's the most repeatable areas in our platform. Once you figure out those repeatable areas, I think Design Systems are a breeze after that, because most websites are usually nav content area. That's it usually. Of course, there are a lot more details. There are probably tables, there are probably other components, but mostly it's around creating those smaller atom-like components, like buttons, like icons. Those kinds of things. Then you move to the modular components. Then you move to the templates and you move to the structure. But once you get that kind of system set up, I think creating a system from the beginning is a breeze. Once you have those beginner atoms set up, Angela, how do you organize Figma to have everything in an easy way to reference for the team and have variance for the designers? I feel as though the best way to organize any design system is to create notes. I know you probably don't want to hear that, but the way I kind of did it was created a note component where it says, "Hey, this is the button component, this is an app component, this is the table component," and explain that underneath that contains the actual container. I feel like those are the best ways to ever organize things. Don't put too much. Don't put all variants inside of the same page. I feel like, you know, I usually limit my components into maybe like six or five variants. I don't put too many. Of course, buttons might need a little bit more variance, but I think after you get past like six, it gets confusing. So, I try to keep and limit a lot of my component tree to at least six different opponents, and I hope that does help out because organizing can be a bit much when you're starting off with a design system. So, yeah, I would say keep it simple as long as you can. If you do need to add complexity, you know, do that. But try your best to keep it as simple as possible, not giving too many variants and not giving too many components at once. Next one is an early-stage startup. There isn't much time or resources to create or manage a design system, and the product-market fit isn't there. When do you suggest starting a real design system? "So, if you have questions about transitioning into a new system, we're working on a new system. Let me know. As well, amazing. So pumped to have you here. You've got all this experience. I'm in the Q&A tab now and I will kick it off with the first question. Question from Nicholas, which has got five upvotes: how to maintain spacing cohesively in a design system, especially in a complex design system. I will leave it to you, then I will be back up to the next question. Perfect. So what we have done at Heroku/Salesforce is we used a system called "Tailwind" to keep our spacing cohesive. And yeah, we incorporated that same system with "Rim" over to our actual design system as well on the Figma side. So yeah, that's how we created and maintained spacing cohesively in the system. Let's go to the next question. Next question, we've got Ricardo. How do you kickstart a design system project and keep it as practice inside a corporation/company project? Ooh, so that was mostly about trying to figure out where to start, what was everyone's knowledge and understanding of what a design system was. Once we figured out what everyone thought it was, we're like, okay, here's what it is. Here's how we can start off with our designs. Then, here are some things that we can start off doing on the design side." The next one is, I was gonna say, do you just want to read the questions out without me? Yeah, I can totally do. The next one is in your point of view. How will AI influence Design Systems as a discipline and as a process? Oh my gosh, that's a good one. AI in Design Systems can be pretty new. I feel as though it can be perfect for the little smaller pieces like buttons, like areas where there's no particular pattern. I feel like buttons are like a known pattern for everyone. Navigation, known thing, side nav, known areas. But when you go into certain patterns to fulfill certain needs like for instance in DigitalOcean, we're trying to figure out ways to incorporate different identity management systems. So when you focus on identity and Management Systems, you kind of have to think differently about what we're going to do holistically around the entire platform. So in my perspective, when it comes to those set patterns, that's more of a custom thing, but buttons, I mean, come on now, everyone uses buttons, everyone uses icons, everyone uses certain things. So I feel as though setting those normal pieces to design system can totally be taken over by AI. But when you have to think about things in a way of, here's how this particular user uses an identity management system and an atom, and we use it totally different in a member or use it this way. And then I am Bill overuse it this way. That's when I think a human needs to be pulled into that bit. So yeah, I feel as though the smaller bits can be totally taken and created with an actual AI system. The next question we have is what are rookie mistakes you made earlier, Leon, that turned into major lessons for you? Oh my gosh. This one was accessibility? Oh yeah. I made some really big mistakes on that one. I am not happy. This is a good one. Oh my gosh, for us on the Heroku team. When we started the design system, it was when we were starting to build new features or new areas of our platform. In the early stages, I do understand it's mostly like "get it done, get it out, do not waste too much time on the little details." But when you get to a point where you're starting to repeat yourself and you're starting to create some type of "here's the way we do this thing" and all of our users know "this is the way we have our nav," all of our users know "this is the way our buttons work," all of our users know "this is where our tables work." When you start to get to that kind of familiarity, I am sorry, I never can say that word right. I am so happy I said it right the first time. When you start to get to that level, I feel like that's when it's time for a design system. When you start to repeat yourself quite a bit, if you're never in a spot where you're repeating, I don't think a design system is for you. I just don't. But once you start to get to that repeating state, it would be in your best interest and the engineering team's best interest to create a design system. So yeah, that's what I'm thinking. Next one is Christian. For a company with an array of products, what is the best way to organize component libraries when there are unique components to each product? You're reading my mind, Christian. So at Skillshare, we had about three different products. At Salesforce, of course, there are so many products to pick from, and I made design systems for each product. I did not mix them. The great part about that was sometimes, let's say there is a product on the teacher platform. Then here's what we can do. On the engineering side, it started with the design portion, of course, to just show, "Hey, here's what we're going to do with icons. Here's what we're going to do with the navigation bar. Here's what we're going to do with the component tree. Here's what we're going to do with all these different bits." And once we got that whole cohesive library set up, we moved on to the engineering team to say, "Hey, could we show this in any kind of way?" And of course, a lot of folks use Storybook if you've ever heard of Storybook before. But yeah, we kind of start off with the design team first to get a sense of, "Here's the center, here are the visuals, here's our ideas of what we want," and then we moved on to the engineering team to show that, I guess, the visual of what we are trying to portray. So I hope that answers that question. Yeah. The next one is, I was gonna say, do you just want to read the questions out without me? Yeah, I can totally do that. The next one is, in your point of view, how will AI influence Design Systems as a discipline and as a process? Oh my gosh, that's a good one. AI in Design Systems can be pretty new. I feel as though it can be perfect for the little smaller pieces like buttons, like areas where there's no particular pattern. I feel like buttons are like a known pattern for everyone. Navigation, known thing. Side nav, known areas. But when you go into certain patterns to fulfill certain needs, like for instance, in DigitalOcean, we're trying to figure out ways to incorporate different identity management systems. So when you focus on identity and management systems, you kind of have to think differently about what we're going to do holistically around the entire platform. So in my perspective, when it comes to those set patterns, that's more of a custom thing. But buttons, I mean, come on now, everyone uses buttons, everyone uses icons, everyone uses certain things. So I feel as though setting those normal pieces to design system can totally be taken over by AI. But when you have to think about things in a way of, "Here's how this particular user uses an identity management system," and an admin uses it totally different, and a member uses it this way. Oh wait, how do you coordinate a design system with third-party vendors that have limited customizations? So our third-party design system vendor was Tailwind. And although Tailwind is mostly around CSS, it wasn't so much about hate. Here's the navigation because unfortunately, if you use Bootstrap, it will give you an app. It's like, hey, here's everything you will need with an F. That became a big issue when we wanted to add things or subtract things or change things about that actual system. There, you know, it became a problem. So we moved on to a system like Tailwind. The issues that we found with Tailwind was not having enough customization. So I feel like it depends, you know? Coordinating a design system with third-party vendors, it really depends on what's the right amount of customization that you need for your system and then what are things you actually do need from this system? Like, for instance, with us, we wanted a very cohesive color system. Our color system at the time was very dependent on exact values. Like, think about this, let's say you're trying to build a button, right? And with that button, you want to make sure the active state was a very slightly different darker tone than the default state, and then with the hover state, you need a different color. Well, with those differences in hues, I wanted to create a system where we're able to use math to create the hues because unfortunately, with different devices like Android, iOS, just because you use a certain color doesn't mean that same color will be the color you will be using on Android. There will be a slightly different color variation within different devices. So I kind of want our system to create those colors for us, and to do that, we needed a system that could be flexible enough to calculate those colors for us. And yeah, Bootstrap couldn't do that. Unfortunately, we needed those systems like Tailwind or things like that to add a bit of math to it to keep consistency. When I moved to Skillshare, we used Material UI. I feel like that one did a bit more. I don't want to say damage, but it created more consistency issues for us. So Tailwind, in my opinion, was still the top-tier solution to use when it comes to consistency, and it was consistent no matter what device you're using. So, in my opinion, I feel like I could totally help us create the documentation that everyone hates. No one likes writing documentation. I don't care who you are, you do not like writing documentation. Documentation is probably the most time-consuming thing that ever happened when it comes to design systems, and I feel as though maybe to a certain extent, I can totally help there. When it comes to creating that customization, I don't think AI is best with that. But in the areas of Design Systems that are very repeatable, like buttons, navigation, and tables, those kinds of repeatable patterns and components can totally be taken care of. I would actually love that. All right, Nakia, how do you start to implement a design system with an established application? What are some best practices? I think an audit of the entire system is the best beginner's step. In Dan's book, he did talk about creating that initial audit. What does the nav look like on each page? What do buttons look like on each page? What do icons look like on each page? Those first steps would totally be around what's the most repeatable areas in our platform. Once you figure out those repeatable areas, I think Design Systems are a breeze after that because most websites usually have a nav and content area. That's it, usually. Of course, there are a lot more details. There are probably tables, there are probably other components, but mostly it's around creating those smaller atom-like components like buttons and icons. Those kinds of things, then you move to the modular components. Then you move to the templates and you move to the structure. But once you get that kind of system set up, I think creating a system from the beginning is a breeze. Once you have those beginner atoms set up, Angela, how do you organize Figma to have everything in an easy way to reference for the team and have variance for the designers? I feel as though the best way to organize any design system is to create... This is being recorded, so we are going to upload it to Disco after. So if you need to stretch your legs or grab a cup of tea, feel free to do so. And if you're sharing this on social media, tag Dribble. We will repost everything that you guys share, okay? Without further ado, I would love to introduce our first Q&A guest speaker of this course week one. We have got Lenora, a senior product designer based in Miami. She's worked on design systems at Skillshare and Salesforce and is a super talented force to be reckoned with in the design systems world. So we're so grateful and happy that she is with us today. Start asking your questions. I already see one in there. And without further ado, we will get Lenora up. Hello everyone. Hi, you're right. I have worked on Salesforce and on Skillshare. I am now with Digital Ocean working through their systems and their design, so it's been awesome working with them for about four months. So yeah, nice. I guess beginning steps of working on a new system, which is awesome. So if you have questions about transitioning into a new system or working on a new system, let me know as well. Amazing. So pumped to have you here. You have got all this experience. I am in the Q&A tab now and I will kick it off with the first question. Question from Nicholas, which is, oh no, Ricardo. Sorry, Nicholas. You were bumped. I don't know, Nicholas, you back up. I am just going to go with Nicholas's question. I was able to pull in tables, especially since we needed a lot of them. We needed a lot of analytics dashboards for our teachers to know which students were struggling or which students really loved a particular part of the video. When it comes to creating that kind of table, we were able to use the same table. Thank goodness for our student platform. So we pulled in those same components and graduated the components to our teacher and student platform to show them which students were doing very well in certain areas, but maybe needed to work on others or upload a project to see how the teachers would contribute or think about their project. There were so many different aspects of learning how some of our components could also bleed into other areas of our product. So I feel as though splitting them up is awesome, but when there's a chance to feature or graduate a component, please do that. Yeah, I think splitting them up is perfect, but when it's time to graduate the component tree, do that as well. Next one, Alyssa in early-stage, I know that one went. All right, that's Mama, our boss mama. How do you scale a design system? Best practices, oof. Wow, you're coming to the heavy hitters. That one is a bit challenging. I think it depends on what you mean by scaling because sometimes scaling can mean how we can make sure that the same components we're using on the design side of things are the same components they're using on the engineering side. And then I am Bill overusing this way. That's when I think of human needs to be pulled into that bit. So yeah, I feel as though the smaller bits can be totally taken and created with an actual AI system. The next question we have is what rookie mistakes you made earlier that turned into major lessons for you. Oh my gosh. This one was accessibility? Oh yeah. I made some really big mistakes on that one. I am not happy. I am not proud of them. I made a lot of those mistakes on the design system, which to me was the best place to make the mistakes because with the design system, there were already accessibility champions part of that system. So a lot of my time was spent on reaching out and saying, hey, is this how this thing works? Is this the best way to do this? What are the areas that I worked on? I will give you some background on me a little bit. I am sure you probably, I don't know if everyone went to my website and saw the little video resume I have on there, but I tried to give like a little quick one-minute video of who I am, but it kind of separates my experience. So the very first year or maybe two years, it was about two years of experience. I was on the engineering team on the design system and then I transitioned to the design team for the last two years. So two years on the engineering team, two years on the design team, four years in total of working on designing systems, and that experience taught me so much about how to compartmentalize my understanding of how to build a cohesive system from both sides. So, back to the question you asked, rookie mistakes. Rookie mistakes are about accessibility and the areas that I kind of fumbled around with quite a bit were about tooltips. I know that's like the simplest area that you can ever think of, but tooltips were so hard. Maybe you should work on this or maybe you should try to, you know, push up or upload a project. See how the teachers, you know, contribute or think about your project? There were so many different aspects of learning how some of our components could also bleed into other areas of our product. So I feel as though splitting them up is awesome. But when there's a chance to graduate or feature a graduated component, please do that. Yeah, I think splitting them up is perfect. But when it's time to graduate the component tree, do that as well. Next one, Alyssa in early-stage, you know that one went. All right, that's Mama, our boss Mama. How do you scale a design system? Best practices, oof. Wow, you're coming to The Heavy Hitters. That one is a bit challenging. I think it depends on what you mean by scaling because sometimes scaling can mean, you know, how can we make sure that the same components that we're using on the design side of things are the same components they're using on the engineering side? That is a bit of scaling. How do we do that? How do we make sure things are compatible to a certain extent? That can be scaling. It depends on what you mean by scaling. But in my perspective, I feel like scaling will really depend on where you are going with your design system and what scaling actually means for you. If it just means building a new feature, if it means how do we make sure that this particular navigation is compatible with all of our products, I think it just depends on what you mean by scaling. So I have to say, I don't know for sure what you mean, but I would say it depends. I know that's a bad answer. Oh, hi.