 Let me first introduce myself. I am in Siddharth. You might know me from twitter at SiddharthTV if you don't then if you follow me I post all sorts of graphic stuff but I don't know what's open source but using any of my open source stuff pops up high and I get super excited. And I also do these YouTube things that I try to teach what I have done so if you want to look at really short videos of nice snippets then you can go to this thing now. And lastly I do this new thing which is called frontend army. It's like a workshop series thing so if your team does we have stuff for senior developers to help you out. It's like a mentor for a higher company. I go to frontend but army is my main address. Cool. I love that this company Auth0 they make authentication stuff. The part you do care about is view is real and view is a lot of real. And I want to talk about Auth frontend workflow which is basically broken. And I see this in context of Auth0 but it's like I think you will find this talk today. A lot of problems that we have are kind of common problems. The best part is why do I say our frontend is broken. So the first symptom that our frontend is broken is the quantity. So to give you an example the top thing is what the designer designed and the bottom thing is what the developer quit. So it looks kind of the same but you see the designer has this like two blue icons. They sit inside the input box and the developers are like ah they get a margin I don't want to do that. So you just put it outside in an ugly grey border. The other thing is that designer comes up with this like nice walk out and like animation goes over and the response they usually get is in nobody but that. I have product managers and there is this docql thing that everyone keeps talking about so I have other things to do. I'm not going to spend time on your shaky models. The second symptom that your frontend consists of. And this is something which is kind of very weird. So we have multiple products and inside every product we have this thingy that's on the top right. You have your name you click and it's a drop down. So these are three of them of course different. They kind of look the same but they're not really like they have the same shadow in everything but they're slightly different right. So for example in the first one your view profile thing is on the bottom and there's like a flag thing on the top it's like a region switcher or the second one. I don't know what you're thinking on my name you'll do. Maybe it will go to profile and you'll get to what. I really like this one because it's like log on. But these are things that users have to learn and it's like inconsistent. It's a bit fun to keep track. And this is like a very weird focus that every designer has proficiency inside their sketchbook. So all of these are symptoms. They're not necessarily the problems. They're symptoms of the problem. And the real problem lies in communication. So this is the communication between designers and developers and collaboration. And all of this rises from this one common set of handouts. There's a wretched concept of handouts. How many of you are familiar with handouts? You do handouts in your company right. Just two people. So let me try to explain what handouts are. Your designer gets like a requirement I think. And then he goes into a heap of handouts and he comes back with these fancy designs. And then he's like, this is what you're going to make. And then the developers handouts and then this is the problem. And then the curator says, does that sound familiar? So this is kind of the example of what your designer comes back with. It's like nicely designed screens with like, they lay it out perfectly. They use nice purple colors. And that's what's trending right now. And the developers are looking at it like, what is this export? What color is this? Is this accessible? And how many pixels is this? Which screen comes after? Which screen? This looks pretty, but what do I do? So that's how to admit that our tools have come along with it. There's tools like Zeflin, designer, sorry developers. They hover over it and tell you this button is 14 pixels or 12 pixels or something like that. So they just talk to you and say, this thing has been made. They comment on the thing and say, this is, please change this and then collaboration. But these tools still revolve around the same idea of handouts. It's still revolving around the same thing. And it's just enough computing. What's this situation? So Twitter tried to come up with a solution in 2011, the Putzla. And they basically made every website in the world look the same. So like any self-respecting front-end team, we tried to create a Putzla for one. And that's what you do. So we had to use all of these buttons around the states of the buttons. You have different states with different colors. You have icons that you have. And this is kind of what it looks like. You can add a text. This is how you get it out. You go to the documentation, you copy the class. You say, this is a button, but it defaults. I'm using an icon, which for some reason is italics, even though it's not a direct app. But I think it's eye-in-eye, so we could use it. Anyway, so you put an icon, you say, I want a button icon. And this is the icon I want. And then I say success with things. Now designers do a user research, right? Which is for name for the last five people and all of them are new. And they said, we're going to move icons to the right now because that's more accessible or that converts more or something. And then they say, this is what we should do. So they change the style, they change the CSS. But that doesn't really solve the problem because everywhere you use this icon, you also have to go and switch this. The icon cannot be switched. You have to change it and the icon has to come second and the text has to come first. So it's very close to what it wants to be, but it doesn't really do the job. So this is what's known as a leaky abstraction, right? It tries to abstract how the design is required. It does a very bad job and most of the implementation details still come with the user. It's a surprise that we have components other than abstraction, right? So we have components. We have components. And so instead of this, you can say things like this. You can say import a button from the library and then you say button like a package. And after this, when they ask five people to change it, you don't really have to care. Because your implementation detail doesn't really solve your usage of this thing. It doesn't really know about the implementation detail. This is not a leaky abstraction. We are components of the right abstraction for designing the left. And this has given rise to this actually which we call design systems, which I haven't talked about enough. So I'm not going to explain what it is. But other than this one definition that I really like. So this is a design system. Design systems are a set of shared and integrated principles and patterns that define the overall design. The key words are overall design and product. So when you look at Airbnb's logo, you know it's effectively. When you see a Facebook light button on the wall, you know how to write Facebook under it. It's the design and the build kind of speech for that. So it has all of these things that Tejas was going to talk about. And don't get me wrong. Components are still a part of it. That's the kind of part that I want to focus on. So let's get into the technical stuff. So to build it. So this is kind of how you can use the new builds in the common way. Say you have space vision, right? So instead of using any of it as the value of spacing you want, it's a good idea to kind of leave them out with the multiples of a unit. So for example over here, the unit is 8. And then you have extra small which is 8 pixels and then small is 16 pixels. And then I run out of names as extra, extra large is 8 into 7. The names matter less over here. What matters more is the common language. So when you ask the designer what should be the margin, you don't say 32 pixels, right? You don't say 70 pixels down there. You say let's use medium spacing over here. That's what we use for all section margins, right? That's like an easy way of communicating. The other thing that also perhaps let me say that, right? You can do the same with color. You start with a base color, for example let's talk about gray. You have one gray color and then you have five shades over it, right? You can have multiple shades. Atlassian's design system uses 16 shades for the Atlassian. But we kind of found that five shades are more than enough for us. So we do this with every color. We say this is the base color, this is the dark, dark color. And you see, we have dark objects. So now, okay, when you say what should be the color of the button, you're not saying let's use sky blue, let's use turquoise green. You're saying let's use blue light, let's use light blue, right? And then you don't have to look at the sky blue or what I do. Colors.blue.light, and it means the same thing for everyone. You're not talking experts, you're not talking pixels, you're talking variables, right? So the conversation is easy. And the other part, which is like a hidden point that I really like, is that it steals the creativity from your designers a little bit, right? They can't start from a blank canvas, they start with this palette and they can only choose the right colors for them. So that kind of limits your design. It just makes it consistent. The next part is you can also be in branded. For example, over here we have some conventions, like success. If you use the success button, the background is colors.green.light, and the foreground text on it is supposedly colors.light. Same thing goes with the question. You have disruptive button, like a beneath button, the background is colors.light, got base, and the foreground is colors.light. So here again, where you say I have a beneath button, what colors should I use? You say I'm going to use the disruptive button, and you get a set of colors to use. So again, you're not even talking about which shade of light, darker, extra dark, you're just saying I'm going to use the disruptive button because that's what it's for. Good. So the good part about this, like creating them as a host of objects is that you can directly use them in the react. So this is like the policy as a j-ship, you can kill it. I like CSS as well, it's nice. But what we also do with this is another project, so it's our script, you also export the SAS variables and XML files for our Android tools. So you can actually just take this and export it for everyone, even if you're not using the app components in your native Android code, at least you're using the same product, the same guidance. The next product, this is like the big part, this is component-oriented. And this is like a long work by a smart one. The important part is, when you're creating components for a design system, it's important to prioritize API sensitivity over any specific information needed. So like the layman transition for this is it should look good when people use it. Internally, you can do whatever you want. So, and this is kind of what I've actually spent a lot of time. So for example, this is our API. If you want icon, you say icon, the icon name is an elephant, and the size is 20. Then you say button, I want the primary button, and then the icon of copy. So this is kind of in that, when you're designing as you can be at a button here, the conversation like, can we have a primary button here with a copy on it? And this is kind of what you're also typing in here. So the more your code looks like the conversation at the app, the easier your entire is, the more intuitive it will be. Similarly, switches, what do switches do? They toggle, right? This could have one change, one press, etc. But because you have to support multiple devices, the component now is toggle. You say, on toggle, then you can ask for a component. Good. Do you have a code like compound components? So compound components are this nest component inside a parent component. So because components are tasks and objects, you can actually just attach things inside it. For example, when you create a tab, you can say, and then inside it, you can say tabs.tab. The syntax looks a little weird, but the good part of this is, you only import tabs at once. You don't have to say import tab and tab. There's more tabs. Similarly, if you create a form, you don't have to say import form, text-in-form, text-in-form, text-in-form. We just import form, and then the rest of the things come as chosen. The other abstractions we didn't go ahead with, when you say form.text-in-form, you're not actually just creating a text-inform. You're getting an output. We also pass label, which is nice. I'll come to the examples for this. How we add a text-in-form, or a text-in-form, using a label. The core idea is, if I should look nicely used, it should be included. Internally, you can do whatever you want. How many people dare to write documentation for their own purpose? That's more than I expected. Good. Documentation is the problem. If I create a button and you're documented, you can't search and stack over and find that I've worked with. If I don't document it, it literally doesn't address my name. Documentation is the most poor part. If it's not documented, it might as well be. So, these are the nice things when you book in Skywriters, as you already could draw it when you just started. When you go to go to an isolated complex, you add Skywriters before creating towards creating a list library, a library of content. We ended up creating a custom mesh of this thing. I'll show you that. Yeah, so we call our designing. Design is the most worse. Let's see. The next important part is that design decisions are big into the system. And now I'm getting, putting this update in my site. You can't just create anything. Anyway, so here's an example. When you say you want a page header, you're not saying I want an X1, X2. You don't really care. You say I want a page header. And the design detail that this is the size, that is big deal. And that's what we actually do. When you say actions, these are the actions that my editor has. You say this is my primary action, this is my secondary action. Now, what's the color of the primary and versus the secondary? You don't care. That's big into the system. Are they left line or the right line? Does the primary come left? Secondary come left. You don't care. The designers have spent their time and you don't really have to care because they changed internally. It's in the implementation detail what it did there. So here's like a form which has three fields and then it has a primary action. And let me just try to show the code part of the problem as well. Sample page, 4,000 slides. They have a switch, and then you have action, and the action is this. You have to give it on the handle because these are the nice things you have to care about. All of these are aligned. These are design decisions. The label could be left aligned but you don't care about. You shouldn't have to care about. So let them do it. The switch is all fancy, large and all those nice things. It has an accessibility thing being in. This is a feature that actually has some input. But what happens when I click on accessibility things are already being into the system and designers won't have to care about it. Everything is already accessible to a certain extent. Same thing goes for the button. It's aligned with these input things and not the left thing. Obviously you don't care about it. I'm going to form. This is the user input I want. This is the project part of it. Confident over third. Language on the left. Which means you can't really do labels on the left because you don't have space and you say label on top and label changes. I can copy this on the box and paste it in my phone. This thing should change to top, right? So these are the kind of things. These are design decisions that are abstracted and they create an extra top. It's not backward breaking. And it's the new file and the new file is what you have. And don't forget it. It's not going through the design so first the designer has to sit and sketch the tools in the end to make it similar. It's just time wasted. So the idea here is that people have already created nice tools like LVD, we have a Gatsk etchup, we have a HDM etchup. This one is good for native. That one plays nicer with that stuff. The thing to care about is components are simpler than sketch. So when you say I want a button from the box and sketch as I release something like insert from Cosmos library what button from Cosmos? So that kind of thing is the source of the code and it generates, you make sure that things are all the same. When the designer wants to start a new project they basically just update their sketch library and they put in six months flexibility, so that condition is not a way with that. But it's very useful to ask do we really need this extra variation of the same component? And the thing is most of the time the it's not because it was it was new, it exists because even did not know that this came so they created this kind of how it was called as code. So always try to go for consistency. The second is build up fractions but shift all the building blocks. So I showed you page header I showed you form how these layout things are done. I used to give that thing basic keywords people wanted like a bigger header around it and then you click on delete it and say are you sure you want to delete it and you say okay fine so it's a very custom bearish case. So you also don't want to become what you call it the road block. Many of my other teams that rely on this system it's very easy for them to say this is not an assistance to the block we'll be under the king building. So the idea is we build all the abstraction but you also shift all the building blocks that they can use the form label so border color dimensions not this property and then make the one thing and the good part is if they make it you can always bring it back into the system and promote it as a library component. Third thing is adoption is the only method so they are all the fancy components that you want but if it's not good to use if it doesn't work out for your developers then you have to build it yourself there's no right and wrong thing that they use. So optimize for usage optimize for whatever actual use cases are where your developers are interesting thing interesting example I have there is I really wanted to use portals I think they're really good so I went ahead and used portals from the access team but turned out the app that wanted to adopt the system as a reactivity so I could have said reactivity is more reactivity is the new hardship so you should upgrade but that is adding more hurdles to the users so what we did is use portals so you can use like a polyphase which adds a little bit to the site but they could use it in the things like adoption optimize for adoption not for port, utility and all those so the last thing I want to talk about is that I hope that folks are convinced that designs are cool you can use them or something it works many times like how do you go on Monday to your boss and say you need to do design systems and the suits in this slide are nice so the first thing you need to do is show people what's wrong so when you talk about design systems you say design systems and the views etc. but most people don't really have that like unless they're working on the same thing every day they might not have that visibility for example a product manager was really happy with the product until we showed that three different drop down things like what you want this product is good like yeah this is not good we should fix this right and then we should destructive button that will say this is right this is big is that what you want and let's just look back when did we bring this so people might not know what's wrong unless we do this but my manager the designer actually did this is our landscape and we want to talk about design purpose actually we're not so let's fix it so show people what's wrong speak their language right if you go to the CEO and say usability is good and then we don't have to do this and you want to mask a crop and then abstraction it's not going to say sound wise but you should this feature 40% time creating presentation components and 60% time creating logic this 40% time every 1000 we can actually just put like 3 number team that does this 40 and then everyone else will have to but this can make you think one is that 40% of the team gets fired and they save money what luckily happen in our case is those 40% people will go go differently when they start the new product I don't make business things I don't make folks product managers like CEOs and you say usability and nerds but in the app they don't really care right so crop their language the third thing is build support from the developer so before you do any of these two things go to your fellow developers and talk to them about usability and they care about this they get excited about it the easiest way of seeing this is saying clip card did this would be hard numbers why is this a good question so then we all have this ego so you build support from the developer this is the new hot thing this is the way you do it and you have the support from the development layer and then when you start speaking they go back to their team like one day engineering managers like these kids are talking about design systems I don't think there is a problem and then all the developers instantly it becomes like they instantly it becomes like a consensus thing and then the manager probably missed this this was there all along and yeah I guess that's all the problems I have so I'm Siddharth Gettner it should follow me this is the it's all open source so you should look at the API it shouldn't record the code oh yeah ok