 design systems. I'm Mayank. And I'm Arnab. And we are designers at Cubol. Now, Cubol is a big data in the Cloud Enterprise Company. So we do a lot of work for some of our biggest customers, including Adobe and Swiggy and Ola, that many of you guys would know about. And as designers, like most of you, like we were sweating about delivering the best quality products. Sweating about every pixel, sweating about all the elements that we were designing. And that's when we realized we needed a superhero, someone to come save us from all these problems that we were having. The other thing where we were still small, but we were growing exponentially. We were hiring people. Our team was growing. We were not geo-located. So we had teams in India and teams in US. So there was a lot of collaboration going on. And so the idea of the superhero was essentially someone who can come in and help us collaborate better and innovate faster. And that was a robust design system. So today, we are going to put you in the shoes of a movie director, because designing a design system is almost like shooting a superhero movie. So get ready for that. And let's start directing our design system. All right, so first thing first, when actually someone gets started with design systems, the person would go over internet. The N number of things about it. And you probably get confused or get overwhelmed about what exactly design system is. And that's what you ask. So what is a design system? There would be N number of quotes written about design system, what exactly it is. There would be N number of perception about design system. So one of these quotes are from Moosley. That's a Moosley publication. Design system is essentially our collection of rules, constraints, and principles where they wanted to tell you that, okay, it's basically these pillars or these functions that needs to be there to build up a design system. But no, that's not exactly what it is, right? It can be anything. Like right now, when you are over internet, basically you know you need it. You know you want it and everyone is building it. So it's like, yeah, even we want to do it. We have a problem, but it's not defined. So right now for you, the hero, or the story around the hero is pretty much mysterious. So that's why we call him a mysterious hero right now, right? All of these that are written over there, a design system can be a visual language, pattern library, brand guideline, you know, voice and tone, design language, and style guide. None of these are like wrong. All of these can be a design system. So here's a great example of how, you know, MailChimp has a design system just about voice and tone. I mean, imagine the whole company has its standardization around voice and tone, like how a marketing guy would come and you know, look at these documentation around how to write a document for external facing stuff or internal facing stuff. The product management team, the engineering team, as well as the product design team, right? They all are looking into this design system for to write things or, you know, writing errors or things like that, right? Yeah, so this is one of the famous material design guidelines, right? Where they have actually written about how you need to go through the UI elements and stuff like that, right? How you get an end to end process of building a UI, right? So that's what they're talking about. If you see both of the, you know, examples, they are actually a design system, but the purpose are totally different, right? Basically you need really, really good bad guys, right? So you need to have or you need to know who are the villains out there for you to solve or the design system that needs to solve those problems. So in our case, there were three villains with us. First was inconsistency. I mean, being a designer or a developer, you have your own mode of doing things, right? You ship some of the other way and there would be inconsistency in terms of small, small things like curves or, you know, how the button looked like in other page and in a different page altogether. So our developers have their own mode. They might even do something out from what you have actually shipped to them, right? The second one is inefficiencies. I mean, these are the conversations that were happening earlier when we didn't have the, you know, design system altogether, right? Where the designers and the developers were actually building the same thing. We didn't want that. I mean, that's like, you know, wasting your cost. I mean, the time that is going through and these kind of inefficiencies we wanted to get rid of, right? So the third one was collaboration. I mean, from the first day itself, the vision of our design system was to actually build up a design language where the developer and the designers are speaking the same language. Even the product managers are using these design system to come up with sketches and stuff like that. So also collaboration, why? Because as Maing said, that our offices are in US and India and the design team has been, you know, divided over there. So we needed a robust system where both the areas of designers need not to think about the pixels again and work upon by just plug-in playing, right? So, yeah, now you have the villains. It's time to characterize your hero. Right, so you know who are the bad guys and these bad guys might be different for each one of you, right? So for us, those were the three main ones. And once we knew the bad guys, it was time to define our superhero's power, right? So our superhero here is called Space. That's what our design system is called. And his main power is to turn mundane tasks into a delight for our customers. And once we had those superhero abilities defined, it was time to find the right producers. And producers are no one but people with budget, people with authority and people with need. Now people with budget and authority are folks like your head of products or your head of engineering, your engineering managers who come and dedicate certain resources to come and work with you on the design side and help this design system into a reality. People with need are essentially people like us, designers, as well as some developers who would be writing code on a day-to-day basis. Now, so it turns out it's really easy to convince people with need, like designers and developers, they're already on board. For people with budget and authority, you need to show them actual data. Because otherwise they'll always be like, hey, why are we working on things that that's not customer facing? We'd ship things and we'd probably take longer time to ship things and this is not gonna work. But this is a great example of what happens when once you introduce a design system. As you can see at the bottom here, once the design system comes in, the number of read writes as well as the files that are written and written by each developer, that goes down drastically. That all means that there's a lot of efficiency that comes in the whole process once you have a design system. That also means that as far as faster to go to market once you introduce a design system. Now, the other part of this is actually a big number. So you can actually calculate the amount of money that you would save a year based on some of those efficiency numbers. So in this particular case, a company with six teams who have 11 deliverables a year could save as close to a half a million dollars a year just by creating a design system. And this particular number is something which you can use to justify the whole project itself because your design system would pay for itself. So now you have your producers on board it. If these don't convince your producers, I think it'll take more time for them to understand what design systems are for. And once you're at that phase, now you need to realize the design systems are ever evolving. You'll start growing the design system and that will lead to decline in inconsistencies and faster go to market. So now you have your producers on board and it's time to actually get started. So how do you get started? We'll put on a pilot show. I mean, it might, you know, what happens is like with pilot shows, you're basically, you know, showing them what exactly a design system would look like and, you know, how the other team members need to envision about design systems. Not just the designers, but also the people who are part of it. So we went on to, you know, redesigning, like this was also the point where we realized, you know, there would be like a couple of components and actually Cuba will need a major redesign at that point of time. So we thought doing a design system is the right time right now. All right, so we went on to, you know, pick up the major pages of the product and went on to redesigning those things, right? So this is the one, which this is the first image that we got out from. So, you know, these are like very, very, like simple design tokens that you can take out from whatever the redesigns that you have done and put it out there, right? Things like, the biggest thing that you can take out of is that the number of hex codes that you have over there, which is like predefined and that's all you need. That's exactly what you need, right? I've seen our code where there were thousands of hex codes which were like really, really random. I mean, why do you need 10 to 20 hex codes just for a shade of gray? So that's what was happening, right? These are the things that we wanted to tackle with. So on the meantime, I was also, you know, experimenting with a couple of iconography that we can do and the illustration style we can pick up. And we just, what we did is just to, you know, paste out in a basic way and just throw them out there. You know what, this is how a design system would evolve. The first things first is actually, you know, when you are doing a project and since the design is on a basis of product management or, you know, engineering, it needs to have a metric to solve, right? You need to hit a metric because it's really important to see if this is actually going to successful or not. So what we did is we sat down with the pillars of product development cycle, right? Who are the pillars over there? So for us, it was product management team, the product design team and the engineering team, right? So you need to have the perspective of all of these, like right from engineering point of view, from the product design point of view to the product management point of view and come up with a metrics. So these are like a couple of metrics that we came up with and these are some common metrics that you can go and hit upon. Obviously you can, you know, go and define a lot of other things, but yeah. So let's see over here, right? Time saved per feature. I mean, imagine your buttons and, you know, the fundamental atoms are already built, right? You do need your, and while you were actually shipping it, you've already done your QA. You don't have to go back and see all of these things that whether these are function properly or not. Eventually what happens is you see a delivery increase at that point of time and obviously these fundamentals are already solved. So you see a lot of bugs reduction. The main point of design system is to also have a coherent experience altogether, right? All the pages, all of the things need to look equal, right? So the usability metrics also improve at that point of time and way better experience comes to the user, the end user. Yeah, so it's, this is the point where you actually start directing things, right? Yeah, so you define your, your criteria as you define your metrics on how you'd measure a design system. So now it's time to actually get your hands dirty, start building the components itself. So how do you get started? Well, the first thing you do is create an interface inventory. So you look into your product, you blow up the product and you break them into small pieces, small pieces that make sense, that together form your entire product. And then you make a list of these items, you make sure that you're also capturing your different states. So for example, for a button, it could be the active state, the disabled state, howers, clicks and so on and so forth. And you start thinking about them. Once you have made your inventory list, you need to start adding some characters, right? So, so these characters, you know, you can derive from a mood voting exercise. Mood voting exercise in our particular case was something that we did to understand what does KubeL stand for and what does the KubeL brand stand for. And so through these mood voting exercises, we picked one of them and derived three main things. Now the three main things were the color palettes. Obviously we did a little bit of it during the pilot phase, but through the mood voting, we actually made some fine changes to that particular palette and started with our primary and secondary colors. The other thing was, so here, so here are the primary and secondary colors. We also defined what our text colors would look like. The next thing was, you know, again fine tune the typography, right? So typography means not just the font family, in our case, which was Helvetica Nu but also font scale, font widths and those kind of things. And so we did all of that and through that, we came to understand what a paragraph would look like and what a header would look like and what a header on a dark contrast would look like. So we defined those and then looked into iconography in our particular case. Our website was a desktop, our product is desktop. So we picked an icon style that is suitable to that. If you are doing a mobile side, your icons would differ. So once you have these characters, you start building up your components. One thing to keep in mind is that your components should talk to each other and not only that, but think about atomic design principles, right? So you start up with the smallest of particles which are called atoms. So in this particular case, you can see your text field is one atom and your search icon is another atom. As you start combining these two together, you form things like molecules, right? So now your search icon and your text field has come together and it has formed a molecule which is your search bar. Then you start combining your molecules together to form organisms. Organisms are essentially a construct where relative tasks come together. So this is a sidebar in our particular case and that's an organism. And when you combine organisms together, you form templates. When you are at this point of stage, you've already defined your page, right? So this is giving you a good indication of what your page would look like. There's also a chance over here to fine tune your organisms and atoms a little bit at this point. So these are like some of the atoms that we have in our design system. So as you can see, we have tabs and we have tabs with icons and so on and so forth. And then we have our organisms which is made up of these basic atoms. One thing to keep in mind while designing the atoms itself, organism itself, it should be replicatable. So it's available. It's something that's used across pages and not just in one page because otherwise you'll end up with a lot of organisms. Right, so that's now you've created a design library, you've created a movie, now it's time to ship it. All right, so yeah, this is the actual time where you and your users are actually interacting with your design system, right? So it needs to be available on a very top-notch way, right? As in, it has to be really, really redefined. It has to be properly defined in a way that everyone can consume it, right? So in our case, the tools were sketched, zeppelin and documentation, that'd be the documentation that we have. Go ahead. So yeah, you can see, this is our sketch library and the purpose of the sketch library at that point of time and from the initial basis, what we thought is these should be pre-configured components or symbols in sketch. So that on a very literal sense, you're actually not playing with the pixels. So indeed, it was never sweating on pixels again, right? So we went on to define it in a very granular level. We tried that, the only thing that the designer needs to do is just to go and configure those things. That's it. That's that level of automations that we were looking for. And another interesting things that we did was, we used zeppelin as a core governance body in the product development lifecycle where the developers actually come here and this is how exactly the governance body looks like because design system is nothing but a governance body at the core of your product building process, right? So what we did is basically give them a pet name, like give them a pet name in terms of the design tokens that we had, like the color palette and the textiles, right? So yeah, I mean, here's a great example, right? Where the developer came over here for a CSS code over there. So what he did is basically just selected that and there's this, you know, the pet name that we have already given. So the purpose of the design system is to have less conversation on these small things. So things like this, this way is basically what we were trying to solve. I mean, then you can see the text was selected and there's this, you know, like font, medium, regular, 14 pixels. That's the variable which is also defined in the code, right? So we use something called a SAS or a CSS processor to compile all of this and create variables in CSS itself. So yeah, and now finally the documentation. I know this is the part where we actually lack upon and don't wanna do it, but that's the heart of the design system, right? Because you don't want to have a lot of conversation around why do you wanna do this, how exactly this is going to implement and stuff like that. So yeah, for us, write as much as possible because if it's not written, it doesn't exist, right? Things like, imagine a developer is coming and asking you what's the reason of having a notification system with that styling and stuff like that. I mean, you don't wanna have a conversation like that. I mean, this is the point of time where we want to innovate, iterate faster for that. We need a design system and you need to write a reason why you do that. So document as much as possible, where to use it, how to use it and stuff like that. And that's what your design system website is made for and one important thing, right? This is the most important thing is because this is the, okay, what's that? This is the only time when you're doing the design system, you're not going back and doing it again. So accessibility, accessibility can be in any way. I mean, there are a number of examples that you can see over internet, but these are one of these, right? Well, there was this one button. You can see that's the darkest shade and what we did is that the color contrast wasn't working fine. So there are a couple of guidelines like WCAG guidelines and stuff like that where you can at least hit double standards for colors and stuff like that, right? Yeah, so that's how our design website looks like and that's how our repo is maintained by our developers. And yeah, I think that's the hero, right? So thank you. And here's the closing notes by Mike. No, so hopefully we were able to give you enough on a high level and how do you go about building a design system?