 So, now we already know that there are some other designers here and you have not been through times when you got a mock-up or something and there were like 10 shades of you for buttons and you have been through times like that when you just wanted to put a lot of salt in your designer's coffee. Okay, awesome. So, that's not only my dance. In a lot of products and service companies, different stakeholders are like a war with each other. It's like they are sitting on a ticking time bomb. This talk is named after a satire called Dr. Stainlub. It was made by one of the finest directors of Fortham, Stainlub Dobrik. The backdrop of the movie was a world war between Russia and America. They weren't very friendly at that time, like they are now. And it was about an exciting movie about our companies or different stakeholders like design, dev, testers, managers. We are often in a similar situation, like we are in a world war, over the product. And what actual product gets shipped outside to the user, right? Everyone is putting things in their side. Managers want one thing, devs want to do it one way. And designers, the office have some problem about like dimension, want weights and others of the It's like we are in our own game of thrones. We have our own house lannisters, house cars, and on top of everyone are managers or white walkers. So, my name is Pajas. I've been a designer for over 8 years now and I've been in this type of situations many times in my career so far. We are in a cold war. There is one designer with 15 devs of us. Things are running very fast. Devs just start designing everything on their own. There is a communication like breakdown and the product suffers in the end. Over the years, last 3 or 4 years, I started to work in a concept or in an method called design systems. And this is about my learnings from over the last few years creating design systems which have now helped me create much more effective communication around the product and product design which also helps devs and other team members. So, so far my, before that my art was like this. I don't know if you can see this very well but I was saying we have to be able to gather. So, let's define design systems. When we say design systems, what do we mean by that? What are design systems? Design systems are a documentation of principles, rules and ideas that guide the entire product piece into building the product. So, it's not thinking about the product in terms of flows or screen by screen which sadly most of us have already been doing. We think of features and everything in terms of one or another flow. We take everything screen by screen. Yes, this screen is done. You don't think of it as a whole product. Design system is kind of documenting in a way so that you have a coherent product instead of different components or different modules. It's not really a new concept in either programming or design. You have been using modular port or modular frameworks like the bootstrap or as a foundation. Or if you go back even a few years ago or something like jQuery UI or Yahoo! UI library. These kind of things we have been using for a long time. So, these kind of frameworks they are pretested, cross-browser tested library of components which you can take. You can assemble them in some way to create your own products. What they lack is sort of a documentation, sort of a logic or rationale on how to use a particular component to build your own product. How to contextualize those components. Mootstrap does get a lot of lapped from people. They were for standardizing or making everything look the same. But even companies like Airbnb did and they still refuse Mootstrap. So, if you are using Mootstrap, you won't have to blame yourself at all. Companies who have made name for their designs, they also use Mootstrap. It's nothing wrong with that. So, if we take components metaphor of Lego blocks or your components, let's say your component library is a set of Lego blocks, then you can think of design systems as the guidebook that tells you how to make something from the Lego blocks. You can make a Starship or a lot of other things, Castle, Moria Castle or anything. Only if you have that guide, it tells you how to put your pieces together to build something out of that. So, moving into the components or the ingredients of a design system, what are design systems here? First and foremost and most important thing in a design system is the more principles of your product design. You take your design decisions or principles, what you want your product to be based on and then use your design system as the melting pot for those concepts and your principles. So, to give you an example, this is from material design. Help me clear, use material design or are familiar with this. Okay, awesome. Great. So, material design has laid down the principles up front. They want to use material as the metaphor for the product design. They want to make their app, at least Google's phone apps, very bold and graphical. They want to make it very colorful and motion is a very integral part of design to kind of guide a meeting to give proper feedback to the users about different activities on the screen. Next is content. Content is what we communicate through our products to the users. It could be in terms of original words, written phrases or could be visual elements, media elements. Here is an example from a popular product called MailChimp. So, MailChimp has this, they have a dedicated website for how to use text, text messages in their products, in their app. They have defined and anyway in the design system you can define what your message is to the user should be, how to actually label the product as detailed as how to label your call to action products. How concise you want your messages to be, whether you want your messages to be humorous or you want to make them very straightforward and then you can also define and declare inclusivity in your content. So, for example, use of gender pronouns. It's a huge point of debate about how to use the gender pronouns in apps where you may have seen she being used more often in order to make it more inclusive to women. So, similar things they get defined in your content. Images, do people here remember images like this and they wear a normal web? I mean you go to a company's website, company might be based out of Ahmedabad, Ederabad or Mumbai but everyone would use these type of images on their website. Call it a lack of proper stock images or awareness but moved on from then. We have started defining our images to be more inclusive, candid, diverse. You might have seen lots and lots of products. They have clear definition what type of images should go in their product and there are more technical things you can define in the design system like what image sizes should be there, what reservation should be used and things like that because images come in ways that words cannot. You can immediately speak to the user that okay, you are the target for you and more. Similarly, illustrations, you can define your illustrations styles, specifications in your design system. This is an example of illustrations done over drop-offs. It's completely musical and fantastical things that may not happen and that really conveys what drop-off so as they are trying to do like 70 years ago when they started, what kind of addiction they wanted their product to undo. So, just to take a step aside and ask the question, we are designers and I mean I am a designer. Most of you are content players. Why do we need to talk about content? Isn't content someone else's job, someone in the company who we haven't seen ever, doesn't, don't they write the content? I would say no because creators of digital products, our job is to serve content in the best way, the best content in the best way to the users. That's what our products are for, to serve some sort of content to the users. Secondly, when you work on content with other people in the company, say someone from HR or marketing or from legal, it breaks down the ecosystem that we have created in tech system. It's a tech ecosystem, it's like all the technical people are talking to each other but our users are something completely different. They don't share the same backgrounds, they don't share the same skills. When you work with cross-functional teams, you help break that equal chamber down, which is why I think content is one thing where every one of your company should collaborate on and work together, just in like the selection of life choices or scale, the rhythm, vertical rhythm. That's very important for any kind of product because a lot of the web or apps is text to it. Colors, again your color palette conveys the values of your brand to the users. In your design system, you can not only choose your colors but also specify the color combinations, you can also specifically work for accessibility. For people with different business abilities, one who don't have perfect business and then a lot of us here are, we don't have color palette. So accessibility is also a very important thing that should be defined at the outset in your design systems. Here's an example from IBM's carbon design system. They have picked a color and kind of combination which enhances text and keeps text legitimate all the way. Grid and structure, your product can choose to use a grid with multiple columns or anything or you can just work with it. It's in the context of your product, whatever makes sense. You can also define how your grid or structure should respond to different screen sizes. You can use your grid to establish a baseline of vertical rhythm. So people who are familiar with material design, you might know that they work at baseline of four points. So all your elements and components are placed and they are multiples of multipliers of four. So those type of things are baseline, you can define. Another example from carbon design, you see how the grid responds to the screen size difference. Earlier you had 12 columns and a certain button. When you move to a smaller screen, you change the number of columns and buttons. This is an example of how baseline involves bigger baseline and that all your, not only your text, all your elements can sit on that page. Component sheet. Component sheet or component library is something a lot of you might be familiar with. You might even be using something like this in your organization. Component library is your catalog of all the UI elements that go into your product. So you define, you can define all your elements and how we are related with each other. How, say, a form, it would feel as if how the next label should be placed, things like that. You can define their structure, specs and their behavior in the sense that how an element looks when it is focused versus active versus disabled. You can also define states of larger entities. For example, something like empty state. How something looks when there is no data line. Or how something would look when a user is using it for the very first time. How do you actually drive this user to take some actions? Those type of states can also be defined in your design systems. Data visualization. If your product uses a lot of data visualization, you can create definitions for them. Your charts, drafts, infographics. Here is an example of a pie chart in a house where users are kind of denoted by color and what order they go into. So to summarize, your design system is made of your four principles. Your definition and declaration of above content, grid and structure, hydrography, colors, your component library, data visualization and rules for that. You can even add things like icons. If your product is very much dependent on animation, you can create rules for motion design. So your principles of motion design can also be part of design system. So going back to how I started the talk, why do we need design system? One thing I mentioned was communication. But say you don't have that problem. Your product probably runs very smooth. You don't have fights between designers and devs after 5 years and 3 years. You still need a design system. So that's the case I'm trying to make now. Communication, as I mentioned before, communication is very important between different team methods. Not only designers and devs, but once you develop something, that is going to do the testers. Do testers understand what you are trying to make? And I think all of you will agree that that's a huge problem, getting something past the testing. So when you create a design system, you are essentially creating a shared language between all your different statements, all your different statements, which means that when I, the designer, mentioned something, you know exactly what I'm talking about. The testers knew exactly what we are talking about. And you can even extend that to the customer, to the end user. So they know what you are talking about. Create a design system in this type of shared language. As devs, you can be sure that there will be surprises. You won't get a new screen with 15 buttons or a different shape. You know that there is something I already know about this product and the new work is going to be based on that. These types of constraints make lives very easy. Even when I say this, when you know exactly what kind of large pool you are getting things from, your work becomes very easy and kind of happier. So to give you an example of how the shared language works, this is something from a product called Intercom. Some of you might have heard or used this product, it's a chatbot, you can place on websites. So in their definition, in their feature definition, they use a name, they use a phrase for a feature, which then translates into their sketch file. So from definition to design, they have a component in code for the same, which I am not very sure could be react. So they have the same thing in their component library, code component library, and then when a user searches for something on the website, that's also in the same language. Users are also searching for monetization. So from start to finish, everybody is using the same language. Their work library is same, which means you have happy designers, testers and managers, good vibes and happy users, scalability. When you have a shared resource, when you are created a pool of resources as part of design systems, that creates a very easy product range to go from idea to production. You can create wireframes, start picking different components based on the rules you have already set, and start making screens very quickly, which means that you are running out of time from having an idea for a feature or something. I mean this is assuming you have done your research and you have proper structure or flow in mind. So from having, from that moment, from that unit government to getting to a production version of that feature, the turnaround time is very low. And low turnaround time is a money to years of your managers, because it means you are saving lots of money going from idea to production. Knowledge sharing and consistency in output. So because you have documentation, it becomes very easy to share the knowledge between other team members, between team members of your own department, designers to design us and designers to help. All the knowledge sharing becomes very easy. It also means that there is a consistency in the output. You will see people working on two multiple models. You can be sure that their result is going to be same because it is based on the same source of truth. It allows cross-functional teams to see the rational behind design. How we have you here take the design as some sort of a magic and you have no idea how your designers sum up with the stuff they do, but you are just supposed to take their developers and what not. Because anyway, if you have been in a situation that your designer refuses to tell you why the kids are their choices, right? Why their choices are like that, but you are just supposed to work on them from really great point of view. So, teams that are from a lot of clients, a lot of teams, designers seem to think that designers are some sort of black box in which magical things happen. Because there is no transference. As designers, we have a guilty of not being very transparent how we come to certain differences and how we build certain solutions. When we create design systems, any document that rational that logic, it makes it very easy for other people to understand our process. Then it makes design not a black box. It makes it looks like something that can be easily learned, right? It is not an art or can be a moment. It is something that can be learned because it is logical. It also makes it very easy for new team members to become product. If you are a senior team member in your team, whether a designer or a developer, do you have young new joining coming up to you and asking about asking questions about why something is like that or that? No one. So, no one has 18 new joining coming up to them asking questions. So, at least it happens with the design teams. New designers come and ask us questions, why something is like this? How do they repeat the same thing? How do they create something similar? When you have a design system, when you have documented your principles and rational behind it, the new team members can read and see all those things and they become productive very quickly. They do not, they lack of time to become productive. Reduce is a thought, which means you have very happy news in the team. They know what exactly, how they are going to build something. Response to external changes. So, based on an article by a company called Information Architects, there are 13,290 Android devices in the market, which means a huge spectrum of device screen sizes. We are never going to be able to build anything, design, develop and test anything across the spectrum. There are, and this is only right forms. In our other things, your laptops, tablets, fanlets, mirror glasses, TVs, advertisement screens, the screenverse is, it's like a multi-verse, it's larger than Marvel's universe. So, what you can do is instead of designing and developing for everything, you can set rules as to how your system, how your product responds to screen size changes. So, here is an example from material design. Something that's a tooltip or a dialog box on larger screen, they have defined it as a bottom sheet in the smaller screen. So, you just have to define something like this. You don't have to create each and every thing separately. You have created your at a component level, you have to find how it's supposed to behave when screen size changes. So, device to device, you are in a better fashion. Concurrent design, because now you have a shared resource, you have everything documented, multiple teams can start working on different modules, different features at the same time. And the surety is that they are going to work of a shared DNA of the product. You have one team working on one feature, the other team can pick up a different feature and their work will be consistent in their output. Together we can work. How many people here know what imposter syndrome means? I'll define it for you and then ask again. So, imposter syndrome means that you are able to do something but you cannot actually believe that you are good at it, whether it's development or design. Now, how many people feel this on the end of the day? I also do because I am like you. So, when you are not able to actually believe that you are good at doing what you are doing, often it is not because lack of confidence. I mean, it could be because of lack of confidence. It is also because when you take certain decisions of your day-to-day basis, you are taking the based on internalized processes and intuition. You are not externally documented your rationale behind it. Some of the decisions come automatically to the point. So, you start believing that you might be doing a lot better than you did six months ago, but you are not able to feel it. When you document something, when you write it down, when you write down the rational step-by-step process behind your decisions, you are able to feel that, no, there was something, there was some logic behind what I did. It has to be all your imposter syndrome. You start being better and completely based on anecdotal evidence of one person, which is me. I would recommend you try this, document your processes, because you start feeling much better at whatever you do. So, you feel good about what you are doing. Just to summarize, and these are only a few benefits that are personal experience from the theory design system. It improves the communication between different teams, it makes for happy team members. Unlike, I would rather be guaranteed that it will improve your relationship with your designer. It makes monitoring easy, and makes it very easy for the new team members to learn something for the product. You can define your responsiveness of the product, multiple teams can design together, and it can draw your imposter syndrome. So, picture is not all rosy. It's not as if you can start, you learn about design system, today and tomorrow or Monday morning, you are going to start creating and using them. One of the biggest challenge in creating or implementing design systems is that it takes time to create design systems and then maintain them. Because it's a different document, you are going to make changes based on implementation and on research, on data, how people are using your features, you are going to have to go back and make changes to your design system. It takes time, it takes people power to do it, which often companies are not really interested in investing in it. Top level buying. For a manager, a lot of times managers and the top management would rather spend their time, money or energy on developing new features than something like a design system. Because design system may or may not give you any immediate benefit. Lot of the promises are future benefits, like okay, you can scale better, your product may be more coherent, your product may be actually better, but trading back for two new features that can go out of XP or minus state depending on the manager, that's very hard buying to get. So, convincing the top management to invest their time and energy into this is sort of hard. Lack of tools, so until very recently, they were using tools for designing a design system. So, normally the way designers would work is they would make two copies of the same resources, like Photoshop or Sketch, make changes, at the end of the work, they would collide with everything together. There will be no git like workload or design as such. That has changed now a lot because most of the design tools now support design systems and libraries out of the box. Here's an example of a design system I made for a company called WebEngage, which is the startup number. You saw more examples of WebEngage's design systems here also. This is a specific point because the audience for this design system was their designers, WebEngage's own designers. It's a little more specific in terms of giving out specs and different states and everything. A lot of times this spec part is automated. So, any designer doesn't have to create it from scratch. Here's a very different example of using design system for teaming. So, there's a company in Bangalore, which has created a product called wallet buddy, which different financial institutes can buy it, label and convert it to their own product. So, here's one screen. This is a vanilla team for wallet buddy. It is based out of a design system that we created. Then when we had to make subtle changes, small changes to make a different product, we simply changed some components or some rules in the design system like apographic colors and there's a bit of grip. And the other product is different. It's not entirely different, but there are differences so that they could be sold to different companies. So, side by side, these are based on the same things with changes that the design system laid, which means teaming is very easy. Once you have defined something, your teaming becomes very easy, which is a huge asset to service based companies or even product based companies that you can change certain things and create an entirely new product. There are examples of design systems out there. Salesforce, Mailchimp, Shopify, IBM, Google is the one who started this all. So, Google has Google's various guidelines. And Haitian has a design system which you can study to kind of start on your own and see how they contextualize everything in terms of their own product. It has become so popular that now there's a gallery for design systems. When something has a gallery, you will know that it has arrived. So, the question I want to leave you with is how can you or your organization use design systems? How can you go and ask your designers to kind of take these rules, take this concept, make it so that it suits the context of what you are building and come up with documenting their national decisions in a way so that it makes it easy for you. You are the for any designer, front-end devs or devs are the very first customers. It goes to users afterwards. You are the first people who get to see your design right and build something based on that. What I would request you to do is go and think how these concepts apply to your product. How can you ask your designers to use them? That's the end of my talk. If you have any questions, you can either ask me on Twitter or you can add it outside. Thank you very much.