Transcript from the "Common Mistakes" Lesson
>> Let's examine some common mistakes, these are mistakes that I've made personally. So this is learn from my mistakes, the first is starting for scale. So while scaling, the ability to scale is really good if you start out trying to code and design for every possible situation, you're just gonna get really overwhelmed.
[00:00:19] And I did this at my current company because we've got a lot of products, and a lot of end-points like iOS, Android, and we started building for scale and we got very overwhelmed very quickly. So only scale when you need to. I also made this mistake which is educating before you build, engineers and designers get really excited when you show them a toolkit that they can use to quickly prototype or quickly build UIs.
[00:00:46] But if there's nothing for them to use today, this is all just theory, they're not gonna be happy with you, and I can actually kind of act negatively impact your relationship with them. So have something to discuss before you educate on the system you're building. When you're working with other people, especially if you're working across different time zones or remotely discussing workflows big, how do you want to handle new component requests?
[00:01:10] How do you want to actually collaborate? Do you wanna have weekly meetings, bi-weekly meetings, common terms on these things before you start, it's gonna save you a lot of time. And the last is not documenting decisions. Again, I made this problem where we would make decisions and we wouldn't document it and either we would forget why we made that decision and we couldn't back it up when we were asked.
[00:01:31] Or we spent a lot of time communicating these decisions to individual stakeholders who would come and ask. So having is documented, having your priorities documented is very important, it'll save you a lot of time. Okay, that is a very high level introduction to design systems, so are there any questions before we jump into design?
>> I have a question.
>> You were talking about a checklist of the unsigned system, right? Do you have a priority list of like, say more first or accessibility first? And like that kind of puts the theme when you're deciding system basically.
>> Like kind of what's the most important things that has to have?
[00:02:20] This is gonna be individual to your team, it's gonna depend. So for us, our initiative right now is accessibility, if our components are not usable, we can't ship them, but maybe browser compatibility can be lower on the totem pole. So I would talk with your team and kind of figure out what's your biggest priority in terms of have to haves, and what are just kinda like nice to have, features for your components.