 Hi everyone, thank you for coming today. My name is Angie, I'm a developer with ThoughtWorks. I've been working here for one year and I've worked in a couple of industries before for financial and insurance industry. And we have here with us Vy. Veronica, so I am a designer here in ThoughtWorks. I've worked for ThoughtWorks around two years now but in the industry for a decade and over. So I work financial governments, UK, government here in Singapore, financial as well, B2B and so on and so forth. So that's us, shall we start? Thank you everyone for coming, hope your bellies are full and that you will not fall asleep. Quick check, are you ready? So we're just going to set up a mic. We can shout, no we can shout. Well you can shout? You want to recite a poem or something? Guys if you are this loud, is it okay? Can we please ask the people in the kitchen to be considerate? Thank you, awesome. So thanks for coming and let's go to that. So I see that we've triggered the good words that lots of people came up which is beautiful. So what we want to talk about is how to build a scalable product. This has been triggered because we've been recently on a project where a client has six digital products. We had ten months deadline so we throw in four designers, we have developers here in Singapore and abroad we had to communicate with. And the interesting thing about this project was that the product we were developing was supposed to be white labelled. White labelled means that they take it and then they apply different branding on those six products that they are rolling out. Now we were obviously working in agile environments and we're scratching our heads on like how can we make this scalable, how can we make this fast, how can we work with changes. And we identified kind of three items that are very crucial in order for us to succeed. And this is what we're going to be talking about today. So the idea there is that these three items are something that are very much on the ground. It's about the designers and it's about the developers. So let's go to the first one, the grids. So for the purpose of this exercise, imagine that Mountain Dew, which is the soda, has basically tasked you to create a login page. And then the login is for the new product which is called Diabetes. Diabetes is actually, okay, Mountain Dew actually in 2012 created a campaign and asked people how would they name a new soda. And this was the name that came up on the top. That's actually a real story. So they never did it obviously, but this is it. So we have a login page, right? And then what happens is the designer goes and says, okay, so I'm going to design the stuff and then the developer sits and then measures all the distances and all the measurements and they develop. But what happens when it grows a bit more complex, right? The developers are pulling their heads. Designers are creating these design systems to remember what were the measurements they applied on some different place. And then they had to make sure that they can apply all these rules constantly in the future UI. And then the developers either keep measuring or pull source will have to learn the design system that the design has developed, which we can't even keep up to date anyway. So the idea is that we apply simple grids. It's a very simple solution to a problem where you have to be focused on your speed and your scalability. So basically, what does it do to designers? It saves us time. I have a blank sheet of paper. I need to place an element on it. I have a boundary. I already have some guide rails, right? Someone has called it that it's like invisible glue. You have elements on the page and then grid gives you a nice way how to string these things together and create the rhythm. So the person knows where to look and where to expect things to be. The beautiful outcome when it comes to scalable products is that you have unified UI across all the products. So for developers, they can stop measuring painstakingly, painstakingly, okay, that word. All the pixels. And they can just focus on placing the elements within columns. So this belongs to columns, three columns, this belongs to four columns, seven columns. They don't actually go into the detail. Again, and the outcome is simpler and cleaner code. So let's have a look. I want to give you some practical examples. So, for example, I picked a grid that is the whole page grid and it's a full width. Who does that? For example, if you go Google Maps, they place this drawer into four columns, right? Very simple example. Or if you were to look into a, this is the most common grid you see everywhere on the Internet, like today's talk. Elements are placed within it. It's very, very simple way of using elements. And then developers don't have to go crazy on this. So over to you. Thank you. So in the perspective of a developer, we want to move away from measuring things, as Pia has mentioned, and we want to just know where the element should be put. So in using Glit, we are able to make it more maintainable in terms of code because we are able to put semantics in code. We're able to say that this is supposed to occupy certain columns instead of having some magic numbers in our padding and margin. So we are basically rating the UI libraries, calculate all these numbers for us, and we are just basically given instructions of how it should look like. So the benefits is obviously in terms of communication from developers and designers, we are able to communicate better, we have the same language. Also, even between developers, whenever you pick up a new code, you're able to make sense of how this code is supposed to look like in a layout instead of checking in what are the padding that is applied in an element. So basically it helps us in terms of code readability and maintainability. So the question now is how do we actually use Glit layout? So there are a lot of UI libraries that are out there and already have their own implementation of Glit layout. Some examples are Bootstrap and Material UI. Those are like famous UI libraries that have Glit implementation. But basically they're boiled down to the same concept and they usually use the live all these libraries from the same CSS Flags box. And actually now CSS already supports their own Glit layout as well. So for the purpose of this talk, we are going to start simple. We're going to start from making a page with one H1 element, one input box element, and one submit button element. So the first thing that we need to set up is to make sure that all the Glit layout is covered under Glit. So we should set up display Glit as well as we need to set up how many columns you want it to be applied inside a Glit. For instance, a typical number of columns that we use in designers and developers is 12 columns. I'm just going to pause for a second. So typically we have 12 columns. So here I specified, so this syntax repeat 12. It just means that we want to repeat 1 fr 12 times. So we're stating that we want to have 12 columns. And also for 1 fr, it's kind of a relatively new CSS syntax that says that we just want this one page to be divided by 12. And each of the 12 things have the same proportion. So it is a way for us to set up these 12 columns. And the last thing that we need to set up is to specify what is the column gap. In this case, we specify page to be 20 pixel. In other kind of speak, sometimes we also refer to this gap in designer language or some of the UI libraries language as gutter. So the next thing that we need to do is to basically place where are the positions that we want an element to be placed at. So in this case, for this H1 text, I specified it to start from column 3. And we want the column to end before column 11. So it starts from here to here. The next important concept that we need to know about grid layout is also it can be used either for positioning and for sizing of the element itself. So for instance, in this input box element, we are using the grid layout basically for positioning. So we are using grid column start 5. So it will start from this position to grid 9. So basically the element will occupy this position. But then we are still fixing the size of the element itself. But then also we can use the flex layout to actually determine the size of the element by basically saying that this button should start from grid 5 to grid 9. So that's how element actually occupies the whole distance that we specified. Cool. So let's still maximize what we can do with grids. And we actually can start putting the grids inside the elements themselves. Again, for the same purposes for designers as well as for the developers. So here's an example. Diabetes has its own shopping website where you can buy lots of diabetes. You can use that, for example, if you have a card like that, you can define a grid that has a wider padding margin on the sides and a different size to get to, for example, to this. So this card is a bit small. So from a visual perspective, what do you want? You want the margin a bit narrow over here. So you can go around and play with the grids. You can also use it on a little bit more complex things like, for example, it's a page, it's a let's say card which has two columns of a content inside. It helps if you say this is within seven columns. When the text bleeds, it bleeds over here. So it really simplifies lots of things first. With you. Right. In terms of before implementation, what we want to understand about having component grids is that we just need to place the grid container on the elements that want to follow the grid layout. But the rest of elements that raise outside of the layout can be stout independently of the grid layout. Okay. Any questions about grids? Yes. Are those custom components? No, it's coming with CSS3. Yes, CSS grid layout. They are just releasing it early this year and they are still making some tweaks. But you can basically use it right now. Anyone? Can CSS3 completely replace, like, bootstrap grid or other grids? Well, it depends on what completely replace means. I mean, like, there are certainly a lot of advantage of using a pre-made library such as Bootstrap. You can have a lot of other styling that is already made inside Bootstrap. But for the purpose of layout, grid layouts in specific, you kind of have the same functionality by just using CSS grid layouts. But depending on the use case that you have, depending on the kind of styling that your client wants you to use, it is very judgment call on that. Right. Yes, so basically that's also another advantage of using grid layouts. So we still kind of use media query for CSS grid layout to actually adjust, like, for instance, for the bigger screen, you can adjust it to occupy five columns. And for smaller screen, you can occupy a larger number of columns so that the size will fit better. But then also, like, in CSS grid layout, if you are using a plain CSS, you can reuse media query in other types of libraries such as, I think, Bootstrap have their own implementation of big points that enables you to, like, kind of not use media query directly. So there are a certain abstraction benefit that you can have by using UI libraries compared to, like, CSS grid layout. For example, in the grid container, between props that says you start from column 5 and then column 9. So that's particularly common way. So if you want to do it from lower, which starts from 1 and then from 12, which isn't a matter of any tumor or props that says mobile, start, and move on. Yeah, you can basically, just a matter of saying that you just call a media query, saying that from a screen size of this, you want the column size to actually use these other properties instead of the properties. So you override that properties with whatever properties you've set inside the media query. Cool. Any more questions? Are we all excited to move on? Components. So, components are fun. Imagine that you are creating your Diabetes account and you are the developer there and then we have just launched new feature, which is single sign-on, right? And then they come say, hey, we need a new button. So designer goes and creates a new button and then imagine that Diabetes grows and grows and grows and then you end up with something like this. This is very common with products that grow and grow. So you've got lots of styles, lots of colors, lots of buttons, lots of shapes, and then you start going crazy again and this is okay because the world is this, world is complex, things grow, changes come and we need to deal with that and design changes and design changes and it's okay. And here I just listed a couple of reasons why as a developer you get a new screen and say, oh my God, design changed again. So one reason is, for example, for optimization. In one of our projects we created a, it was mobile app and we had to do list where you would have a checkbox as in like single select list. And then as we grew, we have found out that we have a screen where we have to have a single select list where we have to be on the same screen. It was a filters page. And then we realized that checkbox is usually on the right-hand side but we had our ticks on the left-hand side for the single select so we had to move the tick to the right-hand side so it doesn't look silly. And that's optimizing, right? We have learned something new and we need to change that. Second, the hypothesis can be wrong, which is absolutely fine. Again, we saw that big red button would make people click on it. After research we found that people are scared or styles are not enough. So we designed a dropdown for one, two, three words items and then as we go along we had to put an entire address into a dropdown so we had to do multi-lines and so on and so forth. And requirements changed. So for example, we were doing checkout flow in a shop and they wanted to do the entire checkout flow that you redeem your points that you have collected. And then the business because the financial model wasn't ready removed that requirement and we had to redesign the checkout flow with the credit card. So things happened and they come out as a design change. Now the solution to that is components and you keep saying that components are nothing new to developers but they are very useful when you are talking about scalable products. How they work is basically as you are working through designing your product and you start spotting things that repeat themselves, right? Simplest is a button. So what you do is you turn it into a component. Now it can be a button, it can be more complex like dividers, icons and input fields and error messages and things like that accordions all the way to entire pages. And so what you can do is that if I create a parent button and then I change the color it triggers down in all of the child components. It's very simple. The beautiful advantage especially for scalable products is that we have a fast change across if necessary. We go to one place. Imagine I have six products each of these products has 30 pages or 30 screens and I have to go one by one to change it. Nonsense, right? And you have consistent user experience. So how would you use components and what are the guidelines to actually create components? So from user's perspective what do we want? We want them to be we want to be consistent. Buttons are always this shape, right? Buttons that have an arrow take me outside of this application. We want them to be structured. So make them inherited as many styles as possible. For example, if we decide that we want to change the font in the entire application, I don't have to go one by one. I just go change the body font and they should reflect in my entire application. And they should be reusable. And usability is only about how well you document it. And I'm not talking about writing word documents and functional specifications. It's about document them well. Designers have their own design systems, design libraries, whatever works for you for the specific projects as well as for developers you have your own systems. It's a very good investment for the long run. So we have come to why we do components in development. Obviously in the past few years there is a big rise in component based frontend frameworks like React and FUJS. There is a very good reason why that happened because of course there is this principle in development that do not repeat yourself. We do not want to always create duplication in code. We want code that is maintainable and we want code that is able to be reused in different cases. And we hope that by doing certain things to make components, we are able to actually decouple functionality and styling so that the components would be reusable. The first thing that we need to understand about building generic components is to understand that we want to build components that is basically reusable. It means that our sole purpose of building them is to maximize reusability and in a more specific definition of that is that we want to try as much as possible to decouple the position arrangement of a component in a layout and how the component in itself is styled and the functionality of the component. So the smallest building blocks that we can think about is what we call building blocks which is basically the smallest abstraction that we can find which are common patterns that we usually use in nodes. For instance, there is this flex component which is basically just a normal div that is default to use flexbox and flexwrap. So because we see a lot of these same patterns happening in our code, we'll try to just extract this and make a building block out of it. The next slightly bigger type of components is what we call basic components which is basically a typically smaller components such as your buttons, your input fields, your text which have all the functionality being able to be customized from the outside but you will make sure that there are also some default values that you can put inside so that it can be reused easily and can be reused to build bigger components. And the next type of components is what we have as composite components which are basically a kind of a bigger scale components that is composed out of basic components. For instance, we have this list speaker which is basically just containing one title text and a lot of these items according to how many of these items you want to pass into this component. The idea of having different field of components is that such that we can basically have different sizes that we can use as building blocks to make a bigger components and the differences between those are just in terms of how much customization we can do with them, how much functionality they have on its own and of course how much reusability they have on its own. So obviously we have common components. We also have components that can be extracted out of layout because it's reused in many pages for instance and basically usually it's reused within a module of a project. So those components, they are like very different sizes of those kind of custom components. Let's take the example of this small title text component which is basically just a text but we specify the positional styling of it and we specify a typographical styling that we want to apply to it. So basically the idea is the only thing that can be customized from this custom component is only the content but the rest of the styling is kind of already fixed within the component itself. In terms of how usually typically we structure our components, we usually have a comments directory where all our other common components are state in and we also have different directory which typically is named after the page layout or the modules which have all the components that is used only solely for that component sorry, I mean modules or layout. So basically this pyramid represents the ideal scenario on how we should have a number of custom components composite components and building blocks and basic components. Ideally we should have as much building blocks and basic components as possible so we can reuse it and build a bigger components and we should have the least number of custom components. The reason of having this basic level of time is because we want as much as possible to reuse it which will help us in the wrong run in terms of maintaining the code in terms of having a sense of security that if there are changes coming in we are able to quickly change that in just one place and not having to hunt for each of the components in different sections having the security that if there is bug to hunt we can easily hunt it in one component instead of having duplication in all our codes. This also means that there are technical depths associated with stylings so basically if you have many duplication you will find the pain not in the short term when we are doing it but in the long run. It's also true that customized components like your small building blocks is very heavy because you need to spend a lot of time to make sure that these components are able to be customized for other different scenarios but it is definitely a worth investment that we can spend in the beginning of the project. It is generally difficult to make customizable components basically there are things that are very obviously like basic components such as your buttons your checkboxes but sometimes like when you are implementing a page it's difficult for you to know which other components you should extract and make into a custom I mean a common component and sometimes the discussion happens with your designers but we should as a before try our best to find patterns to see what are the duplication coming in to see what are the stories coming up and kind of see how these components can be reused before and it is kind of our responsibility as well to try to push down the code as much as possible to push it down from a custom components level down to like composite or basic components level so in terms of so just now we mentioned about how in designers usually have a design system of a style guide usually developers typically did not have a style guide but in recent years there is a rise of style guide for developers these are just two example of style guides used typically in react projects so the idea of it is to give visibility for the whole team or whoever new members joining into the team of the existing components that we have so it's a good way, an automated way to kind of document all your common components so that everyone who joined the team will know what are the existing components again then they do not need to kind of push and they are able to kind of use the component and run with it so any questions for the component section what is the most practical largest scope for component library right so for example you guys have at ThoughtWorks a base component library that all the projects use and then you sort of refine it from there or is that too big every time a project starts you guys start a base set of components and kind of recreate that so obviously the more generic you get the harder it is to manage right from development perspective it really depends on the project there are projects that are obviously very small and it's not worth the investment to build the components at that point of time and there are also even bigger projects that there's just a lot of in terms of showing up the functionality that you may be able to kind of force and not do kind of customize all these components in the very beginning but if we know that this is obviously a very project that needs a lot of scalability then it really is worth it to really spend time to think about what kind of components we can break down and kind of put it aside and it's also a lot of discussion with the designers because designers would be the people who know best what are the components they are going to reuse obviously there are functionality components that is more of development base but usually it's kind of depending on case by case basis usually we will start from very basic components that we know obviously will be we use all the time such as that's why the basic components come in because we know like things like button things like input box first there are things that is always going to be used things like the building box like flags there are things that are going to be used so and it's quite easy to set it up so why not set those up first but the rest of the components is very on whether we we are because we are working in an agile environment and changes happen all the time so it's a balance of knowing what will change and kind of trying to also balance the technical depth of it and whether we want to do it now or whether we want to do it in the next iteration whatever makes sense I think the you should never have bigger design than your product is and I think that's the biggest problem if you inherit something so you should your component library should contain only the things that you actually need right so we the previous project the client had already existing style guide and as in coded from a code perspective as well as design perspective and then we are thinking should we take this and then we are thinking more towards materials so we say sure we use the material and then the developer the developer discussion only they say you know what let's not because then we will have to override and override and it will get all messy and then your designers don't even know if you're going to be using these components and we already kind of implementing them and making everything works so it was a work up front which you never want to do so that was on the this this was on the last last project we were on so every project essentially or every product anyway has its own design system as a rule and that means okay so does that mean that you come up with that system from scratch or do you have system templates that you get I mean clearly from project to project or product to product there's going to be commonalities you don't want to yeah everyone has a button right everyone has input field I mean so where do you draw the line there right that's what I'm trying to understand it's not easy it really depends it really depends but a rule of thumb is to not inherit something bigger than you need yeah cool any more questions components no okay I have one because we did this talk before already and some people ask and this is very very good question so they asked how to ensure that our project team actually adds the components into the library because we have no time right because creating components is full on ground and no one has time to go and make sure the component exists and is in the commonplace and then my story is supposed to was estimated that it's going to take me this much time or this much effort but I didn't accommodate for actually making it into the common component so and so forth so on other projects how we've done it is that we would actually create like a technical task which is create a component of input field and once that's done only then we would play a story that is implement this components into this place so there is a one way how you can actually manage it and make sure that because maintenance and diligence about maintaining your design system is obviously the hardest thing right so this was a mechanism we put in place in order for it to happen cool let's move on hey how do you actually start designing a component that is supposed to be reused because my question is more about you build the basic components like separate tasks like a isolated process or does it coexist with an existing requirement to go hand to hand and how do you make sure that there is reusability and component and the process is subject to change right so how do you accommodate for that so you start with the fact that you start creating the login page first you don't start this is my own personal opinion guys yes so everyone is like the atomic design right some people go from top some from bottom the way I found it working very well is that you create your login page and you have the individual things in there right the buttons the input fields the header things like that and then you create another page where it also has the input fields and then you're like oh so input fields are already abused them twice it's a good time to create it into a component right and then you keep creating new and new and then suddenly you know that your input fields can no longer be 100% with because we need to have two input fields next to each other for mobile phone for example right so what you do then is that you iterate so this is new requirement it's a change right and you say okay so this no longer suffice and that's why the design changes and that's why we then go and refactor our components and change them however we need it to and we change so this will be happening and it's okay but that's why it is so risky to design something upfront unless you actually have a use case for it right so as you go it's more of it worked better when it's more of reflection rather than trying to predict the future that will change anyway so for instance there is actually a real scenario that happened a couple of weeks ago where we are trying to implement kind of a model that is used in two different pages but basically the model are the same kind of design but have different content and different slightly different functionality inside so because we are going to play out this story in the kind of a same iteration so what we decided is for one pair or one stream of work to actually include that building of the common component inside a story and build that first and when that story is done, when that common component is ready then the next person can reuse that component so we make sure that we do not want to also build if we already know like the distant future of knowing that this is definitely going to be used like in a week we don't want to just build a custom component for this obviously so we will start from building a common component and then we just give it to the next person to kind of build the custom component for it sometimes what happens is when you do that you have your business of the critical experiments sort of lead into the common share component properties so you make sure that and I am sure it will happen but how do you refactor it again so that for the next one you don't break stuff when you maintain changes to the base component that's a really good question so design have a solution for that but it's about working software so in design software we have already tools that maintain this that can solve this Figma, Sketch all this you guys know but yeah that's a tough question honestly it's kind of I think as a developer we are never going to see a perfect code we won't be able to see like a nice pyramid or this is all our common components and all very minimal custom components there is always a continuous refactoring of our code and it is kind of expected that some of our code may not be like backward compatible at some point of time so it's also like sometimes a judgment call in terms of whether you want to build another custom component for it or you can kind of try to change it if you see that this is still reusable you kind of push it down the pyramid more and make it more customizable that it can be reused for another use case so it is more of a judgment call common experience cool cool any more questions what I am trying to understand is suppose I use a material UI which is entirely a component framework which is mapped to a react library and what components are we representing here is it a combination of those material UI say I have roughly 500 components from the react library available to me but are we saying that these components are developed independent to those final components for a wrapping of some components or how is it like what are these components it can be composed on top of that components so basically let's say a material UI already have certain stylings inside so we can override those stylings to meet the specification that we have from our client any more questions you guys on fire today that's a very good question so from other projects and this is a question that is like how do you make sure design system stays up to date and is followed and maintained and how do we know so currently on the project there is four designers and we are all in charge of certain functionality so we put couple of things in a place in order for us to stay in sync so we have daily xd huddle where we would just say I'm working on this, I'm working on this, I'm working on that hey you're using component that I'm about to use as well make sure that this scenario is including that so we don't clash and so on and so forth so right now it's a bit more of we sit next to each other so we can talk to each other it's not that big I've heard about projects where there's over 70 designers and this is quite impossible what they do is they create a whole structure like agile has all of these rituals they created a similar thing so yes there is owner that owner is involved on a product level because they need to foresee future and reflect and understand business requirements they create all the way to they send out a newsletter to the entire team to say hey we've finalized a new component this is how it's being used, these are all the interactions and they actually talk about it, it's about communication a lot then they have for example they have a tough component, they've created and then they do a Q&A so they call all the designers once a week and they say this is one can you please break it, we have scenarios where you think it will not work and so on and so forth so there are a couple of things that are put in place in order for this to work and to make sure that it's maintained and distributed correctly so are you talking about the supervising designers or developers currently in the project I have developers doing that to me which is great so I forgot to create something as a component they are like hey we're creating new stuff but we already have it and they actually bounce it back to me and I'm like oh sorry guys thank you so I think it's everyone's responsibility to be on top of the game but in the same way it's the owners of the design system responsibility to make sure that these people know about the components and it doesn't work if neither of them are doing their job reviewing people's design we are trying not to do that and if so then we would it's more about enabling the person to be able to keep an eye on those kind of things rather than checking if they are doing everything up to scratch because that's not scalable so I think one point that is good to put across is that we've talked about all this style guide like style guide for developers we've talked about how to make components small but nothing really creates communication in the end of the day like you need to still have that active communication between developers and designers within developers team especially in agile environment like requirement changes all the time like one day you are building this component and the next day the other stream across your table are building the same component so if you don't have that communication there is no way of you being able to already finish the component and already documented nicely for them so in the end of the day it's always about also communicating what's out there already and to make sure that everyone is on the same page even from the basic component in terms of knowing what's components out there it's like managing stakeholders if you involve them in the creation of it they are more likely to adopt it as well so it's good to have the developers creating the component with you and brainstorming about how it should work and what it should be doing soon cool any more questions so basically when you are trying to design something are you saying like for example I have this page do you say like okay so I have this element in the page so this is actually component A B C and that's how you pass it to the designer so that they know that oh so this one is actually an existing component already so that they use or like how do you guys like pass on like for example you have a single page pass it out to the developers and how do they know that this is an existing component that they have to create a new component for it cool so that's a very good question we had so we have a kickoff of stories so before developer picks up a story designer BA and QA everyone will come there and then we will talk through the story and then designers is responsible to point out all the components so I say this is a component this is a component I know this team has built it go and talk to those guys this is component also some of the tools for example I I create components from my typography as well so these are styles and then follow that it's a component and I make sure that actually in we are using Figma on this project and you can actually hover over and see that it is component style number to do so actually the developers can do it themselves as well cool anymore awesome design systems and components are popular topic last one typography okay let's carry on with our imaginative story imagine that and I'm not trying to be morbid here but imagine that you are blind right and then you have landed on this Diabetes page login page everyone think about it what is the most important information on this page everyone in your head what is the most important information get it okay you landed on a page and then it will if you will have assistive technology it will read out into your ear create your Diabetes account like okay I'm in the right place right so how what would be the HTML element anyone shout well done okay now this happens sorry the username Google was my idea is already taken choose another one okay so what is the most important information now the warning right so what would be the HTML that H2 assistive technology will first read this and then read that but that's no longer the most important information on the page is it so with HTML5 we can also call it H1 and now we have a problem because we have different font sizes for the HTML element H1 right the solution today is actually something called typographic scale it's essentially a list of font styles that are named but the names are not HTML element names so Google uses it Airbnb and everyone who has more complex projects or products they will figure out very soon that calling H1 attaching a style to H1 is not scalable because those kind of situations will start happening that I showed you before so if you look at the names it's called headline it's not called body text it's called subhead display one display two display three or title one you can name it I know projects where they call it crocodile mouse giraffe whatever whatever works for your team right and the idea is that how would you make it happen is that designer goes and creates a scale scale is like this very smart it's like a musical scale it's basically based on numbers of human function in a beautiful pattern so based on numbers you create your scale from smallest to the biggest and then what you do you assign a style to it so these are your styles and you name them giraffe crocodile dinosaur and you go on and what you can do you can go crazy with them you can link the HTML elements to whatever style you want need and your product that is growing crazy is requiring so it's very simple thing what we are doing here is we are decoupling HTML elements from the styling and now we'll tell you how so traditionally we have styling in the HTML element itself so let's say in H1F this styling H2F this styling and we have classes that offer like those styling so this idea is to decouple the HTML structure and styling we are with applying this area we are able to avoid those CSS overriding help we are able to kind of put it clearly all our typographic scaling and styling in one places and then according to the style that is needed we just apply them any questions no okay I have one for you so sorry just the concept here is basically override the actual HTML tags so basically we don't want any styling to be applied in the HTML element we just want to create classes that put the typographic scaling there so in the old days you would say H1 is font size 16 and it's bold right that's how we used to design and code but the idea is that you remove that because then those that problem that I have showed you would not be solved you will restrict yourself to those styles that you've created or you will have to start overriding like crazy okay so fundamentally you are abandoning use of HTML for styling does it make sense sort of sure the previous problem about here what would you use for HTML tags for the create your account and the element what tags would you use H1 just that create your account we got a smaller font size so that the accessibility will pick up that's what I want exactly so it was probably a bit too fast because we went through this so many times so it's a very good point exactly any more questions so when I presented this because I was actually presenting this to my internal teams because we are structuring completely the code because we were not fast enough basically and we were not meeting all the needs that we had to for the product because the product was growing crazy right six products and then this lady came to me and she said so why don't you make everything H1 and they just assign different styles to it right that's developers thinking I like that and I was like oh my this is too smart for me again so the reason for that is one is the accessibility tools so if you have assistive technology there will be absolutely no hierarchy of the information that you are reading it will be everything one by one and that's not necessarily what you want to do imagine you have a blog post and it has a sub-sections even we read without assistive technology just the headings first and then we decide what we want to read next and that's how it should be also and that's what we attract the assistive technology trying to replicate for the people who can't see so that's why it is important to actually create those H1, H2 H3s and so on and so forth there is actually one more reason and it's SEO so it no longer actually no longer as important in SEO as they used to be the HTML elements but they still Google here and there comes up with these things and this is purely based on the fact that they go in, read the H1 which is this one and then pulls out all the H2s so it does have its advantages I see lots of people thinking that's very good any questions? so if you go back to that scenario the users are not we are not taking the user friendly website where if people who can't see would not be able to guess so you would say let's say this would be H6 for example and this would be H1 okay yeah yeah yeah definitely you feel free to write what we are talking about is scalability right so this has its advantages the moment the product starts rolling out to other countries in Europe AA accessibility is a must governments it's a must so it's something that is very you should be creating user friendly products I don't know much about SEO but I would SEO pick up error messages? do they crawl? I don't know good question any other? yes do you have a system in your system whereby you have a system in your system whereby the you go alongside with the ICG for product matching otherwise you would be thinking that because likewise we are saying to use Google Play for product and you use for example the meaningful comfort and then you use for example stencil for certain kind of things do you have that kind of principle in your system to identify the kind of usability in a match up system I'm not sure if I understand the question as in like from design perspective or developer perspective so how do we assign the font to the right place the photograph for example it is suitable for certain product line properly used for any of times or whatever it is not for some you know stabilized structures for some other thing for different sort of classification so do you have that in your system I think this is a design decision on the beginning we are trying to avoid multiple fonts and try to figure out which is the best one for that specific product itself but it's a dark magic you don't have suitability matching component so if I would say I have two products two digital products and they both have a login page and for one product I would like to use let's say Times New Roman and for another product I would like to use C Comixense for example is that what you mean that's the overriding from the code perspective because like when you use body tech you use Optima which is useful you know it is easier and then for example you are quite certain to use something on your reality and use her radical medium light and then you have applied you got three categories but then you know it exactly whether you use light, bold, medium or not it's a hard work on the beginning here yeah it is cool any more questions? no just a simple question how many from your experience how many phone scientists do you recommend? the magic number everyone wants a magic number okay so everyone has a different number of course my number comes from a gardener who recommends never have more than 11 types of plants in your garden hahahaha no okay so with typography there are some basic rules how you can do it so one is that if you are changing phone either don't change all three things at the same time size, weight and then it's only gonna color yeah sorry size, weight and color so if you go it creates scale up or down you either make it bigger but the same color and the same weight or you make it the same size and change the color or same size and you change the weight so if you try to apply everything at the same time there's gonna be no harmony in it like with typography and I am gonna prepare talk about it that's ratio yeah again everyone has a magic number people are just addicted to numbers it's amazing so there's the golden ratio for example there is the most commonly used the ones that you have in your system there's a reason why there is 8, 10, 12, 14, 16 and so on and so forth again it's a it's a system that everyone creates themselves it depends on the fonts that you choose it depends on the light height that you can afford there's a lot of things too but I think this comes with the experience and there are lots of articles you can learn about but I will hold a talk about typography I swear, you are welcome okay one notice here, I just quickly skimed SEO I was applying a couple of months ago to another place and SEO question was one of the key one so actually it's not recommended to use H1 in this case because SEO all the engines are still relying on H1, H2 down to H6 so it's recommended not to use H1 for example to throw such message maybe different size SEO does not care about the font size you can use other thing but H1 is like there is no magic SEO is not that smart too absolutely so now I have the balance SEO versus accessibility I'm not going to be user friendly or I'm going to be on top of the page if you are not targeting SEO then that's fine it's supposed to be searchable by SEO it's a business decision yeah, it is business decision awesome more so you do it by function can you usually it's a team decision basically we always have a joke that naming is the hardest part of the problem in our current project we usually name it based on directory wise we name it based on the module basically what's the functionality of these components yeah it depends on the size of it for example you might have a menu that might be different sizes depending on the name so it's always about so if you are thinking about naming you need to think about who is going to read that directory after you like that naming is after you so you need to make sure that you have enough information to understand what this is even without reading the code just by reading the name so it's just maybe a judgment call on you and your team to decide that we do have a couple of unicorns in part of our code though there's a stuff that I call actually unicorn okay any more question yes how would you sort of pre-sets in your typography class so how would you you have font weights which are addressing the popular variations called the larger stuff like that so how would you like you have five different you have one atomic level of typography scaling elements and when you have the pre-sets so how would you approach it so you leave it up to the developers to you can choose what preset they want for a particular use case or do you define everything as a predefined pre-sets or any typography class as much as I love these guys I would not give them the responsibility and also put them into such a situation that we find that all so from design perspective these are all each individual one of these is defined by design and it's usually hard work so for example these actually in our last project we only define these in iteration 6 imagine how much stories we have already played and how much deep into development we already went because only at that point we realized we have so many places where we need to accommodate and the fonts were just not working so we had to redo this next to each other and say we have to scrub these, scrub the changes and we came out with these styles and we said when to develop please can you implement it for us and refactor and make it happen and but from that beautiful day everything was then fast and easy so but yeah it's something that you have to yeah as a design you have to define for an example case a label is supposed to have font size 12 all gaps and same font style is supposed to be used same font size is supposed to be used for say footnote or something size 12 but not all gaps may need to be same as well so would those go together as like one style preset or different style and you have to define this yes up front that's the point you never know everything up front so you don't and you name it as per the use case of that you agree on this so we we've called it style 1, style 2, style 3 and then we had a troubles because we had to remove style 3 and suddenly we had style 1, 2 and 4, 5, 6, 7 right so like dinosaurs and tigers and mouse is highly recommended because it's not sequence but it has to be retrospectively if anything at least I have never been able to predict future so that styles I have defined on the beginning were actually the ones that went live cool recap just a quick one so we are all employed right we work for some business and we also need to make sure that we make an impact and our work is actually then translating into some tangible things for the business itself and it's always good to keep that on your mind so I've created amazing table for everyone to understand when you are creating scalable products these are the things that are in it for you so for a designer when we implement grid it means we are faster and we have consistent UI developers can be really really fast with their development because they know exactly and fast they don't have to do the measurements and the code readability and the maintenance is much more easier business they develop products faster they have less errors they have a lot of bugs happening for components designers we implement changes faster I change it here it changes everywhere and the same is for product defined patterns of use interaction next time I know there is going to be a drop down or I know there is going to be a model coming up I already know how it's going to behave simple I already have I'm building my server reference library for developers read usability and maintenance of a code simpler and this is the best thing for product less costly I have a component I change it here it happens everywhere that's where the making sure that you are building religion with your components actually pays off literally pays off typography I have a phone system that I can go and reach out to I know exactly how to use it when to use it for dev speed and simple and cleaner code and for business it's about I have actually creative assistive friendly technology so this is it any other questions can I just ask hands up who came here for as a developer developers hands up okay hands up who is a designer hands up I could have guessed so also and who is here for product okay and who's the rest what are your like BA's what you didn't raise your hand okay okay okay awesome any other questions link to that she has prepared something beautiful for you guys so we have prepared a sample code which is actually our debut sign up page which is inspired by Google sign up page you can look for the code in github and there is also like a demo of this basically in in the hero club so you can see inside the code base how we implement components without implements typography and also as a bonus there is also responsive design so if you go to the github page you can see that we actually implemented three different screens for different sizes okay the github is a bit laggy but yeah so they are responsive back into that and you also put a style guide for different inside that you can play around with and see how it's basically set up cool that's it awesome thanks guys okay I think you just pulled it off yeah awesome