 First of all, a warm welcome to everyone. It's a nice day in Nashville. Conference is going on and coming to an end. So let's speak today about design systems and how to introduce this into your team. This is the first time I speak in the United States, so it is a big pleasure for me. And I hope I will learn and you will learn something today with me. Let's start. First of all, a few words about me. My name is Anton Starverov. And I'm working as a design system architect in a young agency in Switzerland. So yeah, this is my official job title and I'm proud of it. I'm really working on design systems on my daily basis. As I said, I'm working in a young agency, but we are working with the biggest clients in the world. And this allows us to focus on design systems and to get to know our clients on a deep level. We are working with Daimler, Novartis and Roche. Daimler is one of the largest car makers in the world and Novartis and Roche are largest pharmaceutical companies in the world. You can imagine, for example, Novartis has around 300 websites and every website has its own design, but all together they form a really big and large and scalable design system. So first of all, let's quickly look on our agenda for today. First of all, I would like to give a quick introduction on what design system is, what parts of design system and what was a quick history in the past which allows us to speak about design systems today. When let's talk about teams perspective and how to integrate this process and how to integrate this design systems vision into your team, not only into your head. And then let's quickly talk about how we can work together with a content management system because these kind of two separate worlds, one is about design, another is about content, but in the end we should merge them somehow to build our product. And last but not least, let's quickly talk about future and what could be possible in the nearest future in the design systems world. First of all, let's talk about design systems. So let's look in the past. And as you can see in the past, actually it was not that long ago, we have no styles at all. Our sites was ugly, but we worked and we actually gave an access to the content and information, but it was no styling at all. That's why we moved forward and we invented CSS which allows and allows us to make our pages more colorful, more bright full, but still we are quite ugly, right? And CSS came to life, but still it's only gave us some tools and power to make our code more flexible and reusable, but still there is no system behind of sense. It's just a code, it's just tool allowing you to simplify your code, but it's not a tool to make your system consistent, scalable and maintainable. That's why we started doing style guides and came to so-called style guides era. In this era, we started thinking about our design consistency. We started reviewing our color palette, our typography and so on. So at this stage, it's not only about styles, it's not only about HTML at all. It's more about design now. It's more about visual representation and about consistency of our elements. So what is a style guide? A style guide, it's a simple thing. It's actually very basic set of rules which defines our look and feel. So actually it can be typography, grid brand, icons and so on, but this is very abstract thing. It's mostly about visual part, not about content itself, not about system behind. It's just about our style, look and feel, so-called. And when we talk about style guides, we usually take in mind colors, icons, grid brand, spacing probably. So you can see this is really atomic things. It's really abstract styles. There is no system yet here. That's why we came to another era, so-called component libraries era. Things like pattern lab, fractal and other component libraries were developed here. And these helped us not just to think about styles, but also about behaviors and functionality behind our components. So component library is a different thing from style guide. It's basically a set of our functional components. Not about, it's not about our styles and look and feel. It's about our functionality and about our code actually snippets we are going to use in our system. So this is basically a storage. It's kind of a library of your patterns, not about your styles. So examples of parts of component library could be such components like item list, slider, gallery, hero area. But as you can see, it's not about styling here. It's more about functionally. It's about pattern we are going to solve. Then we started thinking not only about visual part and not only about functional part, but about the whole thing we are doing. And at this point, we started talking about design systems. And design system, it's not only a visual part. It's not only a functional part. It's actually everything mixed together. And this is actually a system, a set of standards, principles, documentation, of course style guide and pattern library all together to give us a system and consistency. And of course, there is no sense to speak about design systems which are not living. That's why I put small word living here because design system, it is always living system. And actually, when we talk about design systems, at the beginning, most of people can think that this is about design. But actually it's not. That's why I highlighted the system word larger because actually the main word here is the system. This is the system of our design. This is the system of our principles. This is the system of our components and how all these should work together and how teams should work with these tools together. So basically design system is a set of rules and connections and principles. It can contain motion guidelines, taxonomies, terms. Terms is very important to have a shared language. So altogether design system consists of style guide which defines our look and feel or look and feel of your client. Of component library which defines a functional and behaviors part of your library. And design system itself altogether describes the processes and rules and principles how to build all these stuff together to actually deliver our results in product because actually what we are going to do we need to build the product. We don't need just a style guide. We don't need just a component library. We want to build a sustainable and maintainable product in the end. So if to look back as a big picture in before it was mostly about content first. It was like ugly websites but they were very contentful. So it was content first era but it was quite ugly. That's why we came to another big era kind of design first. We started doing style guides, pattern libraries and so on. But at this point we kind of lost part of content strategy of content first initiative. That's why it didn't help us a lot. And today we are proud to speak about system first approach when we talk not only about design not only about content but about both of them together. And we are happy of course about this. In the future we can see kind of next generation of design systems. It's a kind of systems which are not describes only, which not describes only one particular design and approach which are not built only for one particular product but can serve a multiple design systems. Like in this example you can see a set of components which can work in different look and feels in different environments. We can talk later about this today. So let's make a quick recap. It was a long way but today we can talk about design systems and in the future probably we will talk about common interfaces as the next generation of design systems. But at least today I hope we are at this point and we can not only think about design not only think about content but think how we can deal with both of them. So now let's speak about team's perspective. So how design systems can work in your team and what challenges can you find starting to adopt in this approach? But before we go deeper, may I quickly ask who is using actually in your daily business a pattern lab or fractal or whatsoever? Can you raise your hand? Nice, nice. So let's start from this nice picture. Yeah. So first of all let's speak about team. When you first start talking about design systems you can imagine it's kind of a tool for design team to solve design problems. But actually it's not as I said. So when we're talking about design system in your team we should focus on the whole team and we should take in mind and take in account the whole team not only design team. As this quote from Gina N from Salesforce correctly said think about your design system who is involved actually. Design system it's all about design content and building products. So probably you are going to involve your content producers, your design team, your front-end development team as well as project management team. Please do so. Please don't just talk with your design team because in this way it will not work for the whole product. It will only help for your designers but you will still miss all the parts of it. So first of all it's a team play. When you are going to do successful design system please take in account all team members, all stakeholders. Second, usually when you start building a style guide or pattern library this is a kind of fixed time project. You can just plan it, schedule it, build it but then it's very important to maintain it on a regular basis. So when you're talking about design systems it's very important not just talk about short term project which can be done. It's actually a product which should be maintained on a regular basis which should have regular releases. It should be updated on your daily needs. So to make a successful design system it's very important to change your mind a little bit and to shift your focus from only doing projects to maintaining the product and to taking account all the requirements and processes in behind. So second it's a product mindset. Please don't try to build one design system once for a long time. Please work on it constantly and on regular basis. Third thing here it's about shared language. It's about naming and naming conventions. If you will start building actually design systems you can start using some language but most probably your design team and your frontend team will use different words to describe the same things. Like if you will start using atomic design terminology for example your content producers and your designers can probably misunderstand each other because it's not clear what is organism in terms of content production. What is organism in terms of design. So please don't try to do that just talk to your team understand your personal needs and invent and build your own language so all your team will understand what is discussed in the right context. And if you will come to your client probably you'll find that your client speaks another language so please take this also in mind. So your client actually it's one of the key stakeholders of your design systems. So first it's a shared language. It was quick principles about working in the team and let's now go deeper into technical application and let's now see how design systems can work together with content management system. So initially we have some kind of content storage. This can be in our database. This can be tools like gather content or this can be our Drupal instance. Doesn't matter. We have our content somewhere but on other hand we have our fancy and modern design team who is going to produce nice looking designs. So we have another part. We have a living style guide or set of mockups whatever you call it but actually we have a content and we have a design and these two things kind of separated and created actually by different people for different needs. But what we actually need to do finally we need to tell some story. We are our client. We don't want just to store content. We don't want just to create a nice looking designs. Actually what we want to do we want to tell some story. If I'm a client and I have a product I'm probably want to describe and talk about my products. So I'm not just designing my products. I'm not just writing content for my products but I want to tell some stories. I want to highlight some features. I want to show some pictures of my product and all of this this is both together content and style guide built together to tell our story. So we need something to do this actually. We cannot just take content. We can't just take style. We need something which will help us to merge them together to tell our story. Business can be called kind of building blocks which is a kind of intermediate interface for your content producers, for your clients to build a stories in the way business needs but still using content and still using styles from Lean Style Guide. And altogether forms kind of design system in behind because content and design altogether together meets in very reusable maintainable building blocks which can be used by content managers and supported by design and development team. So let's look at an example which probably makes it a little bit clear about this separation between content design and what is a building block actually. This is a simple interface from Drupal admin interface. It's a part of a node page and here it's a one field. In this case it's a paragraphs field containing one paragraph of type video player. So this is actually our building block because here will be our content managers work to create a content or client will go here and create page on his website. But actually let's look deeper what we see here. We have actually video which is a content and we have also some styles here from the Style Guide. In this case you can select a view mode which will, so you can select if you want to show this video as a download button or as a video player. But also you can select here what kind of style do you want to give to this. You do want to make it light or dark because depending on the actual video file you may want to give a different behavioral look and feel. So on one side we have a content which is stored in our system but on other side we have some styles which will be applied to this content. And a place where all this happens it's our building block. In this case this is a paragraph containing one reference to media file and some options to manipulate actually elements from your Style Guide. And in the end you can build different variations of those like you can build video player on the light background or on the dark background or you can show the same video file as a button. And as you can see it's pretty simple example this is probably what we do all on regular and daily basis but actually if we try to look deeper we'll see that actually here we have a clear separation between content and between Style Guide. On one hand we have our content which is here represented by video file but on other hand we have styles which will be then applied to this video file. And then you have a really powerful tool to build a story you want. So if to talk about particular modules and tools in Drupal system content is mostly described and represented by entities and fields of course and very important here to mention entity reference which can help to model really complicated data so one entities can refer to another entities. Visus actually works really well in Drupal and I don't want to go deeper here. On the other hand we have tools helping us to maintain our Style Guide or Living Style Guide. We can now use Fractal or Pattern Lab to store our components together and then to attach to Drupal to building blocks or we can just write CSS, write in theme or we can write TIG files, write in theme or in these pattern libraries. But as you can see even here we have a separation between content and Style Guide. It's different worlds and different terms. So please let's think deeper about all of this stuff. Let's try to separate from the beginning and it can give more power, more flexibility and more maintainability. So actually what we're going to do, what we need to do in the end, we want to build a story. We can use these modules to store, to describe our content. We can use these tools to describe our styles but to build our story it's not enough. That's why we have a lot of modules in Drupal system helping us here, these all forms design system all together in Drupal world. Let's go quickly one by one. Modifiers, let's start from the other side. Okay, let's start from paragraphs. Paragraphs is actually entity, custom entity type and widget but actually this is mostly used as a building blocks because usually when you're creating your page consisting of many paragraphs, you're usually creating some fields on them to change, look and feel to change your Style Guide but of course you need some content in them. So paragraphs are kind of essential building blocks which are trying to mix content and style all together but it's not always work well, that's why we have a lot of, and other modules and approaches which can help to separate these two worlds but to manage them in the nice way. UI patterns allows you to connect your components from Fractal or Pattern Lab right to your Drupal system. Layouts can help you to put your actually content in some layout. Bricks can help you to control this layout on really atomic level like you can write your blog post and inside your blog post body you can put your components in the way you want and you can control on very atomic level and you're still working on content not on the layout. ViewModes allows you to actually switch representation for your entities and for each entity you can say I want the same content to be displayed differently. So this is actually ViewModes, it's built in Drupal core and this is essentially basic way and most easiest way to kind of merge content and Style Guide because at this point you can control how the same data can look differently. Modifiers allows you to display the same data in the same ViewMode but slightly differently like you can change your background or you can change a color or you can change a theme and so on and so on. Like in my example with video player it can be light and dark, it can be a modifier. And entity reference here, you can see that entity reference is special, it lives in both content storage and building blocks section because on one hand, on one side you can model data using entity reference, you can define your structures one entity can reference another entity kind of complex data models but also you can use entity reference to nest your components together, you can use entity reference as a building block so you can put one big building blocks in another building blocks like you can nest paragraphs inside paragraphs and these can be done using entity reference. So as you can see Drupal is now evolving fast and they have a lot of tools helping us here it's a bit of mess because it's not obvious what to choose but please try to separate these three things it can help you to choose the right tool for your needs and to maintain design system and content system all together in the way you want. So let's now quickly talk about future and what could be possible in the nearest future and how design systems can evolve. First of all let's look at several existing design systems and I just made this example to give you impression what is happening now and what can be done later. This is a screenshot of tabs component from material design system by Google the same component from carbon design system by IBM the same component from lightning design system from Salesforce and the same component from Polaris design system from Shopify. So actually these four design systems are quite mature, quiet, a lot of components were self-complete, were used in a lot of applications and were supported by largest companies in the world but if we just look at this screenshot it's just tabs, right? So it's not nothing special about this component it's all the same component it's just slightly different design. So a lot of companies working now on their own homegrown design systems but actually if you will look a little bit deeper behind the scenes where a lot of the same functionality between those systems. So in the future probably we will see kind of common interfaces is kind of tabs component which can be built once and when reused in all design systems. So this kind of form a new design system of a new generation which can support and serve multiple design systems which can be reused through all design systems and this is especially useful if you're working in design agency and you have a lot of clients and each of your client have its own design system and you don't want to invest a lot of time because you are not Google and not IBM and you just couldn't do this. So why not to invest time in these common interfaces? Why not to build a tabs component once and when just customized, look and feel per your agency? But this requires actually a bit more research and thinking about the whole stuff so you should clearly separate what is specific for each client, for each design system and what is actually generic and can be reused throughout the whole systems. That's why here you should think about functional generic components which are design agnostic and which kind of interface first but not design first, not content first. And as you can see here where are two directions one is a vertical direction and a lot of companies working now in this direction on their own design systems but in the future probably we will see this horizontal direction which will allow these companies to collaborate to each other and to establish the reusable components. And finally, I want to give you some examples of what I'm working, what I personally working right now on these reusable generic components. I built these two things in my agency to support multiple clients. One of those is a slider, another is a gallery but actually each of those is just a package. Yarn or NPM package containing very generic interface. It's kind of basic styles needed to give you this functionality, not styling but functionality like with arrows and slider or like with grid and gallery. And it also gives you a tweak file which will help you to output and render your data and the key thing here it uses data attributes. So it's kind of defines interface between your tweak file and between JavaScript file. So it's very generic and it's very reusable because of that. Of course it will give you some JavaScript which supports functionality not styling again but only functionality like this slider it's about sliding and gallery it's about showing your media files in slide box. And of course it will give you configuration in this case this is a configuration for Fractal but actually it will be the same for any other system. This configuration just defines what these components expect, what kind of data and what kind of configuration options it allows you to do. Like a slider for example can allow you to put several items on one screen or only one item on screen. It can be infinite or not infinite and so on and so on. But this is all can be defined once and when just configured per each design system, per each client need. So here we can talk about common interfaces like for this slider and for this gallery doesn't matter where you will use it the interface will be the same. The data for these components will be the same. The only different would be a style and your configuration for these objects depending on your design system need. You can use a Yarn or NPM or use it as a Git sub module to connect to a project. It will give you a way to update and extend instead of copy-pacing. And of course you can customize on any level so you can actually extend or completely rewrite all styles. You can import big file or completely rewrite big file. You can do the same with JavaScript and configuration also extendable but since it's interface it should be compatible. Here are links you can see with working examples. You can even try in your own project. It's since it's very generic components where is no dependency on any CMS or any pattern library. Actually it's just about interface and it's pretty extensive. Finally let's make quick recap what we learned today and what we talked today about. First of all, we talked about design systems and we followed away from now styling to design systems era and kind of moved back because now we're not only thinking about design but we're thinking about both design and content all together to form a system. When we're talking about teams, first of all it should be a team play. It should not be only a design team. It should be design team, development team, project management team and content production team and even client should be involved to give you successful maintainable design system. It's important to shift your focus a bit to the product mindset so it's not only a project which will be done once and then became obsolete but it will be well maintained and it will live in your ecosystem and it's important to establish a shared language so all your team members will understand each other and this design system will be straightforward and clear for everyone, not just for design team. When we talk about integration with content management systems, it's important to differentiate content and design. One design system, it's about design and system behind design and another one content management system, it's about content and data models. So please don't mix them together, try to separate and then use another tool like building blocks to deal with both of them. In the future, we probably will see a trend as functional behavior components, not just visual components. As you remember this example with tabs, it's living in various design systems in the world now but actually it's absolutely the same functionality behind. So why not to share with knowledge, why not to share with functionality using common interfaces and then just customize visual part per unit. And in this way, we will probably see horizontal direction instead of vertical direction so we will work more together and companies probably can work more together instead of just living in their own design system and improving only one system. Thank you. So thank you very much for attention. This was my experience and my vision on what we have today, what we had in the past and how can we and what is possible in the nearest future. And if you're interested in these two components, you can go to these links and see how it works and try for yourself and let me know and we can work on them together. And now I'm open for the questions, if there are any. Yarn is the same as a composer. Composer is a package manager for PHP. In the same way, yarn can manage your frontend dependencies but the idea behind it is the same to simplify a management and dependencies between a lot of components in frontend world. So in our case, it's about components and patterns so you can build a large scalable system. One components can depend on other components but you still can maintain this in a very good way in a large system. So it's kind of composer but for the frontend. Yeah, of course. Of course, it's very important to share your knowledge and your components library to the whole stakeholders, to the whole team. We particularly use a fractal system. It's a component library built on Node.js so you can build all your frontend independently from Drupal. You can show how it will behave, how it will look like, you can even change and update it and you can send link to the client. And when separately we integrate this style guide describing all your components to the Drupal. And actually the same document we are using not only for actual component storage but also for documenting them so it can be useful for design team as well as for content management team and as well as development team, of course. So, yeah, please. Actually I can just show what we are doing internally. You will probably, it will be the best answer, right? This is one of the examples we are using in our agency. This is our base distribution and inside Drupal distribution we have this static living style guide. This is run by fractal component library and it contains all components we have so we can show this document, it's static, it's completely static. I mean, it's living style guide but you can generate it as a static files and then you can store on any storage and send link. And here, for example, you can see this atomic gallery in action. This is a, this GitHub repository directly connected to this style guide and it will give you all functionality right out of the box. You can see here how it works and you can see here in the bottom some details about this particular component like HTML code or tweak code or interface which is expected by this component like which type of data you need to pass to this component. Also you can write some notes here, like here. So it will help to give some documentation and guidance how to use it, how to integrate it and how to update it. So this is actually what we show to our internal team and this is also what we show to our client but different components, different purpose, some mostly for internal use and other mostly for client to show actual look and feel of his product. Yeah, it's now in theme. Yeah, as I said, this is run inside Drupal theme. This is actually a living style guide. It's a set of SCSS files, tweak files, JavaScript files, living inside theme. It's directly connected to Drupal. You can update this style guide and the changes will be immediately applied to Drupal. This is the idea, so it should be integrated. It should be automated. Otherwise it will not be living style guide. Yeah, probably I will just show how it's built. For example, with this atomic gallery component it's just a folder containing your source SCSS file, your JavaScript file, your tweak file, and your config file. And in this configuration file, in this case, this is one for Fractal, you can just describe what is your component. In this case, I'm saying this is a gallery containing items and each item has title, thumbnail and type. And it can be an image, it can be a video and whatsoever. And then this data is used in this style guide to give you default content, but there are also advanced ways to do that so you can provide dynamic data, not just like this, but this is the most simple way to do this and it just works. Yeah, actually if you open these repos on GitHub you will see all of these right in there. For example, this atomic gallery component, you can see all files here, one defines styles, another defines this interface, a part of common interface. This is JavaScript, which you can just connect some library. So you can just go through it and you will probably see what's happening inside. Yes, please? So someone is coming up with some components so they have to package it up to be recognized by yarn. Yeah, so here you can find the package JSON file. This is actually nothing related to Fractal or nothing related to components. This is only related to yarn packaging system. So here you can just write file like this. You can say the name, version, and some dependencies, like here I am using Bloom Gallery. And this is kind of a package description. And then you can give this description to each of your components and then your components can work with each other. But it's important to take in mind that this is not just a library like JavaScript library, it's a self-containing component. It contains all styles, all JavaScript, all tweak and interface so you can just install it and it will work out of the box because it's self-containing component. It's very generic and it's self-containing. Besides the ones you talked about, what should I do? Basically you can find plenty of them but mostly it's libraries like JavaScript or CSS libraries. This way of shipping and distributing components it's kind of a next step for all of us. Yeah, it's a good question actually and ideally it should be so generic so it doesn't matter which framework you will use. As you can see this configuration file with interface it defines just data which needed to be passed in this component. And at this point it doesn't matter what kind of framework, Angular, View, Tweak, Fractal, whatever. At this point it doesn't matter. In this particular case since we are using Drupal and Fractal it's a Tweak template here and this configuration but why not to store here also Angular files or Vue.js files. It's still the same component, it's still gallery, it's still the same functionality, it's still the same interface. So yeah, I think there is no borders and there shouldn't be borders in this way. It should be generic. Yeah. Yeah, yeah, yeah. Let me back to the slides quickly. When we talk about things like foundation or bootstrap we actually talk about where it is big picture somewhere here, yes. So actually when we talk about foundation and bootstrap it's mostly not component library, it's mostly a style guide actually. It gives you set of styles and components but it's a pieces of markup where is no actually component behind it you should copy paste markup and then apply styles. So actually bootstrap and foundation, it's mostly a tool set and toolkit to build your style guide and parts of your component library. But when we talk about components here we are not talking only about styles. We're talking about the whole self-containing components which can just work and functionally work not just give you look and feel. And you shouldn't copy paste markup as I said about common interfaces. It's very important that you can import component, configure it and run it without copy-pasting markup and so on. So it's essential difference between style guides and style frameworks like bootstrap foundation and component libraries like pattern, lap and fractal. It's not just about styles, it's about the whole thing. Yeah, we can actually, and this is probably next step when all of these frameworks like foundation and bootstrap will reuse some functionality but give some different styling, as I said. So yeah, it's a broad topic. Yes? Probably years. So actually right now I'm mostly working on this generic functionality and I'm trying to mix several components together. It's not only about styles, it's about everything. Like let's just look at the example. As I said, we can have this generic gallery component as well, we can have this generic slider component which will just give you a slider with some basic navigation and buttons but no explicit styling. And then you can mix components together, not just change styling, but you can change behavior or merge behavior. Like for example, why not to put a gallery inside slider or even crazy? Why not to create a slider of galleries? Like in this example, this is a kind of timeline of events. Each slide contains one event and each event contains a gallery. And you can click and see how it works. On each slide we have some data, we have this gallery attached but this is all live inside slider and slider can slide these galleries. And this is kind of example how you can customize or extend. Since this is very generic you can use for your particular needs and this particular example it's just, it's just 30 lines of code. Here I'm just iterating all other events in timeline defining what I want to have on each slide. Here I'm giving title, description and including gallery from generic gallery component. And then I'm just calling slider component this generic component and passing all items in there. So, and of course here you can do some customization for your styles at this point. So this is kind of a new component based on top of two generic components. You can customize style, you can customize behavior or you can even merge behavior of two components together. But this is all only done if we're really generic and reusable. Yeah, so it's important to write a good documentation. Right now I'm working on it. Right now it's very basic like how to make this component work but also here I will give more details how you can connect this component, which interface you have and how you can change its behavior and merge to another components. So it's very important because when you're talking about design systems it's all about how to build, how to connect components together. It should be well-established interface and after that it will just work like here. As you can see, gallery works inside slider but we are not kind of... Each of them doing its own job and it just works together without any JavaScript. Yeah, yeah, basically you can but this is not in the component itself. It should be done in your particular project, in particular kind of design system. So we should be a new component or this should be a settings of your theme actually in your project. So you can just import this component and then modify variables outside of this component in your settings file, for example. So thank you all for your questions. It was quite hard discussion. I didn't expect that but that means it was useful, I hope, and you learned something and I learned... Thank you, thank you. Of course I will put a link right to the session announcement and also in the YouTube as a comment. So yeah, feel free to give you feedback. Please evaluate my session. I would like to work on it more deeply and make more sessions on this topic and your feedback is very appreciated. Thank you all and have a nice, closer session.