7 Controversial Myths About Design Systems
In the world of design systems, many dogmas have become best practices. For inexperienced teams, it is often helpful to rely on established rules when creating their very first Design System. However, some architectural and conceptual dogmas are outdated but still prevalent in the market. This article aims to address the 7 most common misconceptions about DS in the ECEMEA markets.
This article summarizes the 7 most common misconceptions about DS that I have encountered in the ECEMEA markets.
Myth 1: A Design System is supposed to be a battleground to fight over
Many roles in today’s product design market try to pull the decision-making rug out from under you. In large companies, UX copywriters suggest completely redesigning an approved design to change a few lines of text. Researchers refuse to democratize processes and want to create wireframes themselves and hand them off to designers for coloring. Similarly, design systems teams hide behind the word “consistency” to tie the hands of designers when it comes to product design.
During my consultancy role with several large design teams in the Middle East, it became clear that their design systems were causing designers to become stagnant and essentially become mere operators of Figma. Design systems were strictly enforced, leaving little room for deviation from approved practices. In addition, as product decisions were made solely by the PM, designers did nothing more than place components from the design system on the layout. Therefore, the argument that strict DS frees up designers’ time for product decisions is invalid. Designers have simply become lazy and UX is limited by the inflexibility of DS. This is due to the lack of a mature product culture in general. For example, a table component in DS does not sort by column, forcing the designer to add a sort dropdown somewhere on the side of the table.
Complicating the problem is the international market. For example, users from LatAm don’t understand a flow of ECEMEA users. But the design system is the same for the whole company and is done by the ECEMEA team. Designers in the LatAm market have to bend somewhere and somewhere spend weeks negotiating with the DS team to add components to the DS or create their own DS, quietly. And for some reason everyone thinks that it is normal for a designer to spend time on fighting. It shouldn’t be.
Unfortunately, this problem existed long before the age of digital design. I see the same thing in developing countries, where the thoughtless use of “Design systems” can be seen in the construction and design of roads. Often they just blindly copy the “experience of developed countries” without correcting it for their unique conditions. We see it in the floor-to-ceiling windows and the huge electricity bills for heating in cold countries. Or in the constant traffic jams that millions of people have to pass through when the road layout is copied from Stockholm.
Solution: Give designers freedom. Constraints should be at the level of topology, hierarchy, naming, pixel perfection. Product consistency should be achieved through processes, not systems.
Myth 2: Decimal values are not allowed
Almost every one of us, designers, thinks that decimal values are something unacceptable. Many mentors and A.I. say that if your Figma/Sketch/Pixso/PenPot source has decimal values, you are a bad specialist and you only came to the digital world from the print world yesterday. Let’s start thinking instead of listening to others. In the browser, the font size is relative. Let’s open any page, for example Chrome settings (Google engineers can’t be wrong, can they?): chrome://settings/. And let’s launch the Web Inspector. We see 24px (1.6em) and a div height of 32.02px. Segoe UI font.
We conclude that the sizes associated with the font are abstract. The default sizes of 16px and 32px only guarantee that the former will be twice as small as the latter. And then there may be nuances with the baseline. We can also see that in the browser there are already decimals, percentages, in the rendered page. Yes, there are no decimal pixels on a physical monitor, but the huge resolutions of modern screens allow more flexibility to play with values + rem and em (not pixels) can generate decimals values. If you have a good design reason for using decimals — well, not advocating, but go for it.
For example, there are fonts that render nicely in decimal sizes, such as Martian Mono. It renders perfectly every 2.5. It’s specifically designed for writing code. Your clients write code? So decimal sizes can provide flexibility. In modern digital, there are cases of decimal values, so feel free to experiment with them. Pay attention to the font hinting. And many browsers round decimals, but we do not just make products for browsers.
If decimal values are used, it is important to communicate this clearly to developers. The use of a decimal font size may be misinterpreted by the developer, who may assume that the designer is being reckless and round up the values in the code. And to an even number, of course.
Myth 3: You can’t use transparent colors.
Transparency can be unpredictable in the wrong hands. If you layer translucent red on top of black, you’ll get a dirty, unsaturated color. That’s a fact.
That’s why many design systems’ teams prohibit colors with transparency altogether to avoid potential problems. Yes, problems are possible. But there is a smarter approach — learning to work with transparent colors will significantly reduce your color palette. A sprawling palette leads to many more problems, including inconsistency and performance. Which is far worse than dirty colors.
Simple example: If you use the base colors #000, #FFF — and add opacity tokens 20/40/60/80% to them, then DS will have 6 values instead of 10. But such a token can be added to any color in DS. If there are 20 colors in DS, there are 24 variables instead of 100.
CSS offers several properties for implementing color overlays, including linear-gradient and background-image and many more. These properties enable the creation of a wide range of shades using a limited number of colors and opacities.
And muddy colors are the responsibility of the designer. If the designer chooses an inappropriate icon, it’s just a mistake. So it is with colors as well. If the designer has untied hands, decent expertise, and no need to fight with the design system team, the problem of muddy colors will not exist.
Myth 4: Outline icons are easier to work with
Straight to the solution. To save time, it’s usually better to keep icons fully fill when exporting to SVG. Especially if the same icon will have multiple sizes. But if you decide to go with outline icons, let me tell you what you’ll have to go through.
Many products use outline icons by default, often with different line thicknesses for different sizes. This creates difficulties for designers when drawing new icons, and there are endless negotiations about the thickness of the stroke. The main argument for outline icons is that the stroke can be adjusted, so it’s flexible. But it is necessary to give away SVG to developers with icons without strokes, just a shape. One way to keep the source code editable and get a fill outline foe developers is to apply “union”, and sometimes spend time to deal with a mess of artifacts and weekly remind everyone about even-odd. It’s also important to control where your designers get their icons from. Mixing drawn icons in figma with ready-made icons from the web imported in SVG format is a big source of bugs. Most shapes imported into figma from SVG or other vector editors often have problems with Boolean operations.
This is all the extra work that I want to avoid.
Another option is to convert the stroke into a filled shape before pushing it to the library. And the sources are saved separately. This is a way, yes.
Suppose you have three different sizes of icons. Usually variants are used for different versions of icons: thin, bold, filled, duotone. And it is better to keep icons of the same style as three separate sets and connect them via preferred values. This way you avoid size inconsistencies.
Many small icon sizes are often not included in the preferred values (20x20 or 16x16), making it quicker to find the right icons.
And in general, it is always better to break components into sub-components and “pull” them into the parent via nested properties. This way you can reduce the number of variants in the main component, from 2000+ to 48 in my case.
But! As soon as you do all of the above, and you will sooner or later on a big DS with about 20–30 products, Figma will start sending you “out of memory” banners. Isn’t it easier to use filled icons and not create complex structures?
Myth 5: The bottom sheet is simple
An ordinary bottom sheet that slides up from the bottom of a mobile screen. Many people think it is a very simple component with a fixed height.
Let’s talk about height and different localizations. In different localizations, the height of the bottom sheet depends on the text and the local requirements of the regulators (what information should be displayed).
The height of the bottom sheet should adjust to the content, or be fixed at half screen height (50%) with a scroll if there is a lot of content. Or it should expand to full screen at once. All these should be props of a component with adaptation to the content, i.e. if the bottom sheet still overflows with content, it switches to the full screen version + add a scroll.
Another important question about Bottom Sheets is whether they should be modal, i.e. the interface is behind the Bottom Sheet and not available for the user to interact with. By default, bottom sheets are almost always modal, blocking the interface. However, if Bottom Sheets take up less than 50% of the screen height, it is probably not necessary to block them. For example, this is a typical scenario on a map, where the user has tapped a pin and some information has opened, and because it is non-modal, it is possible to click other pins. There may be a lot of information, but for initial familiarization, the top of the Bottom Sheet is sufficient. This is a typical scenario of the fixed height with unfolding (dragging) to full screen.
It’s a good idea to hide the bottom sheet not only by swiping or tapping the outer space, but also by tapping the close icon. People can tap the icon with their forehead or nose, not just their fingers. I’ve seen and done it myself. If you live in a cold country, your nose is the best way to press the button in temperatures below -30°, but it’s not that comfortable to swipe with it.
If you propose an explained behavior for a button sheet component, a default Art Director may disagree and refer to MD2 and MD3 guidelines. Sometimes their opinion is relevant, sometimes not. But what is certain is that Art Directors are often accustomed to small screens and possess long fingers, it’s not always reasonable to blindly rely on their opinions. You might also encounter the opinion that if we require a button sheet component with the mentioned props, we will call the entire design department to converse and determine as a team. It is not a nice process to do things. Because designers should not spend a lot of time searching for information and negotiating, they should work quickly and predictably. We have to design navigation components correctly right away, that’s how planning works in good teams.
Myth 6: Screen flow scheme for presentations
A lot of designers looked at the portfolios of big design studios and found a screen flow with arrows between mobile screens. And suddenly they started drawing similar screen flows and showing them to clients during presentations. Well, friends, arrows between screens are not for the primary presentation. Arrows help show the tree view and imply a non-linear narrative. That goes completely against the idea of a presentation as such, a presentation is always linear. Your client thinks linearly, their life flows linearly, and screen flow goes against that way of thinking. Screen flow is part of the technical work, like defining requirements for the development team, it’s not part of the investor presentation.
Myth 7: Designers define CSS naming conventions
CSS is seen as a simple description of properties. This carelessness leads to inconsistencies in class naming. As a result, the same styles for elements can be named differently. A familiar situation: the color #FF0000 is called warning, red, secondary, and text_error.
This is a consequence of not understanding the process of creating a new component within an existing architecture. And there is a solution, it is called methodology. There are two key ones: Write Everything Twice (WET) — semantic ideology, or Don’t Repeat Yourself (DRY) — functional. Both principles are not ideal: the first pollutes CSS by duplicating the same properties in different classes. The second pollutes HTML by repeating classes in tags of identical elements. The flaws in both cases are often fixed by preprocessors like SASS. Now, details:
First, we will look at the functional (DRY), and its very popular methodology for organizing CSS — OOCSS. It is based on the division of element styles into structure and design.
Structure styles can include height, width, padding, margins, and anything else that affects the positioning of the element on the page and the content within it.
Design styles — colors, border radius, shadows, and other decorative features.
Let’s contrast something from the world of WET with DRY. This is the once popular semantic BEM. BEM stands for Block, Element, Modifier.
- Blocks are components that can be reused many times within a project.
- Elements are components of a given block.
- Modifiers are responsible for properties of a block or element that change its appearance or behavior.
Each is a class with its own purpose. BEM-written names are easy for developers to read. BEM has its own rules for writing classes:
.block-name__element-name_modifier-name
In practice, it is better to abandon the documentation in favor of an unofficial but readable version:
.block-name__element-name — modifier-name
In this case I made a div with 2 buttons. If I want to reuse the `.form__product` element styles and its modifiers `.form__product — primary` and `form__product — secondary` outside of the List block, I will have to create a new block with the same styles, but with a different naming from the block name. So I won’t be able to reuse element classes outside the blocks, I will have to create a component from scratch and duplicate the same properties from class to class. This is the main problem with this and any other semantic approach. At one time BEM solved the cascading and specificity problem by not using selectors other than classes, but this can now be solved with CSS Layers.
Let’s get back to DRY, namely the Atomic Methodology. The essence of this method is to split styles into classes with a property and a value for the property, and then build HTML elements from them as a constructor. In essence, it is analogous to inline classes. The method is similar to OOCSS, but in OOCSS these “parts” of styles can be more complex and contain many properties. Examples:
.lh–16— line-height: 16px;
.fwbold— font-weight: bold;
.mb-8 — margin-bottom: 8px;
The peculiarity is that they can be written directly in HTML by linking a pre-created atomic library. Classes are widely reused in completely different elements throughout the project, this is their difference from BEM elements and modifiers, which are bound to a specific block. The advantage of atoms is instant customization of a particular element.
However, there is a drawback: the duplication of classes in similar HTML elements makes it challenging to edit them simultaneously, which lacks a component approach.
The buttons in this example follow the same pattern as in OOCSS, where each button is made up of multiple classes, with each class responsible for one property.
There are many different methodologies, OOCSS, ACSS and SMACSS. And that’s not to mention new ones like Cube. bem, &&&css is generally the way to solve css problems. But if everything is so nice, why did I put it here as a myth?
You could be inspired and run off to prove to the team that we will reuse everything and that there will be structured, beautiful names for all the components. The reality is far from this. Many developers will tell you that atomic classes make the code very dirty, and they find it hard to read such code. It is believed that the developer experience on a large project is better when individual components are written, each component has its own class, its own modifications. I usually use GitHub as an example, which uses atomic classes. But again, it turns into a battleground where you are not right…. designer.
A really complex and well-structured project use compound components, eslint-plugin-boundaries, style dictionary. And Tailwind for atomicity, ideally along with some sort of MUI. All of this imposes certain technical constraints on naming and structure that designers need to understand and take into account in their design.
I hope this article has broadened your horizons regarding the flexibility of mature and modern Design Systems. Remember that every decision for your product should be based on real team/user needs rather than internet articles, including this one.
