In this post I&#39;ll try to organise my thoughts on the Design System concept as a system serving a product.<h3>A Design System definition</h3>Unfortunately there is no standard definition of a Design System. As this is something more abstract and evolutive than tangible and definitive it is difficult to make an universal vision. This is also why this area is so exciting. We can make our own path and share our experience.In this post I will talk about Design System as a collection of shared patterns and practices that enable teams to build better products faster by making design reusable.So, now we know that we cannot make a universal definition of a Design System. On the otherhand we can say what a Design System is not. I heard a lot of people using the term “style guides” and “pattern libraries” in the web industry to define Design System and to be honest I find it problematic as both are only solutions or parts of the Design System but not the Design System itself.This is a shame that a lot of companies took the Design System buzzword as THE solution to resolve almost all of their product interface’s problems and start to create UI kits and styleguides because others are doing so. Is this the right solution? I don’t think so, at least not for everyone and not without solid foundations.UI kits and styleguides are both great solutions to go faster on creating interfaces in an ideal world where the plug and play works each time as expected. We all know that in the real world there are a lot of parameters that will affect this plug and play part (new features, marginal ideas, misconceptions, misunderstanding…). Those parameters are most of the time human issues that can come from a lack of communication, a misunderstanding or a lack of collaboration between people. All those issues cannot be resolved with UI kits and styleguides and cannot be resolved in the same way in all companies. It could be by creating or improving workflows, foster collaboration with handoff process, include technical stakeholders at the beginning of the conception… There are an infinite list of solutions and all cannot be applied everywhere.<h3>When it starts then?</h3>For me a Design System exists at the moment of the product conception. When the idea of an interface emerged a system is already in place even if this system is not working yet.It&#39;s like having a bike without wheels. It&#39;s still a bike, but you cannot ride it yet as the system is not complete. All you have to do is finding a way to get wheels and adding them to complete the system. No matter how you do it, if it&#39;s working, this is your solution.We can reflect this idea for a product. All products have there own ecosystem and workflows around it. The most difficult thing is to find the solutions to go from the concept to the product and this is where a Design System is involved.In the schemas below, I’ve chosen the term Concept instead of Design, and System instead of Design System to avoid all wrong interpretation. I’m convince that all of that should be totally department agnostic to make sure that the goal is the product and how to serve it. Unfortunately I’ve met a lot of people thinking about Graphic Design or Drawing when they talked about Design. On my side Design is better to define conceptualisation, it doesn’t matter if you’re a developer, a designer, a mecanic or a musician.<figure><img alt="Schema of a project as if it is a solar system or a dart target" src="https://cdn-images-1.medium.com/max/1024/1*QbkFkmCA3UGAMOQl7gb7uA.png" /><figcaption>This schema is globaly a simplification of the creation of a project (not only digital product). From the outside to the center of the schemas the idea is to make the project more concrete passing by the absence of idea, the concept and then the solutions to apply to the product.</figcaption></figure><figure><img alt="Schema of a project simplified with the system covering the 3 circles on the center" src="https://cdn-images-1.medium.com/max/1024/1*WI0bNmijbvuUAyChNsuuwg.png" /><figcaption>This schema is a simplification of the previous one to show where the system begins. Only the absence of idea is outside of the system.</figcaption></figure>I choose to not represent it as a timeline or steps to follow because as we all know a project evolves and the idea is to make those evolutions a breeze so a lot of back and forth will happen. I just know that this is impossible to go from the No idea area to the solutions area directly. Even if the concept is quick and almost imperceptible, having an idea of a solution is already having a concept.In a nutshell the concept is equal to the Why we are doing things, the solutions are the How we are doing things and the product is the What. Without concept, without ideas we have a blank page, right?According to the previous schemas, if the solutions are answering the concept it will help create the product. So if the system works well so does the product. This is why I&#39;m convinced that we shouldn&#39;t say that a product doesn’t work because there is no Design System but we should understand that this is because we didn&#39;t find the right solutions to our system yet.<h3>A Design System is not tangible</h3>We’re organising things all the time without caring about the system we’re creating just by doing it. Each time you need to organise something, what do you do? Making lists, creating a Trello board, creating a map with wool thread ? There is no unique answer even if some of you will have a common one. This is exactly the same for Design Systems.A Design System is a concept, an idea of all the things you need to do to organise your own design concept. This is not tangible, this is not fixed, it’s a living thing that will grow and change with time.I wrote this post after hearing people saying &#39;&#39;we need to create a Design System&quot;. I found interesting that these people didn&#39;t know that their real need was to organise their system instead of creating it. They just connected the fact that the creation only comes with tangible things. I&#39;m convinced that this is not true.<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=8e4f53019923" width="1" height="1" alt="">

In this post I'll try to organise my thoughts on the Design System concept as a system serving a product.
A Design System definition
Unfortunately there is no standard definition of a Design System. As this is something more abstract and evolutive than tangible and definitive it is difficult to make an universal vision.
This is also why this area is so exciting. We can make our own path and share our experience.
In this post I will talk about Design System as a collection of shared patterns and practices that enable teams to build better products faster by making design reusable.
So, now we know that we cannot make a universal definition of a Design System. On the otherhand we can say what a Design System is not.
I heard a lot of people using the term “style guides” and “pattern libraries” in the web industry to define Design System and to be honest I find it problematic as both are only solutions or parts of the Design System but not the Design System itself.
This is a shame that a lot of companies took the Design System buzzword as THE solution to resolve almost all of their product interface’s problems and start to create UI kits and styleguides because others are doing so. Is this the right solution? I don’t think so, at least not for everyone and not without solid foundations.
UI kits and styleguides are both great solutions to go faster on creating interfaces in an ideal world where the plug and play works each time as expected. We all know that in the real world there are a lot of parameters that will affect this plug and play part (new features, marginal ideas, misconceptions, misunderstanding…).
Those parameters are most of the time human issues that can come from a lack of communication, a misunderstanding or a lack of collaboration between people. All those issues cannot be resolved with UI kits and styleguides and cannot be resolved in the same way in all companies.
It could be by creating or improving workflows, foster collaboration with handoff process, include technical stakeholders at the beginning of the conception… There are an infinite list of solutions and all cannot be applied everywhere.
When it starts then?
For me a Design System exists at the moment of the product conception. When the idea of an interface emerged a system is already in place even if this system is not working yet.
It's like having a bike without wheels. It's still a bike, but you cannot ride it yet as the system is not complete. All you have to do is finding a way to get wheels and adding them to complete the system. No matter how you do it, if it's working, this is your solution.
We can reflect this idea for a product. All products have there own ecosystem and workflows around it. The most difficult thing is to find the solutions to go from the concept to the product and this is where a Design System is involved.
In the schemas below, I’ve chosen the term Concept instead of Design, and System instead of Design System to avoid all wrong interpretation. I’m convince that all of that should be totally department agnostic to make sure that the goal is the product and how to serve it. Unfortunately I’ve met a lot of people thinking about Graphic Design or Drawing when they talked about Design. On my side Design is better to define conceptualisation, it doesn’t matter if you’re a developer, a designer, a mecanic or a musician.
This schema is globaly a simplification of the creation of a project (not only digital product). From the outside to the center of the schemas the idea is to make the project more concrete passing by the absence of idea, the concept and then the solutions to apply to the product.This schema is a simplification of the previous one to show where the system begins. Only the absence of idea is outside of the system.
I choose to not represent it as a timeline or steps to follow because as we all know a project evolves and the idea is to make those evolutions a breeze so a lot of back and forth will happen. I just know that this is impossible to go from the No idea area to the solutions area directly. Even if the concept is quick and almost imperceptible, having an idea of a solution is already having a concept.
In a nutshell the concept is equal to the Why we are doing things, the solutions are the How we are doing things and the product is the What. Without concept, without ideas we have a blank page, right?
According to the previous schemas, if the solutions are answering the concept it will help create the product. So if the system works well so does the product. This is why I'm convinced that we shouldn't say that a product doesn’t work because there is no Design System but we should understand that this is because we didn't find the right solutions to our system yet.
A Design System is not tangible
We’re organising things all the time without caring about the system we’re creating just by doing it. Each time you need to organise something, what do you do? Making lists, creating a Trello board, creating a map with wool thread ? There is no unique answer even if some of you will have a common one. This is exactly the same for Design Systems.
A Design System is a concept, an idea of all the things you need to do to organise your own design concept. This is not tangible, this is not fixed, it’s a living thing that will grow and change with time.
I wrote this post after hearing people saying ''we need to create a Design System". I found interesting that these people didn't know that their real need was to organise their system instead of creating it. They just connected the fact that the creation only comes with tangible things. I'm convinced that this is not true.

This is where a Design System starts

Midnight is PayFit&#x2019;s design system and also the name of the team working on it full time. In this article, we will tell you where it comes from, and give you some explanations on the way we work in a fast-growing company.

Introducing Midnight, our Design System

I’m a french frontend developer with a graphic designer background. I recently had a new goal, filling the gap between designers and developers and create interfaces as a team. With this article, I want to share the best way I found to create a design system.<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*zPpz_Y6_EoEZwDIJ27WFrw.png" /><figcaption>An example of an interface with some guidelines</figcaption></figure>When I started writing this article I asked myself “Where to start?”. It could be obvious for some of you but this should be the first thing we need to think about when we engage in any new project. It’s healthy to ask ourselves the most basic questions.By definition, a design system is a set of guidelines and rules that makes a product consistent and help the whole product team to understand it and easily create evolutions. It’s not only a pattern library of the product but also the way a team create a product. On this point I’m not the only one who think that way. Alla Kholmatova follows the same idea in her book “<a href="https://www.smashingmagazine.com/design-systems-book/">Design Systems</a>”, and I would highly recommend this reading if you want to look deeper into this subject:<blockquote>There isn’t a standard definition of “design system” within the web community, and people use the term in different ways – sometimes interchangeably with “style guides” and “pattern libraries.” In this book, by design system I mean a set of connected patterns and shared practices, coherently organized to serve the purposes of a digital product.</blockquote>To create those shared practices and connected patterns we need to understand our product. If we don’t then we can’t create rules and guidelines to follow. It’s that simple. Believe me without guidelines the user will see that the design doesn’t make sense, and for us, creators, it translates into “we failed at creating a good interface”. The user doesn’t think about the number of pixels we add on each element but is able to say if the composition seems imperfect, if the colors are not legit or if there are too many of them. This is the reason why the design system has to be consistent.In a nutshell, to start a design system we need to understand our product as a team.So the first thing we need to do is to gather all the people who will work on the project to discuss it. This would include project managers, product owners, UX and UI designers, developers and so on.I’ve created a sort of to do list to create a design system. The order is important for this process and is the one I will follow in the article.<ol><li>Needs</li><li>Inspirations</li><li>Common needs to work on the product</li><li>Prototyping</li><li>Create product, its rules and its universe</li><li>Development</li></ol>Now, let’s take a closer look at these six steps.<h4>1. Needs</h4>The purpose of this first step is to talk about the user’s needs, to know what the team will work on. Each member of the team should be there to start giving some general ideas and rule out others. It’s important that each team member knows why and how the choices are made, as well as seeing that everyone is involved. It could start with a brainstorming focusing on the users, their needs, their jobs and so on. Then, we can go ahead with a UX audit, starting with personas and interviews to gather information about the users.<h4>2. Inspirations</h4>The second step comes naturally after the first one. If we don’t want to do the same thing the competition already does, we have to understand what is available on the market. This comes with a series of questions we need to answer:<ul><li>What is the competition providing?</li><li>What works and does not work?</li><li>What’s the trends in the same area?</li><li>What shapes are always used and why do they work?</li><li>What colors are already used and why?</li></ul>The more we find, the better. It will inspire the team and may provide all the informations we need to bring the project to life. We can hear UX thoughts emerging from the team or see some UI patterns that are already used.When we have enough informations we can decide what we will keep or not and what we want to improve.<h4>3. Common needs to work on the product</h4>Common needs are all the things our team needs to start working on together for the product. It can be software, hardware, webtools or everything else. We need to think about tools that could help sharing work between the members of the team.At this step, it’s up to the team to find the right tools to work together.<h4>4. Prototyping</h4>This is the first step to a concrete design system. I am convinced that the UX must be made upstream of the UI but also in parallel. We can’t create a design interface without some UX knowledge. So the UX team needs to bring some informations after performing a user research. It can be started after the first step and be enriched by the following steps. The most important thing is to start designing with UX foundation to be sure that our product matches with our users needs.Wireframe is the starting point of the design conception, because it can show the composition of the page without details. At this step, details doesn’t help to find the right interface composition and could lose the designer eyes in it. So one color and its scale to define the main elements is the best way to do it. When the right one is found, designers can create the prototype.At the end of this step, or at least the first iteration of this step, we will have a prototype that can be tested with real users. With this prototype we can obtain UX feedbacks from the users, and those can be implemented in the final UI. All members of the team should test the prototype too as it will bring more feedbacks, but also be an interesting comparison with the users test.After that, we have enough to start our design system and create our final interface.<h4>5. Create product, its rules and its universe</h4>I think it’s my favorite part.This is the design conception step. Here, all informations gathered will be mixed into a real interface.The prototype must have given us the right way to create the interface. Designers will iterate the interface design until they find the right one. The design doesn’t need to be perfect at first. It will be improved and guided by the rules created at the same time and after some iterations.At this stage, the main goal is to pay attention to the details: choosing the right colors, the right fonts, the best contrasts, etc. The color accessibility should always remain in mind and the prototype work done with grayscales will be helpful with this point. The designers should be able to identify all the elements that are reusable and start to create a library of those they could use as symbols in the whole interface. “Symbols” is a Sketch term for reusable element but you may find equivalent in similar softwares. For example, in Figma, it’s called “Components”.On the web we can find multiple examples of design guidelines starting by the <a href="https://material.io/design/">Material Design</a> one created by Google. This official video shows the Material Design principles:<iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fwww.youtube.com%2Fembed%2FQ8TXgCzxEnw%3Ffeature%3Doembed&amp;display_name=YouTube&amp;url=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DQ8TXgCzxEnw&amp;image=https%3A%2F%2Fi.ytimg.com%2Fvi%2FQ8TXgCzxEnw%2Fhqdefault.jpg&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=youtube" width="854" height="480" frameborder="0" scrolling="no"><a href="https://medium.com/media/b2aac080cc4f2bb0a03cd1e982e9d4d4/href">https://medium.com/media/b2aac080cc4f2bb0a03cd1e982e9d4d4/href</a></iframe>The material Design could be summarized by this quote from the Material design team:<blockquote>Design is the art of considered creation. Our goal is to satisfy the diverse spectrum of human needs. As those needs evolve, so too must our designs, practices, and philosophies. We challenged ourselves to create a visual language for our users that synthesizes the classic principles of good design with the innovation and possibility of technology and science. A material metaphor is the unifying theory of a rationalized space and a system of motion. Our material is grounded in tactile reality, inspired by our study of paper and ink, yet open to imagination and magic. This is material design.</blockquote>But, this is just why they created it, the needs, and not how it works. So that’s why they created their design principles. If you are familiar with graphic charters, it has the same goal: showing design rules, what can be done and what can’t be done.Anybody reading the design principles must be able to understand how the design system works. Here is an example of design principle for a <a href="https://material.io/design/components/app-bars-bottom.html#">Bottom app bars in material design</a>:<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*ae2A_JVSg2s5SPQ8tKPT-A.png" /></figure>There are some context informations and a clear illustration that shows spaces and sizes in pixel, to be conform with the Material Design. If we don’t follow these rules, then that’s not a Material Design.That’s my point. We need to create rules and guidelines to follow for our design.Material Design is not the only one to have a ruleset on the web, it was just an example but we can also find the <a href="https://www.carbondesignsystem.com/">IBM design system called Carbon</a> or the <a href="https://design.firefox.com/photon/">Firefox one called Photon</a>.You can retrieve many design systems and pattern libraries on <a href="https://adele.uxpin.com/">Adele by UXPin</a>.At this stage, we have a sort of wireframe in place but we need a final design guided by the product rules and moreover, by the users’ needs. These rules have helped the designers to create the interface components with ease, and the frontend developers will enjoy the same benefits. No one will be asking for the color that should be used on a primary button, or the max-width of pages grid. The rules are here for that and will help to ensure consistency in the whole project.When we create our design system it’s important to have a naming convention in place, to make it easy when we talk within the product team. We can name our different web components and reuse the same name in the designer’s files but also in the frontend code. Most people don’t realise it’s important until we need to talk about it with a team member and see that it’s difficult to communicate, because we don’t talk about the same thing or call it differently.This part does not come on it’s own, we also need to know the methodology to create our design system. For me it’s one of the most important part because it leads to our design system identity and the system itself of our design.Brad Frost created <a href="http://atomicdesign.bradfrost.com/">the Atomic Design</a> for this last purpose. It’s one methodology to divide your interface and make it reusable but you can create your own and especially one that fit your product principles and your team philosophy.Your interface is not just an interface. This is many elements that create an interface when they are combined together. I have an example for that (inspired by the <a href="https://medium.com/making-bulb/introducing-bulbs-design-system-c8b2306650c1">Alla Kholmatova medium post</a>):<figure><img alt="" src="https://cdn-images-1.medium.com/max/1000/1*jBXxzaGWirTx4ncyiNIKCA.jpeg" /><figcaption>This is the original US patent for the Lego brick (2x4 brick)</figcaption></figure>Take one Lego brick, you can combine it with another one and so on to build whatever you want (believe me you can create almost everything with lego bricks). The final result is the interface but each brick is a component. Each brick has its own purpose, its own function, that’s why there are different bricks with different numbers of studs at the top. Some of them also have holes to suit another function. All of them together create the Lego bricks design system — because a design system is not just for the web but also all areas that use design in their process. Imagine how frustrating it could be if those bricks didn’t fit together or if they fitted but no kids knew how to put them together. This would mean that the design system has an issue.When designers create the interface’s universe and rules, they should involve UX knowledge and the development constraints to avoid what can not be done and what is not user focussed.<h4>6. Development</h4>Once we have the rules we can start to develop the product. It’s the last but not least step, because it must take into account all the previous steps.Development needs to be done hand to hand with the design team. It’s really important to understand each others and create a unicity between these two disciplines. The methodology used by the design team should be used in development too.There are many ways to show how the design system works. And one solution used by developers is a style guide. But not just a style guide like the one created by the design team. Developers can create a living style guide that evolves with the product when changes are applied to components. Generally, it’s the same way to create it, we add some comments in our styles files and the style guide is generated. For more informations you can go to the <a href="https://kss-node.github.io/kss-node/">KSS website</a> or the <a href="https://trulia.github.io/hologram/">Hologram one</a> (I also like <a href="https://www.docz.site/">Docz</a> and <a href="https://react-styleguidist.js.org/">styleguidist</a>).This style guide can be shared with anyone and become the interactive documentation of our design system. Because our product will evolve, the living style guide is required to live with it and evolve at the same time. To go further in this style guide we can add more technical informations like classes used in html, variables from the template or from the CSS preprocessor, API informations and so on. It’s up to us to add what we want in this style guide.A design system must allow the product to evolve without having to add new elements, colors or fonts. It must be simple and understandable. Evolutions are supposed to be done using the elements already present, according to their meaning or function. New elements are created only when no other elements match the needs. In conclusion, the most important thing to remember is that all of this previous points are not possible if the product team members don’t work together.Thanks for reading this post and feel free to leave a comment.<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=589e8403eb76" width="1" height="1" alt="">

I’m a french frontend developer with a graphic designer background. I recently had a new goal, filling the gap between designers and developers and create interfaces as a team. With this article, I want to share the best way I found to create a design system.
An example of an interface with some guidelines
When I started writing this article I asked myself “Where to start?”. It could be obvious for some of you but this should be the first thing we need to think about when we engage in any new project. It’s healthy to ask ourselves the most basic questions.
By definition, a design system is a set of guidelines and rules that makes a product consistent and help the whole product team to understand it and easily create evolutions. It’s not only a pattern library of the product but also the way a team create a product. On this point I’m not the only one who think that way. Alla Kholmatova follows the same idea in her book “Design Systems”, and I would highly recommend this reading if you want to look deeper into this subject:
There isn’t a standard definition of “design system” within the web community, and people use the term in different ways – sometimes interchangeably with “style guides” and “pattern libraries.” In this book, by design system I mean a set of connected patterns and shared practices, coherently organized to serve the purposes of a digital product.
To create those shared practices and connected patterns we need to understand our product. If we don’t then we can’t create rules and guidelines to follow. It’s that simple.
Believe me without guidelines the user will see that the design doesn’t make sense, and for us, creators, it translates into “we failed at creating a good interface”. The user doesn’t think about the number of pixels we add on each element but is able to say if the composition seems imperfect, if the colors are not legit or if there are too many of them. This is the reason why the design system has to be consistent.
In a nutshell, to start a design system we need to understand our product as a team.
So the first thing we need to do is to gather all the people who will work on the project to discuss it. This would include project managers, product owners, UX and UI designers, developers and so on.
I’ve created a sort of to do list to create a design system. The order is important for this process and is the one I will follow in the article.

Needs
Inspirations
Common needs to work on the product
Prototyping
Create product, its rules and its universe
Development

Now, let’s take a closer look at these six steps.
1. Needs
The purpose of this first step is to talk about the user’s needs, to know what the team will work on. Each member of the team should be there to start giving some general ideas and rule out others. It’s important that each team member knows why and how the choices are made, as well as seeing that everyone is involved. It could start with a brainstorming focusing on the users, their needs, their jobs and so on.
Then, we can go ahead with a UX audit, starting with personas and interviews to gather information about the users.
2. Inspirations
The second step comes naturally after the first one. If we don’t want to do the same thing the competition already does, we have to understand what is available on the market. This comes with a series of questions we need to answer:

What is the competition providing?
What works and does not work?
What’s the trends in the same area?
What shapes are always used and why do they work?
What colors are already used and why?

The more we find, the better. It will inspire the team and may provide all the informations we need to bring the project to life. We can hear UX thoughts emerging from the team or see some UI patterns that are already used.
When we have enough informations we can decide what we will keep or not and what we want to improve.
3. Common needs to work on the product
Common needs are all the things our team needs to start working on together for the product. It can be software, hardware, webtools or everything else. We need to think about tools that could help sharing work between the members of the team.
At this step, it’s up to the team to find the right tools to work together.
4. Prototyping
This is the first step to a concrete design system.
I am convinced that the UX must be made upstream of the UI but also in parallel. We can’t create a design interface without some UX knowledge. So the UX team needs to bring some informations after performing a user research. It can be started after the first step and be enriched by the following steps.
The most important thing is to start designing with UX foundation to be sure that our product matches with our users needs.
Wireframe is the starting point of the design conception, because it can show the composition of the page without details. At this step, details doesn’t help to find the right interface composition and could lose the designer eyes in it. So one color and its scale to define the main elements is the best way to do it. When the right one is found, designers can create the prototype.
At the end of this step, or at least the first iteration of this step, we will have a prototype that can be tested with real users. With this prototype we can obtain UX feedbacks from the users, and those can be implemented in the final UI.
All members of the team should test the prototype too as it will bring more feedbacks, but also be an interesting comparison with the users test.
After that, we have enough to start our design system and create our final interface.
5. Create product, its rules and its universe
I think it’s my favorite part.
This is the design conception step. Here, all informations gathered will be mixed into a real interface.
The prototype must have given us the right way to create the interface. Designers will iterate the interface design until they find the right one. The design doesn’t need to be perfect at first. It will be improved and guided by the rules created at the same time and after some iterations.
At this stage, the main goal is to pay attention to the details: choosing the right colors, the right fonts, the best contrasts, etc. The color accessibility should always remain in mind and the prototype work done with grayscales will be helpful with this point. The designers should be able to identify all the elements that are reusable and start to create a library of those they could use as symbols in the whole interface. “Symbols” is a Sketch term for reusable element but you may find equivalent in similar softwares. For example, in Figma, it’s called “Components”.
On the web we can find multiple examples of design guidelines starting by the Material Design one created by Google.
This official video shows the Material Design principles:
https://medium.com/media/b2aac080cc4f2bb0a03cd1e982e9d4d4/href
The material Design could be summarized by this quote from the Material design team:
Design is the art of considered creation. Our goal is to satisfy the diverse spectrum of human needs. As those needs evolve, so too must our designs, practices, and philosophies. We challenged ourselves to create a visual language for our users that synthesizes the classic principles of good design with the innovation and possibility of technology and science. A material metaphor is the unifying theory of a rationalized space and a system of motion. Our material is grounded in tactile reality, inspired by our study of paper and ink, yet open to imagination and magic. This is material design.
But, this is just why they created it, the needs, and not how it works. So that’s why they created their design principles. If you are familiar with graphic charters, it has the same goal: showing design rules, what can be done and what can’t be done.Anybody reading the design principles must be able to understand how the design system works.
Here is an example of design principle for a Bottom app bars in material design:

There are some context informations and a clear illustration that shows spaces and sizes in pixel, to be conform with the Material Design. If we don’t follow these rules, then that’s not a Material Design.That’s my point. We need to create rules and guidelines to follow for our design.
Material Design is not the only one to have a ruleset on the web, it was just an example but we can also find the IBM design system called Carbon or the Firefox one called Photon.
You can retrieve many design systems and pattern libraries on Adele by UXPin.
At this stage, we have a sort of wireframe in place but we need a final design guided by the product rules and moreover, by the users’ needs. These rules have helped the designers to create the interface components with ease, and the frontend developers will enjoy the same benefits. No one will be asking for the color that should be used on a primary button, or the max-width of pages grid. The rules are here for that and will help to ensure consistency in the whole project.
When we create our design system it’s important to have a naming convention in place, to make it easy when we talk within the product team. We can name our different web components and reuse the same name in the designer’s files but also in the frontend code. Most people don’t realise it’s important until we need to talk about it with a team member and see that it’s difficult to communicate, because we don’t talk about the same thing or call it differently.
This part does not come on it’s own, we also need to know the methodology to create our design system. For me it’s one of the most important part because it leads to our design system identity and the system itself of our design.
Brad Frost created the Atomic Design for this last purpose.
 It’s one methodology to divide your interface and make it reusable but you can create your own and especially one that fit your product principles and your team philosophy.
Your interface is not just an interface. This is many elements that create an interface when they are combined together.
I have an example for that (inspired by the Alla Kholmatova medium post):
This is the original US patent for the Lego brick (2x4 brick)
Take one Lego brick, you can combine it with another one and so on to build whatever you want (believe me you can create almost everything with lego bricks). The final result is the interface but each brick is a component. Each brick has its own purpose, its own function, that’s why there are different bricks with different numbers of studs at the top. Some of them also have holes to suit another function. All of them together create the Lego bricks design system — because a design system is not just for the web but also all areas that use design in their process. Imagine how frustrating it could be if those bricks didn’t fit together or if they fitted but no kids knew how to put them together. This would mean that the design system has an issue.
When designers create the interface’s universe and rules, they should involve UX knowledge and the development constraints to avoid what can not be done and what is not user focussed.
6. Development
Once we have the rules we can start to develop the product. It’s the last but not least step, because it must take into account all the previous steps.
Development needs to be done hand to hand with the design team. It’s really important to understand each others and create a unicity between these two disciplines. The methodology used by the design team should be used in development too.
There are many ways to show how the design system works. And one solution used by developers is a style guide. But not just a style guide like the one created by the design team. Developers can create a living style guide that evolves with the product when changes are applied to components. Generally, it’s the same way to create it, we add some comments in our styles files and the style guide is generated. For more informations you can go to the KSS website or the Hologram one (I also like Docz and styleguidist).
This style guide can be shared with anyone and become the interactive documentation of our design system. Because our product will evolve, the living style guide is required to live with it and evolve at the same time.
To go further in this style guide we can add more technical informations like classes used in html, variables from the template or from the CSS preprocessor, API informations and so on. It’s up to us to add what we want in this style guide.
A design system must allow the product to evolve without having to add new elements, colors or fonts. It must be simple and understandable. Evolutions are supposed to be done using the elements already present, according to their meaning or function. New elements are created only when no other elements match the needs.
In conclusion, the most important thing to remember is that all of this previous points are not possible if the product team members don’t work together.
Thanks for reading this post and feel free to leave a comment.

What’s a design system and how to create one?

<figure><img alt="" src="https://cdn-images-1.medium.com/max/768/1*KEj1UxDYCz_q2aG0825acg.jpeg" /><figcaption>Source : <a href="https://cets.georgetown.edu">https://cets.georgetown.edu</a></figcaption></figure>First of all, I must explain the context. Last year I was in a modern training in France. Now we can learn how to manage web projects, and I was curious, me, a front-end developper. So I tried.In this training I was in school every 4 weeks. The rest of the time I worked in a company as a Front-end web Integrator.<h3>The purpose of the training</h3>The different themes are :<ul><li>Knowledge of the web world. Yes, it’s the main goal but contrary to our belief, all young people are not familiar with the web. Most of them are just good to post on facebook or to level up in warcraft. But they really don’t know how the web works (and it makes me think of the South Park episode that talks about internet).</li></ul><figure><img alt="" src="https://cdn-images-1.medium.com/max/595/1*CD9G9eSZJKsf9FR_qemg2w.jpeg" /><figcaption>South Park — Over Logging S12E06</figcaption></figure><ul><li>SEO / SEA / SEM / SMO. A big part of webmarketing to learn many ways to index a website.</li><li>Project Managing. No matter what project to manage, it’s really interesting to know how to manage a team and give tasks to the right people.</li><li>Web languages. Some people had problems on this point, which is quite understandable. When the trainer talks about HTML, CSS, Javascript, XML, PHP… and give some exercices to the whole class, it’s really hard. Some say it’s ridiculous to know this, because it’s not their job. It’s a real problem to teach how it works without looking in. A web project manager must know this part otherwise he simply can’t manage a web team at all.</li><li>Design and web accessibility. This part is very important to get a good design, a good semantic code and make it accessible to the largest number of people (on the web we need to care about partially sighted, color-blind or blind person. We need to know how to make pages accessible to them, it’s as important as the accessibility in some places to people in wheelchairs or with limited mobility).</li><li>The Billing. Yeah, the hard part. I’m not familiar with numbers but it’s important to know how many you can pay your employees with a profit margin, of course. Some Project Manager don’t do this part and leave it to the accounting officer but it’s good to know for little agency, freelance or whatever you want.</li></ul>At the same time there is also the company job that takes three-quarters of the time.<h3>What I liked?</h3>When we get into this kind of training we meet a lot of people. And yes I met a lot of different people.It’s very good for the team work to be with people from different areas. Ideas according to individual specialties were really interesting and opens more possibilites.It’s good to know that all the people don’t use computer in the same way. And when you create a project, this sample of people can inspire you. So when we had to create project group it’s became very interesting. Working in groups is important at all levels. You can have ideas faster than if you’re alone, you can solve problems easier, you can work faster because many tasks can be done at the same time… and so onThe topics are really interesting and complementary. The project Managers have big responsabilities and he has to juggle between marketing and the technical part. This training show me the importance of them.What I really liked in the training part is the accessibility lessons. It’s often left behind for timing reasons or because the graphic designer and developpers have no thoughts for this. So that’s a really great idea to give it the importance that deserve. Because of this we can expected a good futur for the accessibility on the web. If you want to learn more about this part you can go to <a href="https://www.w3.org/WAI/intro/accessibility.php">the W3C page</a>.In a nutshell :<blockquote>Web accessibility means that people with disabilities can use the Web — W3C</blockquote>I must admit that I preferred the company part. I learned in two weeks that I never learned in a year of training. My team at work was very great, they helped me a lot to integrate myself into the world of work and I thank them for that.When you work for a company in the web area it’s not about you, it’s about them. People who visit your site. And your work is real, there are customers and requests, and you need to bring solutions. It’s not the same as a training project, it’s better.<h3>What I disliked?</h3>It’s terrible but there is a gap between training center and the company. They are two different worlds. It’s complicated. You need to learn how it works in real business world and when you work you realize that’s not the truth. I think it’s the real problem of this kind of training. We learn things theoretically, we practice a little bit with this theory and when we see the reality we are lost. I hope some training center can solve this problem over the world, but in France, I think it’s mostly the same in many field (I learn in 4 different center, and the result is the same).Trainers are not often invested in their work. Some of them are called for replacement. Others may come from different area and they learn themselves the lessons that they teach the same day. But of course, and fortunately, there are always good trainers. But it’s a minority and it’s too bad.<h3>In Conclusion</h3>Yes the purpose of these two entities is different. The training center ask you to learn and get your degree, and on the other hand the company ask you to produce with your knowledge. It’s not incompatible but I think the goal should be common. Trainees should be in company, in the real part of the job. They can learn on the field, with some themes to approach. And if there is a need of degree they can pass a test in agreement with the training center.Yes that’s utopian but I think with this kind of training we can expect a lot more efficiant employees at the end.However what I learned is interesting. People of all areas can become web project manager if they want it. Personally I prefer to leave the management for now and keep the development part. I’m not comfortable with the marketing but I saw people who had it in their blood.If anyone reading this post is a trainer or a teacher in the web field, maybe you can talk about your experience. For exemple I know <a href="https://medium.com/u/2c972de40a20">Nicole Saidy</a> teaches at <a href="https://www.lewagon.com/">Le wagon</a>, what can you tell us about their training?<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=4148a9f37148" width="1" height="1" alt="">

Source : https://cets.georgetown.edu
First of all, I must explain the context. Last year I was in a modern training in France. Now we can learn how to manage web projects, and I was curious, me, a front-end developper. So I tried.
In this training I was in school every 4 weeks. The rest of the time I worked in a company as a Front-end web Integrator.
The purpose of the training
The different themes are :

Knowledge of the web world. Yes, it’s the main goal but contrary to our belief, all young people are not familiar with the web. Most of them are just good to post on facebook or to level up in warcraft. But they really don’t know how the web works (and it makes me think of the South Park episode that talks about internet).
South Park — Over Logging S12E06
SEO / SEA / SEM / SMO. A big part of webmarketing to learn many ways to index a website.
Project Managing. No matter what project to manage, it’s really interesting to know how to manage a team and give tasks to the right people.
Web languages. Some people had problems on this point, which is quite understandable. When the trainer talks about HTML, CSS, Javascript, XML, PHP… and give some exercices to the whole class, it’s really hard. Some say it’s ridiculous to know this, because it’s not their job. It’s a real problem to teach how it works without looking in. A web project manager must know this part otherwise he simply can’t manage a web team at all.
Design and web accessibility. This part is very important to get a good design, a good semantic code and make it accessible to the largest number of people (on the web we need to care about partially sighted, color-blind or blind person. We need to know how to make pages accessible to them, it’s as important as the accessibility in some places to people in wheelchairs or with limited mobility).
The Billing. Yeah, the hard part. I’m not familiar with numbers but it’s important to know how many you can pay your employees with a profit margin, of course. Some Project Manager don’t do this part and leave it to the accounting officer but it’s good to know for little agency, freelance or whatever you want.

At the same time there is also the company job that takes three-quarters of the time.
What I liked?
When we get into this kind of training we meet a lot of people. And yes I met a lot of different people.
It’s very good for the team work to be with people from different areas. Ideas according to individual specialties were really interesting and opens more possibilites.
It’s good to know that all the people don’t use computer in the same way. And when you create a project, this sample of people can inspire you. So when we had to create project group it’s became very interesting. Working in groups is important at all levels. You can have ideas faster than if you’re alone, you can solve problems easier, you can work faster because many tasks can be done at the same time… and so on
The topics are really interesting and complementary. The project Managers have big responsabilities and he has to juggle between marketing and the technical part. This training show me the importance of them.
What I really liked in the training part is the accessibility lessons. It’s often left behind for timing reasons or because the graphic designer and developpers have no thoughts for this. So that’s a really great idea to give it the importance that deserve. Because of this we can expected a good futur for the accessibility on the web. If you want to learn more about this part you can go to the W3C page.
In a nutshell :
Web accessibility means that people with disabilities can use the Web — W3C
I must admit that I preferred the company part. I learned in two weeks that I never learned in a year of training. My team at work was very great, they helped me a lot to integrate myself into the world of work and I thank them for that.
When you work for a company in the web area it’s not about you, it’s about them. People who visit your site. And your work is real, there are customers and requests, and you need to bring solutions. It’s not the same as a training project, it’s better.
What I disliked?
It’s terrible but there is a gap between training center and the company. They are two different worlds. It’s complicated. You need to learn how it works in real business world and when you work you realize that’s not the truth. I think it’s the real problem of this kind of training. We learn things theoretically, we practice a little bit with this theory and when we see the reality we are lost. I hope some training center can solve this problem over the world, but in France, I think it’s mostly the same in many field (I learn in 4 different center, and the result is the same).
Trainers are not often invested in their work. Some of them are called for replacement. Others may come from different area and they learn themselves the lessons that they teach the same day. But of course, and fortunately, there are always good trainers. But it’s a minority and it’s too bad.
In Conclusion
Yes the purpose of these two entities is different. The training center ask you to learn and get your degree, and on the other hand the company ask you to produce with your knowledge. It’s not incompatible but I think the goal should be common. Trainees should be in company, in the real part of the job. They can learn on the field, with some themes to approach. And if there is a need of degree they can pass a test in agreement with the training center.
Yes that’s utopian but I think with this kind of training we can expect a lot more efficiant employees at the end.
However what I learned is interesting. People of all areas can become web project manager if they want it. Personally I prefer to leave the management for now and keep the development part. I’m not comfortable with the marketing but I saw people who had it in their blood.
If anyone reading this post is a trainer or a teacher in the web field, maybe you can talk about your experience. For exemple I know Nicole Saidy teaches at Le wagon, what can you tell us about their training?

What I learned from a Web Project Manager training

<figure><img alt="" src="https://cdn-images-1.medium.com/max/833/1*9hWNj7SXyf7OfAY9dYS-XA.png" /></figure>Why I asked me this question? I think it’s because sometimes I see my own code and I swear a lot. Or it’s because some people don’t care about their style and I swear too. But I love styling things and I decided to clean up my styles.It’s my way to organize my properties to get cool, clean and readable stylesheets. I think I’m not the only one who cares about this and this is why I’m sharing it right now.First I made a list of properties and I’ve sorted them by type and by importance. And with this list I can style neatly without thinking my code is a big mess.Here is the list :<ol><li>Position type and float</li><li>Top, Right, Bottom, Left position</li><li>Display and Visibility</li><li>Size (width and height)</li><li>Margin</li><li>Outline and Border</li><li>Padding</li><li>Overflow</li><li>Background</li><li>Font, Text, Line, Space</li><li>Color</li><li>Effects (like opacity or shadows)</li><li>Animations and Transitions</li></ol>So, the organization is simple. I start with general properties and I continue to the most inside properties. After that I make effects and animations. What I like too in this method is to seperate the container and the content. In this list the first 8 elements are part of the container, the following three are part of the content and the last two are just sort of bonus.According to that list, I get the position of my element, I add its size, I design it, then I work on text inside it and finish with Effects and Animations. Since I’m working this way, I’m saving my time because I find my properties with ease.Here is an example of what you can expect:<pre>.element{ position: relative; display: block; width: 200px; margin: 0 auto; padding: 1em 2em; background: #212228; font-weight: 700; color: #ffffff; transition: all 0.3s ease; }</pre>If you have another method to define your CSS properties feel free to leave a comment.You can also like <a href="http://bradfrost.com/blog/post/atomic-web-design/">the Atomic Design concept by Brad Frost</a>. It’s the organization of web components as if they are a chemistry elements. I like the idea!<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=b8bc5820c2e5" width="1" height="1" alt=""><hr><a href="https://medium.com/wdstack/how-i-organize-my-css-and-why-b8bc5820c2e5">How I organize my CSS and why?</a> was originally published in <a href="https://medium.com/wdstack">WDstack</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Why I asked me this question? I think it’s because sometimes I see my own code and I swear a lot. Or it’s because some people don’t care about their style and I swear too. But I love styling things and I decided to clean up my styles.
It’s my way to organize my properties to get cool, clean and readable stylesheets. I think I’m not the only one who cares about this and this is why I’m sharing it right now.
First I made a list of properties and I’ve sorted them by type and by importance. And with this list I can style neatly without thinking my code is a big mess.
Here is the list :

Position type and float
Top, Right, Bottom, Left position
Display and Visibility
Size (width and height)
Margin
Outline and Border
Padding
Overflow
Background
Font, Text, Line, Space
Color
Effects (like opacity or shadows)
Animations and Transitions

So, the organization is simple. I start with general properties and I continue to the most inside properties. After that I make effects and animations.
What I like too in this method is to seperate the container and the content. In this list the first 8 elements are part of the container, the following three are part of the content and the last two are just sort of bonus.
According to that list, I get the position of my element, I add its size, I design it, then I work on text inside it and finish with Effects and Animations.
Since I’m working this way, I’m saving my time because I find my properties with ease.
Here is an example of what you can expect:
.element{
  position: relative;
  display: block;
  width: 200px;
  margin: 0 auto;
  padding: 1em 2em;
  background: #212228;
  font-weight: 700;
  color: #ffffff;
  transition: all 0.3s ease;
}
If you have another method to define your CSS properties feel free to leave a comment.
You can also like the Atomic Design concept by Brad Frost. It’s the organization of web components as if they are a chemistry elements. I like the idea!

How I organize my CSS and why? was originally published in WDstack on Medium, where people are continuing the conversation by highlighting and responding to this story.

How I organize my CSS and why?

<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*Bv6W5ynBosJTGt_3q8Dw2Q.png" /></figure>For many years now the world have the chance to see same content on different devices. And unfortunately for most of the people those devices became units of mesure.<blockquote>Why my Ipad mini gets a better look than my laptop on this website? My laptop is larger, I don’t understand.</blockquote>People think about the size of their devices and not their resolution. But the design of a website is not based on device but on resolution!It’s our fault. Or at least the fault of these pictograms :<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*NrFeSPaQFR7ojrIBYggXEQ.jpeg" /></figure>Since we create responsive websites big brands use this type of icon to inform their customers that their websites fit their mobile devices (usually you can see it on tv ads under the logotype). People are used to it but it’s not necessarily well understood.Recently I worked with marketing people and it was hard to explain that I just needed 3 or 4 breakpoints in my code to make website responsive for all devices.<blockquote>- But the design is different on my tablet in landscape mode! - Yes! Because the screen size is wide enough to fit the large breakpoint. It’s responsive!</blockquote>Website design just need minimum or maximum width to make a breakpoint, under or above it’s a different design. If we design based on resolution (and therefore pixels) we can fit to any devices.It’s not unusual to see website with just 2 breakpoints, one to seperate small and medium resolution and one to seperate medium and large one. With this type of responsive in medium range we could have laptop and tablet landscape with the same design. And all of this without ever caring device itself.So our users have no idea of what’s the real responsive, they just want it fits to their device. Because of this misunderstood we continue to create our wireframes and prototypes on these devices, but we should do this on different sizes and ratios for better works.For exemple we have a tool named <a href="http://responsivepx.com/">responsivepx</a> for testing responsive without thinking of devices.<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*7Bsqxmo-99kpop3ZhnHeXg.jpeg" /><figcaption>capture of creativebloq.com website testing</figcaption></figure>Thank you for reading!<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=d6869aebfd4c" width="1" height="1" alt="">

For many years now the world have the chance to see same content on different devices. And unfortunately for most of the people those devices became units of mesure.
Why my Ipad mini gets a better look than my laptop on this website? My laptop is larger, I don’t understand.
People think about the size of their devices and not their resolution. But the design of a website is not based on device but on resolution!
It’s our fault. Or at least the fault of these pictograms :

Since we create responsive websites big brands use this type of icon to inform their customers that their websites fit their mobile devices (usually you can see it on tv ads under the logotype). People are used to it but it’s not necessarily well understood.
Recently I worked with marketing people and it was hard to explain that I just needed 3 or 4 breakpoints in my code to make website responsive for all devices.
- But the design is different on my tablet in landscape mode!
- Yes! Because the screen size is wide enough to fit the large breakpoint. It’s responsive!
Website design just need minimum or maximum width to make a breakpoint, under or above it’s a different design. If we design based on resolution (and therefore pixels) we can fit to any devices.
It’s not unusual to see website with just 2 breakpoints, one to seperate small and medium resolution and one to seperate medium and large one. With this type of responsive in medium range we could have laptop and tablet landscape with the same design. And all of this without ever caring device itself.
So our users have no idea of what’s the real responsive, they just want it fits to their device. Because of this misunderstood we continue to create our wireframes and prototypes on these devices, but we should do this on different sizes and ratios for better works.
For exemple we have a tool named responsivepx for testing responsive without thinking of devices.
capture of creativebloq.com website testing
Thank you for reading!

Blog

This is where a Design System starts

Introducing Midnight, our Design System

What’s a design system and how to create one?

What I learned from a Web Project Manager training

How I organize my CSS and why?

How users understand responsive?