 Good morning. So I think that we are going to get started. Good morning, everyone, and welcome to this presentation. As you can see in the title, we three are going to be talking and doing a short demo as a workshop of our proposed collaborative flow between designers and frontenders. But first, let me introduce the speakers. We have Lara. There is experience UX UI designer here. We have Monica as a front-end developer, and also myself, Jose, as a front-end developer too. Let's get it started. And this is going to be our agenda during the talk. And there you have the cure to the slides so you can follow easily if you want your computer. We are going to explain the main or key idea that we want to give you today, explaining the problem that we want to face, and our main point to fix it. Then we are going to explain and getting two details, explaining the proposed flow that we want to follow. And finally, we will finish the presentation with a small demo workshop where you will be able to see the flow in action using some artifacts, demo artifacts, for both design and development. So our key idea and central point of our concept that we want to develop during this presentation is templates. Templates tends to make things, and especially when you are collaborating, really easy. But first, let's get some context. So what's the problem that we're facing here? The collaboration, collaboration especially between designers, or the design team, and the development team, especially front-end. And it can be dramatic at some point. And that drama can lead to frictions between both teams when developers get hard designs that they feel like they cannot implement in time, or maybe that when designers get to know that their design or their effort is not going to be implemented. So that can end up with unsustainable situations, delays, conflicts, or even failures in the projects because of this collaboration. But why is this a problem? We are going to give some examples for both sides, designers and developers. And we are going to start with designers. So as a designer, you might don't know how hard it is to actually implement your idea. So maybe you do an incredible UX or a really pretty UI that it's three times harder to implement than something that is very, very similar. Or maybe you don't know about the technical requirements of your idea. So maybe it's not doable because you have some technical dependencies or missing technologies or because the team, development team, is not having some special skill that is needed. Or maybe you just forget about designing some small items or behaviors when you are developing something that it's like designing something that it's a really complex feature or that has a lot of things to sum up. You maybe lose some details, and then the developers will have to guess those details. Maybe it's some hovering behavior, redirections, some transitions between two designs. But what about the developers? OK, so maybe you just, at the very beginning, just misunderstand the design. You don't get the UX idea of the designer, or you get confused when you are implementing something like the layout, and then it's not as responsive as it should or something like that. Or maybe you just have to recheck again and again because you don't have access or you cannot see in detail each value that the designer was thinking in each small detail of the implementation. So then when it's Q8, you get some errors that are saying, add some pixels here, like the pixel perfectionist. Add some pixels here or wherever in other place, some color. Or maybe, as we commented already, you just need to guess behaviors because they are not specified in the design files. So to sum up, the problem is a lack of communication and the timing in the communication, especially. So it's important that you are able to raise your hand when something is not clear in the development side or to check the latest changes on the very moment that they are done. Agreement between both teams, how things are going to be done, where, how, or even if they are possible. Definition of the flow, of the tools that you're going to use, the processes, how are you going to communicate. So in general, having a roadmap to follow. And of course, consistency. You have to be consistent between design and development implementation. So our solution or the main key point of our solution is templates and specifically matching atomic templates. And that will work as a starting point, defining the base, all the base foundations, components, following some atomic design structure. So both are always keeping this consistency. And that starting point is going to be reusable, iterable, maintainable, because you have that template. But it's, of course, always going to be extensible. You will be able to improve it on each iteration or on each project. You will be able to add things to it, to both of them. And of course, any other project, any new project that you start, you will get these two templates as the very beginning of them and base your implementation on them. So let's get to the workflow. And we're going to extend that proposed solution with a whole workflow that will let us go from those templates to actual products. The region, how it's going to start. We're going to start with the design system, that it's the developer's template, as we commented. And it's going to be containing all the base functionality that any project, front end project, might need. So it's going to have a theme configuration, as you can see here with the foundation, scholars, typography, spacings, that are going to be set as design tokens that are going to be used in all the rest of the design system. And after that, you will have encapsulated and atomic components that will have all that functionality, base functionality, that any front end project could need. And of course, it's going to be matching with the design. So now, Lara is going to continue with it. So now we start the worm now. I'm not sure how many designers are here in the room. Maybe you can put up. Great. I'm sure that the most of you have problems in some of the parts of your process with projects. So we try to solve this situation, try to, if you can, with the enemy, join with him. So we start to define a template where we use the same structure, the same naming of the different components that they are actually using in the design system. We organize the content in the same way that they normally work. So for them, it's more easier to find the different elements and make sure that all the things are in the same places that they have in the actual design system. So in this way, they don't have problems to understand things. Like I said, we structure this template in the same organization. We divide the template in foundations. With the foundation, we define the different aspect. The basic aspect of the design of a project. So the style guide of a new client have here the basic element, like colors, typography, scales, spaces, or these type of things. We divide the second part of this is the components. We define the primary buttons, for example, buttons like primary, secondary, things like checkbox and small elements. That makes sense itself. In the third part here are the patterns. Or the most of you know, it's a set of components that combine together to create a function, to take on a function. And then, page samples or regions like footers, headings, and these things. But the most important question here may be that always, if this template constrain the design. For us, this is no problem because when we start a new project, when a new client comes, start to work in both files. We start to define the design, the UI part, or in the case that this design, this project needs white friends. And we start to define basic elements, all the elements, all those elements in the template. If we do in this way, we have, first of all, a basic checklist with the most important elements that a client projects needs. So we can have a clear overview of all of the elements down. And after that, we can start to create improvement there. And we can start to have more focus in the hard part. So we can start to see more inflows in improvement than defined basic elements like defined colors of the things. Use this type of template provides maintainability. So we can make products much easier because we have defined the basic elements and we can reply in most of the pages then. Provides extensibility. So any changes, any new functionality that we need in a project, we can add in this template. And we can check in one project. And if we think that is something that we can move for the general template, we can do it. And we always, in this way, have a live file. And our system is always improvement. It provides consistency. So make more quality for our designs because we are always using the same elements in the same way. We are using the same buttons, the same patterns, and the same behaviors. And like I said, have continuous improvement. So we can scale up very faster and define new elements there. The latest thing that we were seeing and we start to rethink to doing this way, I'm not sure it's a case that you have in your company, but some of our project needs to work for external designers. And this is really hard for our developers because at the end, they don't know the way to provide us the best way for their designs. So if we can provide them this template, they can use a base to define all these elements there. And for our developers, it's more easy to implement it. It's a good point because I think it's more faster to create this project. And as I said in the first part, the more important thing here is the communication between teams and the collaboration. They have our developer, when we start a new project, always have access to the principle bar files here. So when me or my colleagues, like a designer, start a project, the first thing is to share both files to them. And they're always checking all the design. So in the case that we are thinking to create a new flow, a new behavior that they can't implement, they are always constantly checking this one. We have several validation meetings between the process, between the designs, and we are always checking these things. So in this way, we can have agreements, internal agreements, before show to the client at the end. And in this way, we can improve the delivery of the project and they don't have to do things very hard at the end. So like I said, we have a technical validation inside the team. And after it, we can show to the client. And now my colleague Monica is continuing here. Thank you, Lara. So once we have the valid design, what we do has a developer. So first, we need to set up our design system. We have a base design system, as Lara told us, where we can set up in all the projects. So it's easy even if we need to change something in the basic system, it's easy to change for and update in all the projects that we have. So the next tip that we did is adapt the template that we have to the design. This means that we need to define the style that we are using in the new design. For example, colors, fonts, typography are also adapted in the components. We have, for example, changes in the buttons, in the cars, all that we need in the new design. So to this point, to the workflow, we have some different important points. So one of these is the template. It's really important to define a good structure to the template, not only in the design, but also in the project that we are using to have a consistencies between the designers and the developers. So the new design is really important to have to be basic in the figment this template that we are using and the same that we have in the projects. The next important is the validate. We need to have constantly communication between the designers, between the developers to have validation, all that we are doing. The last tip and not the last important is the design system update. So based on the design that we provide, the designer provide us, we need to update our design and, of course, integrate with Rupal. So right now, time to the workshop. What kind of tool we are using in this workshop? So in the design part, as we are talking, we are using figment and in the developer patch, we are using tile wing for the styling, we are using lead for the web components, a storybook to show all the changes that we are doing, and, of course, Rupal for integrate all of components. And let's start with the workshop time. If you want, here you are another QR, where you can have access to the repository where we prepare everything for you in case that you want to set up your local environment and let's try. In this case, in this repository, you will find three different branch. We have one branch with all the design system, the base design system that we are using. We have another branch with the design and the last branch with some changes in the design that sometimes happens. So if you go to the QR to the repository, you will see a redmi. Then if you follow the redmi, you can set up your local environment. We prepare in that branch, we prepare all the atomic design system that we are using. The first thing is what is atomic design. In this case, the atomic design is we prepare, as you can see here, as you can see here, hopefully in the screenshot. We have the different elements which start for the more smaller component, like could be a link, a button, and then we have more bigger components, like could be a card or some different regions and so, so let's see. Here we are. Now, if you can see, we are in the repository when we have different folders and structure. So hopefully you will see here that we have a folder which is the design system where we prepare all base design system where we have in all the projects. Inside of the design system, as you can see, we have the different components that we prepare for this demo. In this case, we have, for example, buttons, cards, headline, image text. If we go inside to the folder, we have inside to the components, button component, we have the difference files, which could be the CSS for the styling, we have the GS for the web components, and then the stories. The stories will be for, sorry, I will close this, yeah. And the stories for show, for make a visual that we are, what we are doing. Also, we have the, the title has I mentioned before, we are using title for all the styling about the design. In this case, we have the, some different colors only, like could be the branch, the secondary color, and so on. Here, you can add all the plugins or all that you need in the entire wings. So if I go right now to the storybook, I will go here. So here we are in the storybook. If you can see here, as I mentioned, as we saw in the Visual Studio, we have here the different components that we have for this demo. We have here the buttons, we have the headline, the cards, and image text. In this case, this is only the base design that we have right now. Inside of the button, for example, we have the default button, and we have some different variants, like could be the secondary button, or maybe outline, and also the headline, where you can see the typography that right now is set up in the project. And for example, the default card where we only have right now, some image, title, and some text, which is only an example. And right now, I will come back to the presentation, and then I will continue with Lara. So now designers start to design a new project. New project is coming, and we need to start a new project here. It's not only have a good structure in this design template. It's more and more infigma, have a good structure in this software. In this tool. The first things that I said before is that we need to involve our developers team, well, developers in this case, because here we are with developers, but we involve developers and board PMs and all the members of the project there, because all of them are allowed to see all the process and can check there. And we need to have a good and clear and optimal organization in this design file. All of our projects have the same structure. We are working in it now because we are defining continuous improvement, internal continuous improvement, because at the end we are learning with projects, we are learning with type of teams, and now we decide to use the same structure. We are going to, I'm going to have a fast review here, because maybe we need another workshop to explain the structure of Figma's on projects, but we're at the end, if you see, we have always the design system file in all of our projects. The design system file is a copy of the basic one that they are using for their storybook. So for example, for this project, like the talk here, we are going to have the main file with the designs, with the UI design, and with them the component library and style guide that is the template that we use. Internally, we prefer to have a good structure of all of our files, because maybe it's not the first time that you open Figma and see a lot of screen with a lot of layout together, and maybe your brain can, pfft, and it's not good. So we try to extract the flows in different tabs. We secrete a status and extractor there. So in this way, always, always, they know where is the, that is a file, the file that is validated for the client. Or it's good. So the first thing that, imagine that it's not a project, we open our template in Figma and duplicate this template and have a copy of this in, please help me because I'm Mac user, not Linux user. So we duplicate the file and the first thing to make more easier their life, because at the end we are UX designer, so we need to take in mind the user and developers are user too, sometimes. We extract this summary where we start to define all the components or the element that are defined in our template. We have a fast link, you know, for then a fast access and they can go to all of the components or the foundation with only with a click. Click, click. Linux mode. In this, in this view too, you can see if we are, when we start to define and complete this and add element in the template, we stand to add like a check in desktop or mobile so they can have a general overview with type of component that define what types of element they have ready to implement it. Sorry, the link here is. So if we go to the, to click in cars, we can see the basic card that we are, we have defined like a general theme. Basis in it, we start to define the new cards with the look and feel with the new foundation that have the project. Now we move to the presentation again. So the second thing, we start to work with the design. Like I said, we work together with this template, we start to define a general layout in the UI file and then when we have defined the basic elements, we start to add this element to the template of this project. How we organize the designs and how we link the different things here to make more easier the life of them. We have a clear structure here in the sidebar and we always have in the handover section the designers that are validated for the PMS that can share for the client and the pages that they can start to implementing. And we always add notes here in general information and always have a link into this design template system and in the case that for example, we create a prototype iteration prototype in Figma to show them how we want the behavior of a menu. For example, we add here the link too. So they always know where is all the information. So this is for example, the design system of this design. You can see that we start to redefine elements like colors to add the principal element, the principal color of this project, the secondary color or complementary color, the typography that we are using. So all these type of themes are defining here and all our developers can get when. So here you can see that in this template, we start to move and define the cards for example in this case that we apply in our design and we add these type of cards in the components in this template. Now Jose is going to finish to continue. Okay, so yeah. We already have our base design system set up hopefully in place. So also the design for our new project with matching design template that has already shown. And now we are going to start to adapt our design system in order to make it match with the new design and to be able to build the page that Lara showed. So if you want please check this QR that is going to lead you to the second branch that we have that is automatically going to have everything implemented. We don't have time to go step by step here. So if you want to get it and you will be able to see everything that we have there. All right, so this is going to be our steps to follow here we are going to start going back to our design system that we have already set up and of course we are going to be checking Lara's design and then we are going to start updating our design system. So we are going to change design tokens as Lara said some colors has changed and then we are going to change the component styles to make them match with the new components like component by component because we have the template and then we are going to add new component variants or new functionality that's needed that wasn't in our base template so it's that extensible part of it. And in the end we are going to explain how is this going to be actually integrated we're not going to be in detail there because it's not the purpose of the talk but we're going to check how it's integrated and how is that going to enable us to actually use the components and build a page in Drupal. So yeah, I'm going to show you that was the first one. So first of all, what we are going to do is as a developer now go to the template that Lara provides us and of course we're going to start with the foundations and as Monica said we had a tailwind config file that it's going to have all these foundations values. So if we go to our tailwind config here in the new branch you can see that we have changed the colors we have added a new font family for example that is Germanist and we have set up of course here it's just a few values in a real project it will be lots of more values also spacings also font sizes or whatever. So after that we will be able to have in our design system directly all these colors change. So this was our first one and if we go to the secondary button sorry this was our second one this was our first one iteration with it only the template and if we go to the secondary it was having some blue demo color and now if we go here as we have changed here the secondary color and it's matching the colors that Lara has defined right here in our sorry in our colors foundation section right here this one you can see it but I assume maybe exactly this one here we have copied to the other place of course we will also able to set up all these gradients or yeah scale of colors but for example we just move the secondary one so that's what's enable us to use or automatically update our template colors. After that we will go component by component and in the demo we are going to show you how to do it with the cards so if we go to the component section we get into the cards component we will be seeing the new design that we have from Lara and of course we can automatically as FIMA provides get all the values and CSS values here and in order to use them in the styling side of the component so once we check this we go to our DC card as Monica also showed component and we will be able to just change the markup that we have here in order to restructure our card very easily because you already have the parts of it defined so it's just maybe moving something to the top or something to the bottom or maybe something inside of other thing or styling something with an absolute position so then we go to the card CSS file and start adding here all those yeah style values that we need always using our tailwind configuration that it's automatically going to apply all the design tokens that we have defined and after that as I commented we need to actually use this component in Drupal so in order to do that we have templates that are corresponding to paragraphs that we can automatically use so here for example we are using a DC button that it's one of our components that it's a secondary one and we are also using a DC card generally that it's at the top so the DC button is inside of it that it's defining all the media so the image and some text how is the text going to be and so on after that we will be going component by component as I said we're not going to demo that but you will be updating component by component following just this structure that we have here in Figma and the same structure that we have in our design system and when you do that you will be able to see all the changes applied in your storybook so you can isolate those changes and see them right here for example the new font as you can see here also the size of the font you can see the new card with all the styles that Lara provides us and a new variant that is something that I didn't comment but as you can see we also implemented here a new variant passing as a parameter that it's going to be compact variant and it's the gray one so yeah that's practically it from my side and now we are going to continue checking as I said the last page that the page that we implemented thanks to that integration with the paragraphs so here we are we have the design that Lara provides us of course we are not going to explain how to actually build the page because we don't have time but yeah it's practically matching the design that Lara has here and now finally I'm going to let Monica continue and finish thank you so sometimes in the project happens that we have chains in the middle of the project so changes are coming so in this case if you can see here we have now a new design we have a new paragraph here with some properties here and also we have a new card new another new paragraph here so we need to update up to this point the design system we need to update our templates we need to make some change I will go quickly about this so here we have the last keyword with we have everything prepared there which is in the third branch where we have all the new variant that we create the new color that we set up or everything that the change that we need to do so in this case we need we check first as we follow the workflow that we explain in this presentation we check the design once we check the design we see that we have different I will go to the design here we have new colors here as you can see we have the font is changed and also the color of the font it changed so we need to do it so in this case we go directly again to the tile wing and then we change and update our design system first we need to update the design system in this case we update the colors we update the font family we add the new property for this headline and also we have a new variant card which is with another color and of course we need to integrate with Rupal so in this case we update the design system as I told you if we go here to the design system as you can see now we have a different font type a different font family a different colors and so we have another property here and in the card if you can see here we have another new variant card which is combat highlight that match with the design so I will back again to the presentation so the conclusion of this workshop is we have three important points to this important point which is the first is stability we need to have the designer and developer we need to match the design that Lara in this case provide us we need to match with the atomic design that we are using in order to have consistency between the designers and the developers of course the most important thing is the communication if we don't have communication we don't know if we have some changes if we need to create new variants or if we need to update something in our projects it's really really important to have a good communication between your team and of course the structure we need to follow the same structure not only in the designer also it has a developers because the same structure is easy to go directly to the designs see the check the design check the colors check the new components and then we go to our design system and then update our design system with all the new changes that we have and of course the structure have really important thing that is maintainable and reusable we can maintain more or less easily and we can reuse in all the projects that we can prepare that's all thank you so much do you have any question or something? my question is do you deliver the design system to your client as part of the delivery? Hi, how are you dealing with multiple projects because I think your design system was built once and how do you deal with a lot of projects? How do you manage it? Like, you mean like yeah we have the template as we commented yes, even on the dev part as the design part because I think you would do not just copy and paste you use something as you change in design systems your primary design systems and after it's applied on your project design systems how do you deal with this? OK, we have a theme for Drupal that is automatically having the design system template that we commented inside of it and then we just when we started a new Drupal project we just cloned our theme in that Drupal project so we have everything already set up so we only have to set up the first time and then there as we commented we start adapting it so Lara provides a new design and then we already have everything there so we just have to start working on it and we have to update the design tokens or the components or whatever but we still have all the functionality that we keep in the same place and we extend and we improve project by project Next is me so I have a couple of questions but mainly you mentioned that this needs maintenance and I was wondering what are the costs or the time needed from your design team and frontend to maintain this I know for example like in-house design systems like Airbnb would have like a team of five persons maintaining just the design system so how does this work for an agency and also what are the pros and cons that you think comes from building your in-house design system versus using an open source design system like material design which is well supported on a frontend level there's a team in Drupal there's already a React community so like why did you decided to build your own design system versus adapting our already existed open source design system So for the first question So for the first question Sorry, can you talk into the mic We're going to be streaming, sorry Well for the second I'm going to start for the second one For the second question I think is for us we prefer to start to define our own design system because for us it's our product and we can make more improvement and we can do the things that we don't we don't have to have in mind the things that are done so we want to create new things and define new things the asset in the needs and in the things that a client needs in this moment so we want to be free in this way and we have the option to work together for our team so we have this possibility too and the first question now I forget, sorry How cost effective is for an agency to maintain your own design system Okay now in this moment we have three members in the team so maybe if this increment we need to add more members in the team but now in this moment we are allowed to do it It's not a problem In the design system part for the developers we are also rotating so we have maybe one or two developers that are in charge of checking that everything is going well but then all the developers in the company are able to point out that they found something in some other project when they are applying the solution and at the issue in the project and then it's going to be fixed even by them if they already fix them in the actual project so that's one of the points that we commented so enable because of that because we are using that template in every project so if you find in any project you are able to go back to your template and update it There's one question from the app is the FICMA document that you displayed just now is it publicly available or Yeah it is and it's on the links I can go back to the very beginning where you can get access to the slides so all the links are inside the slides and you can click on them and you will be able to see the resources that we provided You can access them Yeah we can We can change it Any other questions? I'm running to you I just wanted to check how you're dealing with the version of the design system when you go through several design iterations before the clients actually sign off and how do you know if there's a new version and you've not implemented the previous version yet I mean in general how do you deal with the process For development we use of course Git so we always have versions tagged when we are changing it so in the design system template we have tags every time we increment our functionality and on every project we also have tags when we are changing things so that's a Git is the main version and for designers the same Figma provides us a version history so we always save the date of the version and we don't have we always have a history of this version that the client when the client starts to do changes we have always a version history like a background and we can recover it then in files and in the template and we out of time I think you guys can catch him at the booth you have like final words Thank you so much for joining to us if you have more questions or comments please invite you to go to the 1x internet bot 10 see you there, thank you again