 is how to pronounce my name. So obviously, that's how I pronounce my name. I'm a senior UX engineer at MailChimp, where I'm building a design system for millions of users. Just kind of curious, how many of you have heard of MailChimp or use MailChimp and whatnot? Oh, so quite a few. Sweet. So I'm going to actually start this talk with a story about my first experience building a design system. I was working in a big corporation where there was at least hundreds of designers and many different engineers. And we didn't have a design system. So what we wanted to do is that we wanted to create a design system not only for us, but also for the rest of the organization. So we dedicated a couple of people. And within a couple of months, we had a design system. But there was a problem. This design system was hard to use. And what happened was that a lot of people were frustrated with using it overall. This design system was a failure. And it was very hard to pinpoint why it was a failure, because we kind of did our research and figured out what we needed for it. But one day, I was watching one of my favorite shows, which was called The Prophet. Has anyone watched this show before or whatnot? Oh, nobody. That's interesting. But the whole idea is that the host, Lamarcus Moniz, goes around saving struggling businesses. He's an expert businessman. And he uses the formula of a three piece to kind of help them be profitable. So I was kind of thinking that this formula can actually be used for a design system. And I'm going to kind of talk to you about how the three piece can help you create a design system that's more successful and help your teams be able to build scalable products. So the first piece is the people. The people are the foundation of what we do. We are creating products to solve people's needs and problems. And if you kind of break that down, you get to a point where it's like two people where you have producers and consumers. The great thing about it is that we all are producers, because obviously we create products for a living. We also consume products daily, too. And if you're thinking in context of a design system, so we have a design system that serves the direct users, which is our colleagues. And they build features for our end users that are actually using the product overall. So let's take a deeper look into the direct users. So as you can see, we have designers, engineers, content chargers, data scientists, and QA. And this is just like a small subset group of it. It could be many, many more. But the problem is that if you're building a design system from the ground up, it's very hard to kind of build one for everyone. So I kind of came up with this concept where you design for the primary, support the secondary, and then you accommodate the rest. And the reason why I say this is because you need to kind of prioritize who's going to use this design system and focus on them first and then making sure that everyone else can kind of be supported or accommodated. So if you think about it, I put them in a subgroup like this. So we have the primary users, which is engineers and designers. These are the people that are going to be leveraging the system often. And then we have the others, which is customer success, which is also salespeople and finance. Depending on your organization, this is going to vary. But we still have a problem. We still have the engineers and the designer. And the question might be, which experience is most important? The designer or developer experience? So when I was kind of doing research for this, I started as a designer, but I realized that the developer experience is super important. And the reason why I say this is because they're the ones that are actually executing the UI itself. As designers, we can kind of plan and kind of think about what is the concept and the ideas of the UI, but we actually don't really execute the UI. That's why we need the engineers to help. Another thing is that they also execute the interaction design. Again, we are product designers. We are actually creating the plans for the interaction design itself. But we need the help of the engineers and making sure that they're creating something that's useful for everyone. And finally, they are in charge of the performance accessibility. This is super important because the wider and the more users you have for your product, the more important it is that performance and accessibility plays. And really thinking about this, I kind of thought that at the end of the day, a design system doesn't really exist until it's in code. The reason why I say this is because I have often heard other designers talk about how their design system is a PDF, or a design system is a Sketch library or a Figma library. But the problem is that no one can really use it unless they're designers. When it's an actual code, people can actually kind of pull on it and use it day to day. So we talked about which kind of group of people we want to focus on. We have to figure out what are their needs? How can we figure out their needs and their problems? The best way to do this is with research. And what we do this is with quantitative research. So I had a case where I was working on a design system, and we wanted to figure out how we can kind of help people in other parts of the organization. So what we did was basically send out a survey asking people what their needs are, what their goals are, and if they have any ideas of what would be helpful for them in the future. This was super useful because we were able to kind of validate some of the ideas we had. Some ideas worked, some ideas that people wanted to use, but some of them weren't. And then we kind of took another step where we went to qualitative research. So based on the group we kind of sent the survey out to, we wanted to kind of internet it. So we asked a bunch of questions, figuring out like, hey, how did the design system can help them and whatnot? Some of the key questions we asked was what are some of the major pain points in the design process? So the whole idea is that if there are pain points in the design process overall, the design system should be there to kind of help them. Another one is how can the design system make your job easier? We're trying to figure out if there's specific things that people really need and understand if there's a way that the design system can kind of help them with that. And finally, what are some of the future goals? Again, a design system is solving today's problems, but you want to make sure it's scalable for tomorrow's problems too. So after doing this for a while and kind of doing a lot of research, there are a couple of things I kind of found out when I was kind of talking to people and whatnot. The first thing was that it was super important to have a clear and concise pattern documentation. People always want to know how to use a pattern, where to use a pattern, and what cases. Another one is making sure that there is a seamless integration into the design and development process. So if I'm a designer and I want to kind of create an actual feature, I want to be able to leverage the design system as quickly as possible. This is the same thing with engineers. If I'm building a feature, I want to be able to kind of use the system without actually taking so much time to kind of set it up. Next, there has to be a way you kind of communicate design system updates and new features. While I was doing a lot of my research, I kind of show people some of the features that were in the design system. And there are some things that people were unaware of. And this wasn't their fault. This was our fault, especially within my team, where I work as part of a design system team. And our job is making sure that people are aware of all the things we're kind of doing. And one way we could do this is basically sending out a monthly newsletter and sharing what is new. This was a great way to kind of communicate the changes overall. And next, we're talking about testing and validating components before release. One of the things that often happened when I was talking to people was that sometimes they will use a component or a pattern, and it didn't work that it's supposed to do. And this happens both for designers and engineers. So if you're trying to create a design system, you want to make sure that you test and validate your components before it gets released. I'll be talking more about this in the future. So there's this great article about the people part of the design system. Regretta Moon kind of talked about saying, we realized that also for our system to succeed long term, it needed to be thought as everyone's responsibility. And the idea where I was seeing that the responsibility, when people feel like they're responsible for something, they're more likely to put an effort in making sure that the system will be successful. So we talked about the people. Next up, we want to talk about the process. A great process will allow people to work more efficiently and effectively. So what makes a great process? So for me, it has to be predictable, flexible, and seamless. And I like to keep it simple because it's so easy to overcomplicate the process overall, but let's say you're starting a new design system and you want to know where you start. Where does the process start? This process starts with a pattern audit. So in my last job, I started in design system from the ground up, and one of the things I did was literally take screenshots of every screen in the product and put them on a long wall. And there was two reasons why I did this. I want to kind of get a holistic view of all the actual UI elements in the product itself. And it was a great way to kind of communicate to my colleagues about what I'm doing. I was able to kind of have them kind of take the post notes and write and figure out like have questions. And this was a great way to kind of collaborate them. Once I was kind of done with this, there was a lot of things where I was able to kind of prioritize what I should be focusing on. And once that happened, I was able to kind of create a project roadmap. This is super important because you want to make sure your process is as transparent as possible and easy to follow. So when I was creating tickets, I do something like this. I don't know if anyone used to GitHub, but I used GitHub to kind of manage my tickets and issues and it makes it where the issues is kind of linked to the actual code itself. And as you can see here, there's like a system for everything. So if you kind of look down here, we have those brackets where we kind of communicate like what is this ticket for? Is it for a button? Is it for documentation and whatnot? And then we have like a small description for it. And what's super important is that I tack each of these features and this is super important because let's say if I'm working on a design system by myself and someone wants to pitch in, there is a actual roadmap that they can kind of follow. So if there's a bunch of design issues and a designer has some time to kind of work on something, they can literally go in here and pick up an issue and start working on it and then compete it and kind of move it along the actual Kanban board. But one thing I want to kind of say is that the process will be rough at first. People are not really used to change and especially with a design system, it's hard to get used to. And you have to be in the right mindset for it. So I always like to communicate that you wanna start with small steps and then these small steps are gonna lead to great distances. So one example of this is that when I was working, when I was kind of building a design system, when I was like the only person working on the design system rather than building all the components at once and kind of asking people to kind of import it into the actual product, I start very small. So I started with the smallest component I could do, which is the button. So I created a button component and then what we did is like I worked with the front end engineer to kind of replace it. All the instances with the design system button within the product. After that, we started with the badge and after that we started with other bigger elements and whatnot. This allowed us to kind of build up momentum and not get too overwhelmed. Another thing we wanted to think about was like how can we incorporate new patterns into a design system? This is probably one of the hardest things to do because depending on the organization and how the people work, your process is going to vary. But one way to kind of do this is literally with a new pattern process that I kind of kind of do where I start with the proposal. So what is this pattern? What does it do? Then I get into the production phase, which I'm getting to actually building the component. And then after that, most important documentation. So I'm gonna get into these right now. So we have the proposal. Usually a proposal starts with this. It starts with the pattern name. This is super important because a design system is also a design language for your organization. So names are very important. So you wanna make sure your name is very descriptive and straight to the point. Next, you wanna talk about the purpose. What is the purpose of this pattern? Why is it needed? And then next, you wanna talk about where we use this pattern. And I like to ask this question because oftentimes people will wanna build a pattern that's specifically for one specific view. But the idea is that a design system, the pattern should be able to be used in multiple different views and workflows. So now let's get into production. So this is where we actually build in that component itself. And like I said, there's many ways to kind of start the actual production phase of the actual pattern. So one way I like to do is start with interaction flow spec. So this is the way where I can see the different states of actual pattern itself. So as you can see here, I have, this is full spec specifically for a dropdown component. So I have a default, I have the active and I have the clip. And what I wanna kind of communicate and kind of kind of demonstrate is like the actual life cycle of the component itself. And I'm kind of using, it's kind of hard to see but there's colors here. So I'm using like dark blue to kind of demonstrate what are clickable items. And then I have this light blue, which is demonstrating the hover states. And then these things are orange. It's kind of hard to see. But these are kind of showing, demonstrating like what is motion. So what are things that are gonna be moving and having some animation? And then from there, we could dive in deeper into the actual anatomy of the dropdown component. And this is super important because you wanna kind of be able to list out what are the specific states and the action of each of these elements within the pattern itself. The idea for this is that we wanna make sure that we are aware of like all these micro interactions before we start actually building and designing the actual pattern itself. And this is a great step to leave off of because let's say you're working with an engineer. What you can literally do is that the designer could work on the more visual aspects of this like thinking about the colors and typography and whatnot. And the engineers could focus on creating a component API which looks something like this. So the whole idea is that once the interaction spec is done and the pattern anatomy is done, the engineer can kind of quickly build the component alongside with the designer. So there's no real handoff, but more of like a handshake process. So once this is done, what you wanna do is just kind of focus on other stuff like accessibility. And one way to kind of do that is have accessibility checklists for your component itself. So this is a checklist that I usually follow. So if it's an interactive component, I wanna make sure that we're really focusing on like is this key, be able to navigate the actual component with a keyboard. You have to think about color contrast because if you're working on a product and it has multiple themes like a dark theme, light theme, you have to make sure that we plan for that. Another thing is if you're using images, you have to make sure you include all text and making sure that if I'm using the product with screen reader that I'll be able to use it overall. And the same thing with having semantic elements and roles, this plays a role when you wanna create a product that's more accessible for people that have some disability visually. So I actually use this site called the A11 project to be able to kind of create a checklist, but I would recommend y'all kind of explore this because it's very well detailed and I think it's a very useful resource if you're kind of building patterns overall and making sure that whatever you're doing is very accessible. And they kind of do all the work for you. So all you have to do is kind of follow them because sometimes for me I'm kind of lazy so I don't wanna actually do all the research but definitely check this out. Next up you wanna focus on QA. So it's important that you QA your patterns often and this is kind of the checklist I usually follow. So this is mostly for if you're building a web product but I wanna make sure the pattern is able to kind of work in different browsers. So we have Chrome, Firefox, Safari, might have to support Edge and whatnot but that's the first thing I would think about and then thinking about the operating system. You wanna be able to test this component out in Windows, Macs, Android, iOS and then also think about responsiveness because not only are people using your product in desktop and mobile but in some cases they're using it on TVs and fridges and whatnot. So next is documentation. Documentation is super important because this is the only way people gonna know how to actually use the component itself and why. So this is kind of like a structure I kinda come up with. So it starts with the purpose. Why are we using this component overall? And then it gets to the variance. So if you have a component that has different types and structures and whatnot, you wanna be able to kind of demonstrate that within the documentation. And then last you wanna talk about having like a live sample to kind of see like the component in real life and then co-snip it for your engineers. The idea is that they're able to kind of copy the code and use it into their application right away. So this is an example I created. So it kind of follows the same format where you have the badge, the title of it, then you have like the purpose. Why do we have to use the badge overall? And I get into the variance because what you wanna kind of do is kind of be able to communicate when we use one variant of the other. This is super important. And if you go down the page, you have this kind of playground area. So if I'm an engineer, I could literally just kind of play around and kind of see which are the different types and copy this code and literally use it in the application. So it makes the process very seamless. And there was this article by Unicravus about why design system fails. And she had this great quote saying, despite how much control the other engineers have on the process, they need to feel like they have input and feel heard. This is super important because I feel like as a designers, our job is to make everyone's lives easier and making sure that if engineers haven't any ideas that we listen to them and making sure that if they want to actually work on something that they feel empowered to. So we talk about the people, we talk about the process, but we talk about next, which is the product. So if you kind of have a good process and you got people that's working on it, you should come up with three products. The first product will be UIKit. So this example is coming from the carbon design system of IBM's. And this UIKit is built in Figma and it's kind of demonstrating all the different states and the sizing and whatnot for a button component. And if you kind of take it a bit deeper, we have the actual pattern library, which this is the code example built in HTML, CSS, and this is what most of the time the engineers are gonna actually utilize. And finally, we talk about documentation. Documentation is super important because the better your documentation, the more likely your design system is gonna be successful. You have to make sure that you're working with content strategists, making sure that it's easy to kind of navigate the documentation and figure out how to write the content and whatnot. So I talked about three P's, which is people, process, and product. But there is another P, a bonus one, which is prototyping, specifically friend and prototyping. So a couple years back, I used to work at NASDAQ, which is the stock exchange located in New York. And we were building a lot of products that were very data heavy. So instead of working in static form, we kind of decided to build our prototypes and our main deliverables is actual code itself. And the main reason why we did this is that, one, it allowed us to design the real experience of the application. So we weren't really focusing on the static views, but making sure that we are thinking about how it looks like day to day in the real experience itself. Another thing that allowed us to do was that it was basically one massive deliverable. So instead of everyone working on their own sketch libraries or whatever like that, we were able to kind of work kind of like engineers, which looks something like this. So if you have working with multiple tracks or squads or whatnot, everyone has access to the actual features itself. Because most often not, a workflow will include many different features from different parts of the site. Another great thing is that we were able to utilize real data. And there's a saying that in order for us to be building the best experience possible, we had to use the same data that our users are consuming daily. This was super important, especially for a data heavy site, because often what happens is that the data will actually bake their experience itself, and we want to kind of bubble up that edge case early as possible. And the one thing I wanted to kind of communicate is that doing front end prototypes allowed us to move away from the idea of like pixel perfection. Because the idea is that your product is never going to be perfect, and you want to make sure that the user experience is for fun. And what else front end prototype allowed us to do was that allow us to focus on building the right thing instead of building the thing right. So instead of thinking about, hey, we have to make sure that the spacing is right and whatnot, we want to think about the holistic experience. Is this experience solving the problem for the user itself? So if you want to learn more about this, I have an article actually about this on Heart Internet, talking about front end prototypes that were great experiences. So if you want to kind of learn more about how to do front end prototypes, definitely check this out. So I know I kind of talked a lot, but I want to kind of leave you out with three things. The first thing is that I think you first should understand the goals of the people. The reason why two design systems are never the same is because it's depending on how people work. So really understanding their problems and goals will allow you to create a design system that is not only going to be useful, but also well-adopted. Second, you want to create a process that empowers the people. You want to give them enough process that people can get started, can contribute to the actual design system overall, but not too much process that hinders the process overall. And finally, you want to have a product that provides value to your company. The design system is a product. And if you view it as a product, you have to make sure that it solves the goals and the needs of the people. And once you start thinking like this, you're gonna actually see the value of it and also be able to kind of communicate that not only to your team, but the executives. And once you start seeing the value itself, they start to kind of invest more into it and you could have a well-defined design system. That's pretty much it. Thank you.