 I'll get started. I think you'd not tell you anything about me anymore. I think the slide is up there. My name is Anubhav. I'm from Srijan, now acquired by a material plus company recently, last week, basically. I'm a product manager. So my role, basically, is involved throughout the lifecycle of development of a product. So I'm involved from requirement gathering, and probably with the product is all I can say. These are my Twitter handles and LinkedIn handle. So just in case you want to reach out to me after the session, you can use this as well. And just to disclaimer, I just have 20 minutes. The topic was very vast. It was a very technical project where we worked on. Just in case if you need any technical questions to be answered, again, I can have it answered over an email or any other social media platform. But the topic that I'm covering here is about developing a versatile design system for enterprises. What is there which goes into planning of development of design system? How do we actually execute a design system? So starting from the beginning till the end, I'll try to cover every aspect of the project. But why this topic is the question that comes to the mind of everyone. Why design system needs to be developed? I'd just like to give you an interesting stat. Again, the agenda goes like this just to quickly tell you. I'll just brief you a little about what is design system. I'll tell you about the project which I was working on, what we did, how we did, tools and technologies that we used, and what are the business benefits that we are trying to reap from this. But again, coming to why design system? Just, I mean, this slide talks on its own. Software is eating the world, we all know, while design is eating the software. If design is not there in place, I mean, software is not good enough. So this speaks volumes on its own. But again, are there any stats to prove what I'm saying is correct or not? So these are the recent stats, basically last week's stats. Top four companies in the top 10 by market value are basically software companies. They're deriving their revenue from this software stream. Apple, Amazon, Microsoft, Google, all software companies and they're deriving their revenues from the software industry. And see how what Tecran set out design. You see six major tech companies have doubled their design, hiring goals last half-ticket. This last half-ticket basically is from 2012 to 2017. You see, per developer at Laskin had 25 developers, had only one designer. Now, then in 2017, there are nine developers per designer. Likewise, if you see Dropbox, they had 10 developers per designer, now they have six. You see the shift, the trend of having more designers in the organization. There is certainly something which is very important that industry needs to adopt. Industry needs to change. And the change is happening. But when I talk about design system, what exactly does that mean? What is the definition? So I've carved out my own definition from different places, my experience, and this is how it looks like. The design system is a collection of design components, atoms, molecules, and organisms. I'll tell you what does this mean quickly. And a systematic approach to product development with guidelines, processes, and code that defines how these components should work together seamlessly, right? The standards cover guidelines for each component, typography standards, and content writing rules. Basically, so it covers everything, your design, your rules, your standards. When everything comes together, it is called a design system. So a few examples of design system. Google has their design system, it has their design system, IBM has their design system. There's a reason behind it again, right? But when I try to basically give you a visual definition of this design system, this is how it comes out, right? It consists of building blocks, pattern library, and rules. Building blocks basically where your smaller elements fit in, color palliates, typographic grid definitions, icons, pattern libraries include templates, modules, components elements, rules include design rules, implementation guidelines, and editorial guides. So together, this whole system that we're talking about, right, is called design system. And it is based, this whole design system is based on a principle which is called design principle. And this is how it shapes up, right? The building block is atom. When atoms meet, they make molecules. When molecules meet, they make organism. And when organism meet, they make templates. And when templates meet, they make web pages. So this is the flow of a design system. And why do we need it? Why can't we just have designers developing websites? Why can't we have designers just developing applications? What is the need of talking about design systems? Again, this is the reason. Without a design system, software development processes become slower with time and the user experience suffers from growing inconsistencies. You start with design system. There is a team which works with its own style, with their own patterns. One year down the line, there is another team. They start working on the same website. They have their own style, their own patterns. And what we actually try to get, what we actually get eventually is an inconsistent product, right? The buttons on one page is different from the button at a different page. Or it might be a case that one website of an organization has a different type of button, but the different website of the same company has a different button. So that's the problem that we face most of the time. Coming to the project that we've worked on, right? Now this basically defines what a design system is. The project basically, our client was a global welfare organization, tasked with helping countries eliminate poverty, I think. Pretty obvious by now that you know what the client is, and achieve sustainable economic growth and human development. It is headquartered in New York, largest aid agencies in the world, operating in 170 countries. Shrejan helped them, basically, develop 200 plus websites, right? So they have a website in each country, and basically multiple websites in each country. And the task was to basically build a custom design system so that every website looks similar, right? So if I can define what the complete project was, I will now go into the detail of the project. But it was a very big project, and design system was just a part of it. So platform building on Drupal was part of the project. Migration of all the older sites from AEM to Drupal was second part of the project. We had a plan, but if you see in the red, integration of the design system into the Drupal platform was what I'm talking about. What was the ask, right? They wanted an extensible and scalable design system, relaunching global sites in multiple languages. They wanted India to have two languages, US to have Spanish, French, and English. So multilingual capability. They wanted to increase the overall user experience, the front-end, as well as their tutorial experience. They wanted to build everything with a modular approach so that the reusability is high, and they did not want any kind of problems because of RTL or LTR languages, right? So all this was the ask. But what were the challenges before we got started? Define it, so we had to define a consistent visual identity. There was no visual identity, and we wanted to replicate the same look across all the sites, avoid additional cost, right, by developing reusable components. So these were the challenges that were told to us. What we did? We built a Drupal platform, which consists of basically 200 plus, I mean, you can spin off 200 plus website from this platform. There was a technology build, and we were able to do that successfully. The design system solution has detailed documentation of visual design elements within the platform, components, and updates for developers to use, right? And this is a snapshot of how the design system eventually came out. If you see on the left-hand side, there is getting started documentation. We have icons, images, layout, all this hierarchy, and if you see there, you will be able to see this is how the design of a paragraph will come like, or the detailed page will come like. We have actions, control, HTML, how will RTL look like, what are the accessibility things, which we can see there. We have documentation. All these, first possible in the design system, this is the eventual product, right? How did we do it? So step one was the research. It was very rigorous exercise. We went through almost all the websites to figure out how many social share icons, types of social share icons are present across the site. How is the menu design different? Like if you see a few examples, this is what it is. So one, two, three menu items look very different, and then we suggested it should be consistent. Likewise, example two, paragraphs on different website of the same brand look very different. We wanted them to be looking like that. Sample three, see the difference in the social share icons. We wanted to have them look very similar, right? So all this exercise of probably, it was around a month of exercise. We came up with a laundry list of what all components design elements they had on the website. So we prepared a laundry list. We shared it with the designer, and what the designer did was this was the step three. They came up with a Figma file, right? Figma file had all the components designed, and this became the holy grail for the developers to develop a design system. We had text, all the possibilities of mapping a text, buttons labels, what are the possible forms, what are the possible navigations, blocks, images, everything was developed. How will that, so we had asked that it should be basically compatible with three viewports. So even on mobile, how is the design element going to behave, on desktop, what it is going to be like. So everything was there in Figma file. This became the source of truth for us, and then we reached to the step four, which was defining the technology, how to go about converting this UI toolkit into a design system, right? So we chose Storybook. So Storybook is an open source tool, and it is basically, you have the sandbox there, you can test your design system on Storybook. We use, for UI components, we use HTML CSS. For functional components, we use HTML CSS and JS. Drupal, as I told, and we use Acquiasite Studio for component building inside the Drupal platform. We had Figma for UI library, Storybook, as I told you, right? But why, what is the approach that we took to build the Storybook design system? So we took a ground up approach, which was probably a proven approach before we started. Ground up approach means, as I told earlier, right? So you have to work on the atom first. You can't quickly, the developers can't quickly go and start developing the templates, right? So you have to start building the atoms first. What do I mean by atoms, right? You have to build the typography first. You have to build the buttons first. You have to build the dropdowns first, right? So the smaller elements will build first and then we attempted the molecules. Molecules basically mean, like if I talk about the search functionality, you have the field, you have the search CTA. This together forms a molecule, right? So those were built. How is that going to look like in mobile? How is that going to look like on desktop? That was built with that search. How's the menu coming up? The hero section coming up. So all that together was called an organism. So that was built after the molecules. And further, this helped in building templates, right? Block template. This is how the block template can look like. So it will have all the organisms put together. This was step four. And these are the essential add-ons we used. Very important add-ons that we used in the storybook. The viewport, which was helpful in basically adjusting the dimensions of iframe. And you can probably see how your designs are going to look on different type of viewports, right? Mobile desktop iPad of a specific device size. A, 1-1-y was used to check the accessibility of each component. Doc's feature was, as I showed in the screenshot, was to transform your storybook stories into component documentation. HTML, it provides the compiled HTML for each component. RTL was used basically to write to left toggle option was available because of this. So we were able to do that testing. And language switcher was used to basically test each and every component that we developed in storybook. How's that going to behave in any specific language? So we had all these Burmese, Thais, and I mean there were I think some 27 languages that we were testing each component against. Some key consideration that we took and we learned during the process of developing this design system was, and it is a great learning that I would like to share, that we have to consider the responsiveness of each component when we are developing these components inside a storybook. It is very important, we miss out on this, but very important, we have to think of grid system. We chose FlexBase Foundation Firework. This was a very lightweight framework, so probably helped us in the performance bit as well. Java, script and jQuery usage, I mean probably I'll not be able to answer all the technical questions related to this, but yes, minified versions of these were used while we were actually developing the design system. We used documentation within storybook, so all the component level documentation was like, if you have to use a paragraph, we had the HTML, CSS all written or available and then you can how to copy paste, how to use it, every documentation was available with each component inside the storybook, and then best coding practices, naming conventions, styling, modular coding, use of SVGs, so these were a few practices that we started, we started our journey with, right? We did a lot of research that we don't falter in between and we have to do a lot of rework, so from the beginning we kept note of all these things which helped us in the long journey. We adhere to Google HTML CSS style guide and we were very mindful of the folder structure, extra F, you can ignore the extra F, be mindful of folder structure in the design system, right? So eventually this design system is a public URL if you want, right, or it can be private as well, it's a URL that goes out to the developers who are going to use your design system if they are spinning off a new website, so if you want to put that into public domain or even in the private domain, you have to be very, you have to have a very user friendly navigation on the left-hand side, right? You should be able to define everything in the right order, so you should be very mindful of that, right? And this is basically the last step, right? You integrate your design system with your product, we integrated the design system with Acvia side studio on Drupal platform and the design system is up and running now. We have already observed a few business benefits, we have faster to go to market, achieve through simplified and accelerated development of digital assets, so now this client can spin off a new website in a few days, which was an exercise of a month or two earlier, now they can just quickly spin off a website without spending too much time on front-end development. Maximum component reusability for creating websites and microsites, I already talked about that, an improved brand recognition, all these 200 plus websites, now they look like they're a family, everything is very consistent, the buttons, styles, everything look like it's from the same parent brand. Improved brand recognition, creating engaging experience across geographical locations, so India website looks very similar to what is there in Canada. You get to know that they are from the same family and the frictional experience for designers and developers like through a unified user interface. So yeah, that's largely it. I'm open for questions if you want to ask anything. Do you use Figma for prototyping or do you use another tool to test your models you build at Figma? So the design team used Figma for prototyping as well, but eventually the final product that I was talking about here, the UI library which had the final designs was also made in Figma. So different bug spaces, but the front end developers used a different bug space which was the final output of this exercise which I talked about, right? So prototyping, yes, so we do use Figma. Thank you. Hi, I'm not sure if I understood but you're talking about 200 websites following the same design systems. So my question is how different can the website be? Are we talking just about color, not being the same or typography or go deeper to, I don't know, layout, animation, if you have any examples maybe or something? Right, so we had, your question is very logical, right? So we had this problem while we were doing the research, right? While we were going through these microsites and main websites of each country. We got to know that there are a lot of design elements but the problem, the core problem was that every site had different look and feel, right? It was not looking like as if it belongs to a parent company as such, right? So that was the core of the problem, right? And that is what we were trying to solve. So we figured out that, yeah, the paragraph styling in the website of Vietnam is very different from what is in Egypt. We collated all that, right? And we shared it with the designer. Look, this is what it is right now. And you have to come up with something which can be consistent, can be used across all and looks good all on. So that was the need that we have to make every site look similar, right? And we don't miss out on any of such design element on any of these sites. So that research was very extensive. We went through all the website, all the possible pages. But yes, as you asked, right? Like if it was a blog, right? If it's a blog, it has to look similar on all the countryside or macro site. That was the ask, right? If it looks different, then it is a problem. But visually different is a different thing. And if you say, like, if you restrict, say, Egyptian website, not to have a hero image because I've made the template, that was not the case. So you can introduce new elements. You can include a header, you can include a paragraph based on your need, but it has to look similar to what it has been designed in the design system, right? You can change the template. So it was available in the Acquia site studio. We mapped every component with the design system that we made. So people in the back end can go and choose what they want on their template and can design their pages, right? So but everything which came out eventually to the front end users, it gave a feeling that, yeah, the fonts are not different. I mean, buttons are consistent. Is the layout might be different? Yeah, that face. Yeah. Are there variations on each of the components? Yes. Located for? Yes, you said animations, right? Yeah. Submit button had three kinds. The need was to have submit button of three kinds. On contact us button, it should have an animation going from left to right, right? On probably a page where you download something, it was a need that if you change, the color should change from lighter red to darker red. So three variations were made. And now you have an option while you're making the webpage to choose any three of those. And the guidelines documentation actually defined which has to be used on which page. But yes, it was so holistic that now people are using it with ease, right? Without spending too much time on developing the same thing on a different country's website or anything of that sort. Yes, thank you. Just a small clarification, what happened afterwards? So you have been hired by this client to build this amazing design system and then all the sites are unified and then who maintains it, who inherited, who takes care of updating it and using it, is it still you or is it like on the client side, they have a design team that they were acquiring or using this design system? Our involvement basically is over. So that's the beauty of the project, right? So our involvement was over at the time we delivered. So the experience of the backend, if you are a blogger, we train them that this is how you should actually blog, right? You go in the backend, choose this content type, choose the header, choose the paragraph, drag, drop, drag, drop, make your page, submit and it's live. And that's the experience that every country's editor has, right, and Acquia Site Studio, thanks to that, has helped us in doing that. So now the designer, even the designer of this client actually comes into the picture when they need to have a new design element made, right? You and nobody has thought about it as of now. Now they need to have a carousel, for example, right? Which they did not have. The designer comes in, makes that, pushes that to a design system. The code, HTML, CSS, everything is written there. And then basically it goes to the backend and people start using it, right? This is the only involvement we have now. I think I'm getting a bit short for the next, yeah. Thanks, yeah. Thank you everyone. Thank you very much. Thank you. Thank you.