It’s been almost 2 years since the last time we talked about the design system. Now, it’s time to update our content with new features, options, and pieces of information that might be useful for you.
Let’s quickly sum up what a design system is.
What is a design system?
We all know or remember times when our designs had countless numbers of different buttons, instances of icons, inputs, etc. There was no specific guideline on how we should use the elements throughout the project. Making changes was cumbersome, as was maintaining final versions for development or testers.
Then a Design System was introduced into our work, being one of the most important things that we can use to create consistent and accessible products. It’s a collection of reusable components, guided by clear standards that can be assembled to build any number of applications, views, marketing materials, generators, etc.
It helps us improve consistency across our projects and teams by guiding how elements should behave across different contexts — and if we can standardize how elements behave in all of our projects, then everyone wins!
Who stands to benefit?
Clients — A product ready for further development with minimal work with all necessary guidelines.
Developers — Have continuous visibility and access to current versions of components, all their states, and behavior on different resolutions.
Testers — They can easily check if the deployed version is compatible with the designed one, without unnecessary searching through screens and worrying that something might be different somewhere.
Marketing — We are well aware that designing marketing materials by an external department can be problematic when it comes to maintaining all the relevant brand guidelines. With Design Systems, we can reduce the amount of work and risk to practically a minimum, creating posts or presentations that rely 90% on clicking on the options we want.
Newbies — The introduction of a new person in a company or department always involves additional costs that stem from the need to implement its internal processes, and to understand all the rules of brand guidelines. Thanks to the design system we can quickly and pleasantly show this person how a product is created in our company and how we want to continue it.
What should be included in the perfect design system?
Below you will find a small checklist of elements that should necessarily be included in your design system.
- Colors
- Typography
- Icons
- Loaders
- Spacings
- Shadows (if used)
- Inputs
- Buttons & Labels
- Form Controls
- Illustrations (if used)
- And all of the remaining components used within the app
Naming of Elements
Typography
Regarding nomenclature, with reference to the original version of this article, we have deviated from a few rules.
Due to the fact that we are working on Figma which is the most powerful and flexible tool for us, we no longer need to specify color or alignment for typographic styles. We only focus on Family if we have more than one, and then divide into Headers, Bodies, Paragraphs and any other modifications, respectively.
And the whole thing looks as follows:
[Font Family] / [Style]
In the case when we have a style, for example, Body 3, and we want to add exactly the same style, but with, for example, underline or slice, we use the rule:
[Style]_X
That is, we get Body 3_S or Body 3_U.
If the project is not too extensive, we abandon the categorization of fonts on the basis of Header/Body, etc. and the whole thing is replaced by “Style 1, Style 2, Style 3”. After talking with developers, we discovered that this way is much more pleasant for them to implement, as well as for testers to test.
Colors
As for colors, here the case is short. Thanks to the extensive plugins in Figma, we are able to easily design Light and Dark versions. At the design stage, we adjust the colors so that Light has its Dark counterpart, and the shades, if needed, are determined by the transparency percentage.
It looks as follows:
[Light Mode] / [Group] / [Name of Color] / [Opacity]
That is, based on a live example, we have:
Light/Universal/Primary
Or
Dark/Elements/Subtype
In this case, we just didn’t need to add a marker to these colors.
That’s it about naming our styles.
Atomic Design
The most popular framework for making a Design System is Atomic Design. It is not such a complicated philosophy but rather a simple methodology that consists of creating small particles and building bigger templates and projects out of them.
Before we even start with basic system elements, we need to determine what kind of atoms we will use. Here are the examples of atoms we use daily at iteo.
Grid
The grid we use at iteo hasn’t changed much over the years. The standard used in our company and others is the 8px grid. It allows for harmonious arrangement of interface elements, plus it is very intuitive when designing since there are multiples of the number 8 (8, 16, 24, 32, 40, 48, etc.), so designing in such a system is very smooth.
Personally, I have recently switched to the 4px grid. It presents us with much more possibilities and flexibility which is very important for smaller devices. Then, we base the whole of our grid on multiples of 4 which gives us practically twice as many possibilities as in the case of an 8px grid.
Color Scheme
After the research is done and we have a vision of the product in our head, we can start with colors. It is a good idea to begin with establishing what will be the main color, additional color, text color, as well as success and error colors. In iteo we use colors and any additional shades are the main color with transparency imposed. This way we reduced the number of hexes and made the implementation much easier for developers. Of course, there are cases where we create shades based on completely different hexes, but we mainly rely on the transparency of the main color.
An additional interesting fact is that if we create colors for light and dark versions in our design system (that is, the colors have their specific counterparts), we can easily and cheaply implement such versions, and in the company, we just need to design one of them, and then generate light or dark views using the “Lights” plugin.
The plugin works by pulling our colors based on the naming specified above and the plugin automatically changes the main prefix from light to dark or vice versa.
Typography
Regarding typography, I would say that we have undergone quite thorough changes. The complete set of our typography in the product shows right away with a sample text to see how it looks. In addition, we have also listed all the properties of a particular typographic style to make it easier to implement for our development.
Apart from that, in the case of RWD projects, we create separate text styles for both mobile and web versions and try to show what texts correspond with each other in a given version — so that scaling this is seamless and the whole thing retains its target hierarchy.
In terms of font sizes, we don’t stick to any particular rule anymore. The whole simply has to look good in the final result.
The only rule we try to stick to is that the line height should be consistent with our grid, which in my case, must be divisible by 4.
Icons
Another very important step is to design a set of basic functionality icons that we are sure will be needed for the project. While creating them, we can use the ready color styles made beforehand. This way, we won’t have any problem with a quick color change of the icon — without a need to create more options in our components.
In addition, when designing icons, we try to maintain their uniform style. That is, we either go for filled icons, or we go for icons that are based on the outline. If the key visual allows us, we also go for small color accents for the icons (only in specific cases).
Buttons & Inputs
Buttons and Inputs have undergone a major redesign in our company. Thanks to the new options in the “Component Properties” and “Auto Layouts” Figma, we are able to quickly design really complex interface elements that are scalable and highly customizable. We start by creating base states which are an absolute must-have, and these are:
- Empty
- Empty Inactive
- Filled
- Filled Inactive
- Hover
- Error
- Active
- And in the case of web versions of applications or pages, we get a “focused” state
If you are wondering what is a “Focus” state, let me explain. It appears when we use a website without a mouse but with a “TAB” key or when we use computers with touch screens. The first click is a “Focus” state and the second one is a confirmation.
With all this in place, we move on to creating component properties, that is, we set the ability to quickly edit a given text on input or button, the ability to enable or disable additional icons on the left or right, and the ability to select a different instance of an icon, or any additional texts that would show up in the workspace.
With thus prepared buttons and inputs, we already place on our previously prepared boards from the Design System and try to conscientiously describe what and how so that all states and options are completely sufficient for our developers.
Spacings, Blurs, Shadows
Other additional things that we have also begun to specify in our design system as separate tabs are spacing, any shadows used if present, and blurs or dialogs.
In the case of spacing, we specify the most important distances between the elements we use, and assign the appropriate tokens to them, so that everything is clear at deployment.
In the case of shadows, we present them with an example of a simple square, and in addition, we can include a description with values.
The same is true for blues and dialogs.
Rest of Components
At the very end we move on to the creation of components, that is all the other quite important elements of the interface like switches, progress bars, checkboxes, the most important tabs used in our product, headers, tabbars, and all the rest of the essential stuff created from the combination of the small elements above. This is why we call it atomic design.
Making Generators?!
You heard right!
Currently, Figma gives us such powerful possibilities that we are able to create generators for social media posts and for banners to be included in the app. Everything is based on the principle of Component Properties as well as Auto Layouts, so I redirect you to the Playgrounds below:
https://www.figma.com/community/file/784448220678228461
https://www.figma.com/community/file/1100581138025393004
Even non-technical people who have no idea about design can easily create a post, banner, or anything else, and then quickly export it. All this while maintaining 100% of the visual language we have developed for our company/product. We definitely encourage you to explore this option and make life much easier for yourself and your marketing department.
Let’s rock!
After we are done determining our atoms, we can start building our Design System. No matter what we design — a mobile app, a desktop app, or an ordinary responsive website — we need to keep a couple of rules in mind.
Remember to create new components with the ones that you made previously. For example, a chart can be done with the following symbols: an icon, a shade, a shape, a state, and a text. How complex organisms you design with your atoms depends just on you.
We hope this small guide will help you create your own Design System. This way you can give your chaos a dash of organization and clarity. Using it will make your work faster and better.
