 Thank you, everybody. Super happy to be here and sharing my whatever knowledge I have about design systems here. This is basically a talk about, first of all, this is no wisdom. This is some of the learning that we had while we were making our design system in Pacto. And what we eventually understood and realized that whatever we were building in terms of components, because we did our own research and built our atomic design structure, that we all know that whoever is building a design system will know about Bradford's atomic structure. But there's a lot more beyond that. And finally, when we kind of completed the entire design system process, we started calling it our design metasystem because it was much beyond a simple set of components or design systems that we typically talk about. So I'm going to just share our thoughts and views on that, that how we came about doing this. So the design metasystem, so let's start with it. There's a lot of buzz in the industry around design systems. We are aware of its beauty, but we are concerned about the consequences. In Pacto, again, the design system was required to be built because we wanted efficiency in the system and we wanted design consistency. This is something which is very common. Everybody of us know that why we want to build a design system, right? So we built our design system, which was called the omega, okay? So, but it was not a one-shot process, just to give you an idea with how we went about crafting our design system. It was around in 2017, we started developing our principles, the product plus design principles. Then we had a project called Project Aurora, okay? The Project Aurora was basically where we were trying to build our UX in terms of, initially we were a very task-oriented UI. We wanted to go to a more platform, a transaction-focused platform so that that entire UI paradigm was changing. So that project, plus the principles, framed a bit of the direction that we wanted to go about building our system. Then in between, we started developing the research around how our design system needs to be built. We went and talked to, spoke to Ola, we spoke to Gojek and several other companies at how they are working on the design system, brought the learnings back and then started around sometime in the later half of, I mean like around November or December, we started building our ATEMs and then we built our components in 2019 early. Then we had our version 2.0 and then 2019 quarter two, we started working on adoption. Now we'll come to all of that, that why adoption is a separate process altogether. But fundamentally, we kind of broke down every step of the design system into, so that the fundamental reason was that Pacto is a company, as an organization, we try to measure everything. And for us, it was very important that we are able to measure the impact of all of this as we go forward so that we can take a decision based on the outcome of that measurement. So that was the fundamental reason why we're doing this. So by doing this, we realize that what we are mostly dealing and discussing about the components of the design system, which is only a part of a larger system that we started calling and I call as design meta system, right? So this is, so our design meta system has basically three layers. We have a central core, which has a rule engine. We have the components and then we have the adoption or the measurement layer. And these together come together to kind of make the design meta system and make it a self-evolving system. So it's very important to understand that where the concept of the design meta system comes from and it actually, it's comes, I mean like some of the core can be understood by this book because this is something that I read long time back. Has anybody read Michael Crickton before? Okay. He's a writer of Jurassic Park, The Lost World, Twister, Congo. I mean most of the science fiction which has been made into a movie. So Westworld, anybody on HBO has watched Westworld. So Westworld is written by Michael Crickton. So Michael Crickton's book, Prey, if you read it, it talks about self-emergence system and emergence is a very standard and a large part of computer science software discipline. So the fundamental thought around our design meta system is that it has to be a self-evolving emergent system, right? And that's what we're gonna talk about. So if you look at it, so we have to first understand the concept of a self-evolving system. So you guys look at these birds, okay and we have all seen these birds fly in this shape. Now do you know that why the birds fly in this shape? I mean how do they decide to fly in this shape? Is there a bird which kind of knows that where it has to fly? But before we come to that, let's understand that why they fly in this shape. They fly in this shape because this optimizes the energy using the advantage of aerodynamics of the bird ahead. Because they fly in this shape, the aerodynamics, they're able to use the wind draft of the bird in front of it and as a result end up using lesser energy and they are able to migrate further and probably this is the way for the nature to kind of evolve and survive. So fundamentally the success matrix of this is survival, right? Now the point is the interesting part of this entire, the structure of this, the formation is that knows bird knows that they have to fly in this formation. So the interesting part is that this is not achieved by a plan but by following simple rules. Rules that are genetically coded in the system like being able to sense the aerodynamics. So the birds know something like I have to keep this much distance from the next bird based on the wind draft that I'm getting and maybe at this angle. And that's how the shape evolves. There is no single bird which is the leader of this pack. There is no single bird which knows that I have to be on the third or fourth position. This shape evolves when the birds take flight together and they just follow those simple rules. So this is the fundamental concept of an emergent and a self-evolving system. Has anybody ever seen a Converse Game of Life? So that's out of the topic here but in case you guys are interested because that kind of demonstrates a self-evolving system because this is from Converse Game of Life, it's a grid structure and each grid part is basically treated like a cell and the black ones are the living cell and which is not filled is a dead cell. So go and read about it. The interesting part is that these structures are evolving out of only four or five basic rules of life and death of those cells and people have demonstrated that extremely complex behavior could evolve out of these systems, right? Now, so fundamentally what I'm trying to put forward here is that design systems need to be an emergent system. They need to have, so what are the fundamentals of basics of an emergent system? It needs to be a continuously evolving system, right? It has to continuously evolve because if you look at it, these are generations. So in a Game of Life, there are generations that run and as a result, a system or an organism evolves, right? A decentralized system evolved from the fundamental and basic rules, okay? So there are certain basic rules which have no correlation to the whatever the larger system that evolves out of it but the system evolves out of that, those basic rules. A system with a known measure of success, of course, there has to be measurement because unless you measure it, it cannot feed back into the system and a system that can be measured and evaluated against the success metrics, right? So these are the fundamental requirement of an emergent design system. Now, this is what the design system in our case looks like, okay, so we typically talk about the component library which is the second part, second layer of the design system. The first layer are those rules, right? Those rules which are going to make and build a component and ideally in some time in future, probably if we work enough hard enough on the rules, the components will evolve automatically, right? And then we have adoption which is basically the process of measuring the success of the design system and then evolving the design system by that process, right? So I will just take you through each of these step-by-step that how did we do it and the important parts of the rules and the adoption part will go slightly deeper there. We haven't cracked everything out there but we have cracked part of it and that's what I'm gonna share here, right? So some of the rules we typically know of like the brand guidelines, right? The color, typography, illustrations, images, these are something given to us by the brand and we kind of use it. Of course, there's a lot of research that goes back in deciding that what font and why it should be used and stuff like those. These are some of those fundamental rules but we have also design principles. We had our design principles that we built to kind of come to some of those rules but fundamentally I would like to talk about this one particular rule which is typographic density and contrast, okay? So to give you an understanding of what a typographic density and contrast means, let's look at this. This is Airbnb, this is Zomato, this is Amazon, right? And they have separate typographic density and contrast. This is, so first of all, what is a typographic density means? Density, typographic density means the baseline, the base font size that you're gonna use for all your content. Mostly it is for mobile either 12, 14, 16, right? Now, somebody like Airbnb would use a 16 font size because that's where the readability comes from. And also, something that adds to it is the line height, right? Combination of these two will give you the density. So if you look at it, this is more dense, okay? This has much more spacing if you look at it overall. I mean like even between these at, so what is the ratio? It's 1.5 versus 1.8 or 1.6 and even the variation of that ratio can lead to a very different style or usage of the product. Why this matters? Because a lot depends upon how much content you are showing in a consumer-facing app, right? And if you look at it, these guys, they show less content, but they're okay with it. Why? Because they have a better brand, their brand is a larger brand. So people are going to spend time not because they want to do something immediately but because they are on Airbnb for some reason and they're gonna stay there. They're gonna scroll and see all the content against maybe, you know, Zomato, which is trying to say that all of this here and you know like everything is on the first screen. So this has a very deep correlation to the state of the business and that's why this is very important. So this is high density, this is medium density and this is low density. But let's look at the contrast. This is very high contrast. With contrast, what I mean is that the lowest font size and the highest font size, the ratio between that. So this is a very high contrast and if you see there is very hardly any difference between the contrast of this interface. In this, it's a medium contrast. So what we did was that we kind of made a dispersion of density contrast of all the, some of the apps that we could see. So if you see everything here, Flipboard, Nike, Apple, these are like, this is a quadrant where most of the premium looking apps are there and they can be here because Apple doesn't try to achieve transaction or conversion on their app all the time. They get people on their app via marketing and via building the brand, right? So most of these organizations here will be using that as a lever to kind of bring people. So they don't need to show too much of content but most of the other places like Intra, Swiggy, Amazon, Zomato, you have a lot of content and you need to be somewhere here. But if you look at some of the other ones like Craigslist, Cora, they have like very dense GitHub, very dense, very low contrast because they have too much of content and it goes up here, which is very functional. This is premium. This is somewhere which is a hygiene plus premium, right? Zomato, if you see that Zomato has a very quick cycle of iterating on the density contrast and they keep redesigning their app, they keep moving here continuously, depending upon what is the state of the business. So after looking at it, we decided where we wanted to be and that's how we came to practice density and contrast and that's how we designed our interface. So it is somewhere in between, you can see, right? So fundamentally what I'm trying to put forward here is that all design decisions, now previously these kind of decisions were taken by designers on gut instinct. I created this and I think this is good. Okay, either as a head of design or the lead designer who is building it, he feels which is actually right because the gut might be right, but there is a reason behind it and this kind of helps us to bring that on the table for the larger management and the developers and why did we select a 14 by 20 density and 14 by 24 contrast. So those measurements help, those measurements give us a lot of confidence on the design decisions that we take, right? So after this, so the fundamental idea is that the rules must be connected to the state of the business, right? So if tomorrow my company decides to spend more on advertising and brand building, I will pull my levers of density and contrast and change it from being somewhere in between to somewhere more premium. So I will take it, I will make it move along this metric somewhere depending upon where the business stands for, right? So this is about the rules. This is one of the rules we had a lot of rules which we kind of deconstructed and kind of built on those and that kind of gave rise to our components. The components were built on the concept of the atomic design structure. We had the atoms, we had the molecules, we had the components. Okay, we built the anatomy of each button and then we had the dimensions of them, like how much padding and stuff that will go into it. The states of each component, they are checks on the background because we had a blue as one of our brand and we kind of built on that. And usage, right? Iconography, looking at the tools and fixing them, we had some of the previous icons had a lot of flaws in terms of spacing and everything. We kind of removed all those flaws and then finally creating the rhythm by space system which is something connected to the density and typography that we're talking about, right? And by this we kind of created almost 210 components. Now that's a huge set of components but that was primarily because Pacto already had multiple businesses which were having their own separate set of components. And the idea was not to just come up with a design system and say that, hey, why don't we use this? We wanted to kind of inculcate and bring in the design, the components from each business units and the pods that we're working on. We assimilated them and the idea was that once you start measuring them, you can start optimizing it. But we first start with having everything, include everything as inclusive as possible, right? This is some of the screens and the app screen and the web screen that we kind of designed out of those components that we built. The second most important part is the process adoption measurement. So the process adoption and measurement because again, like I said, we have a culture of measuring everything. So even for us, the important part was that whether the design system is successful or not. And we have to figure it out, right? So there are two paradoxes to it. One was the process and the second was the framework. That what is the design process that allows the integration of the design system because if we don't follow a process of, because the process is going to give us a checkpoints where the design system is getting used so that I can measure on those checkpoints. Unless and until I have those checkpoints, I don't know where to measure. So the process was very important. The second part was the framework that allows for the measurement of the usage of the design system. That how are we going to define the usage, right? So again, these are like all very developmental concepts and theories because we had to work with the business to kind of understand that what can we build around this? The one thing that we did was that we set up an OKR around design system that, and since like I said that we had a legacy, usage of system. So we did not start by having the engineering start building them immediately. The idea was that let's first measure that how much of the design team is using it because we already had the design team using different components and we have brought it all in within the design system. But the idea was to measure that how much of these individual designers are using the design system, right? And then to take it to 90% because when it reaches 90% of adoption, then we can clearly say that this design system is at least successful with the designers so that now the engineering, we had the confidence for the engineering to start building on it, right? So for the process, we had to, I mean the tool was very important. The abstract, I mean we used abstract for this and some of the benefits of abstract was that it gave direct link to the design system library, right? It's kind of built to help you do that. We have other ones like DSM of InVision and some of the other tools. Somehow abstract worked out financially and from whatever we were doing, right? The whole design process can now run on abstract. The process of design could now run on abstract which kind of helped us to have those checkpoints to measure. The design review steps allow us to have a central review system, right? And allowing versioning and archiving of all design for. This was more tactical, not related to design system, but because of also this, we got abstract on board head. So if you look at the process, I mean obviously everybody had a spend process in the organization, so we had our spend process and these were the three checkpoints which we found. So this is where the backlog grooming happens, okay? And this is where the pre-handover happens and this is where the handover happens of design. Now, whenever the backlog grooming is happening and the design project is decided, it has to initiate on abstract. So we measured the initiation, we measured the review on this and we also measured the handover. If all the steps are happening on this, then we say that design system process adoption is 100%. Sometimes designers fall through this. The idea is that this should not take much time because ideally everybody should follow this process but since we were migrating from one to another, we even measured this, this entire transition. We had naming convention of course to kind of help them with a very specific naming convention and then we used runner to kind of, this is just to help you guys to understand that what are the various tools that goes into helping build the design system because without those associated tooling, it will be very difficult for the designers to kind of use the design system, right? We were using sketch. So now coming to the measuring of the adoption of design system abstract plus sketch, right? So this was a combination that we had to use. Not just to give an example that how adoption can be measured. So the adoption, so this is, let's say this is a project which is, so what we did was that we did sampling. So after a month, we would take four or five large projects which has full screens, let's say two or three big screens. And then we would see that when the designer has designed how many of those components are from the component library versus some of those independent floating items or something that he has to build for that particular project. So this ratio of this green versus green plus red gives you the adoption ratio, right? And this gives an idea that where we stand in terms of usage of this, the components. So this was a hacky way, but the interesting part is, there's a lot of work going on. So one of our, there's a lot of work going in this area where people are trying to automate it. And to be honest, the tools today we have don't really help us to measure because even if you look at Adobe XT or Sketch or because this measurement can be very well built within the Sketch, right? When you're using it. And in fact, one of our ex-Practo designer who is also a brilliant developer, he actually built one tool called Lint, which is now being used by Google and a couple of other large organizations abroad. It kind of gives you, throws you back that how, you know, like if you have used this, this is the right component to be used and it connects back to that component and tries to help you to, you know, identify the right component that you should be using instead of that. And what he's right now working on is a fuzzy logic system on which he can build. So the idea is that because if you guys are using Sketch, you would know that a lot of time we kind of disconnect the symbol, detach the symbol from the symbol library and then modify it. The idea is that even if you modify it, it's going to get caught in the development cycle because the developers are going to say that we have this component, you have modified it. But even if you modify it, you can use fuzzy logic to understand or a little bit of AIML to kind of figure out that whether this is the same component or not. So they are trying to build a system where you are able to understand that this is the same component and give you some recommendation that you can improve it. You can use the same one and give you a measurement also that you have used this much of component versus what, right? So this is how kind of, this is a development in a space and we kind of worked with him very closely to understand if we can build it for us. We haven't done that yet, but we have the process of doing it, right? Integration with the tech, like I said, that it's very, very critical because at the other end, we had the storybook version of all the components, which is what we are building right now as a second stage of the process where the developers keep all the components and they are visible and there's a hell lot of documentation that goes on to that to kind of figure out all the various states of it, right? So this is fundamentally the system that we use in Pacto. So we have an abstract version. We have a storybook version. We have UIM production and this is a design sprint, right? And there's a review that happens between this and this, which is the Omega adoption rate, right? And then in the process of evolving, there's the Omega release cycle, which kind of goes and updates the storybook version. Then there's a parity scan. This is a very difficult stuff to do, but actually it's possible. We have not done it yet, but this is something on the pipeline. It's that understanding that how much of that design system which we see on storybook is on production, right? And again, of course, this design handover kind of completing the circles, right? This is basically that we learned from the UI production that which of the components are actually working fine. Are they successful? So PayPal and stuff like those, they do this a lot. They actually check the success of each component against their business metrics, right?