Sparking joy in a design system

Apr 19, 2021 | Blog, by M. Mastrosimone

Implementing BEM in a cluster of products made with React.js following Marie Kondo’s secret of happiness
Any frontend developer will have experienced the pleasure of opening the newly released page with the Chrome inspector finding a clear and semantic clean code. Not even Marie Kondo could do better!
How many times has it happened to you to review some old code and think: “gosh, how bad is this? ? who assigned the classes? What a mess!“.

At first glance, it might be the work of the former nice but bungling colleague, but Git doesn’t lie and Visual Studio quickly reveals the author – what the heck – it was me to create this obscenity! There might be a positive side: you have improved your skills over the time, and the code you write today is neater than yesterday.
When working as a team on a complex and rapidly evolving product, this individual process takes its toll:
a shared nomenclature system must be adopted then.

Tidying up should be about re-establishing a balance between people, their belongings and the house they live in.” – Marie Kondo


As naming things is a rare talent, adopting a naming convention helps teamwork and turns the giant question mark about how to name an object into an automatic process that follows precise rules, and that – at best- someone has defined before you. It’s reassuring to have both a tidy closet and a uniform code, isn’t it?

Designing an interface thinking in BEM

An interface designer, able to reach a good level of abstraction, may already have in mind the html structure of components while drawing them, from the draft to Figma.
After reasoning about the user experience and the aesthetic research of the interface, the designer can focus on assembling and naming the components and levels to prepare the code development process, anticipating potential development problems.

BEM provides a model that helps to reason in these terms: association between Figma and BEM
component = block,
layer / group = element,
variant = identifier, works well.
Just as our cute Japanese heroine suggests organizing spaces in the simplest way possible, dividing the garments according to a logic grouped by type, so also in designing a mockup it is useful to declutter and group by sets and subsets according to a defined protocol.

It is essential to discuss with the technicians to validate feasibility and nomenclature, and with the help of the FE colleagues, to work on functional and shared solutions for this “chest of drawers” ​​which will mainly serve them.

“Words can be bullets, but they can also be rescue teams” – Jón Kalman Stefánsson



Block_element — identifier

BEM is a convention created in 2007 (read here how it was born) to improve collaboration in frontend development.
Thanks to BEM we are able to assign to the classes of our DOM elements names that are explicit about the type and hierarchy of their content:
Block is the main container that contains a set of other elements, even at multiple nesting levels: our “chest of drawers”, to clarify
Element is the child of the block and distinguishes each of the main sections that contain other elements, the “box that divides the socks”, simply
Identifier is an indicator that changes the appearance of the block or element, as if the labels of the containers transform the shirts into wool sweaters.

An example: l-header, a component of our design system, has an intrinsic structure that can contain strings, objects or other independent components.


.l-header {
   display: flex;
   flex-direction: row;
   padding: 1rem;
   flex-wrap: wrap;
   gap: 1rem;
   align-items: stretch;
   &__title {
       display: flex;
       flex-direction: column;
       justify-content: center;
       align-items: flex-start;
       order: 1;
       flex-grow: 1;
   &__details {
       display: flex;
       flex-direction: row;
       justify-content: flex-end;
       align-content: flex-end;
       order: 2;
       flex-grow: 2;
       flex-wrap: wrap;
       gap: .5rem;
   &__actions {
       display: flex;
       flex-direction: column;
       justify-content: space-between;
       order: 3;
       flex-grow: 0;
       flex-wrap: wrap;
       gap: .5rem;
   &--dark-mode {
       background: @rdb-dark;
       color: @rdb-white;


<div className={`l-header ${modifier || ''}`}>
     <div className="l-header__title">
     {details && (
       <div className="l-header__details">
         { &&}
         {details.two && details.two}
         {details.three && details.three}
     {actions && (
       <div className="l-header__actions">
         { &&}
         {actions.two && actions.two}

“There are only two hard problems in Computer Science: cache invalidation and naming things” – Phil Karlton

Robust CSS architecture

In Radicalbit we have chosen BEM as the reference model among the many conventions available (OOCSS, SMACSS, SUITCSS, Atomic) because its peculiarities are perfectly adaptable to the needs of a design system:

Clear Structure

Having a semantics similar to the React structure allows us to think in terms of components: each component is an easy block to intercept and recognize within the project also in the compiled html.

<div class="l-header ">
    <div class="l-header__title">
        <div class="c-section-title">
            <h1 class="c-section-title__title">
                Microfrontend Title
            <div class="c-section-title__props">
                Title props 
     <div class="l-header__details">
        <div class="c-detail">
            <span class="c-detail__label">Detail label</span>
            <h3 class="c-detail__content">Detail </h3>
        <div class="c-detail"></div>
        <div class="c-detail"></div>
    <div class="l-header__actions"></div>


Each block is made up of distinct units, each performing a specific task and capable of interacting with the others, or being used in different patterns.
Below is our l-header used in various sections of the RNA interface, our MLOps Platform.

data sources


Each component, while maintaining its properties, can change shape or color to match its parent or its identifier.
This is how our l-header changes its appearance based on context and content.In this case the product has the structure of our design system but in light mode and with a different primary color in our product GoLive.

ABEM: a useful adaptation of BEM  

Distinguishing a room from a wardrobe and a wardrobe from a drawer is natural when we tidy up our house. When it comes to a design system, things become more complicated.
Fortunately, some specificities of our method come to the rescue.
The code shared so far has one more module than the Block__element– identifier,  in fact a more recent declination called ABEM (*) allows us a further classification and greater flexibility.
A (tomic) BEM defines the type of block with a prefix of a single letter, while the classes atomic allows the use of global styles, limiting the known problem of  stiffness of the original system.
Our pure BEM react component could have looked like this:

<div className={`l-header l-header--$ {modifier || ''}`}>

instead we have chosen to free the modifier class from the constraint of the containing block.

<div className={`l-header $ {modifier || ''}`}>

In this way, we can also dynamically manage state classes or helpers better described below.

Selector specificity

The ABEM structure is extremely interesting thanks to the openness of the atomic classes but it’s not close enough to the desired solution.  For our structure is ideal to use the self explanatory nomenclature prefix as suggested in this article. We can distinguish the type of block in order to recognize the genre of our selector:

  • Module layout l- l-header l -sidebar l-modal
    These modules have no aesthetic elements and are used exclusively to position components and structure the layout of an application.
  • Component c- c-toolbox c-detail c-tab c-button
    They form the backbone of an application and contain all the features for a standalone component.
  • Helpers h- h-show h-hide
    These utility classes have a single function (and are commonly used for positioning or visibility).
  • States is- has- is-visible has-loaded
    Indicates the different states a c component can have.


Now that you can give your React project a neat style, do you think you can avoid wondering if the element you are using is a title, a paragraph, a label, or a list? Chill out! 

Classifying each object of the dom according to our model does not relieve us from the need to maintain correct semantics in the html by assigning the appropriate tag to the content type, as the style-free page must maintain correct accessibility (web content accessibility guidelines)- for example for automatic code reading systems useful for the blind people and google algorithms, among others.

“Nomen omen (a name, a destiny)”

Naming consistency

The hardest task of all: naming objects so that they are generic enough to be modular, while maintaining the descriptive ability of their content.

Do you really want to call c-consumptions the bar chart block that shows the consumptions in the table?
Indeed, you are creating this new component to show customers’ consumption, but this same component could be useful, for example, to visualize the efficiency detail of a service in another environment where the name could be misleading.
So let’s call it c-chart-micro in order to have a wider level of granularity and, possibly, make the chart an interchangeable component, with a chart area or a small pie chart.


Spring cleaning the codebase

As every April in the domestic habits of European households, even here in Radicalbit it’s time to”spring cleaning”: actually, we are giving a refresh to the design system, creating new design patterns, renewing the existing ones and getting rid of those that did not “give us joy”.

Recently, we are also putting a big effort on moving our Frontend architecture towards a “micro-frontend” approach. Wanting to hear more?  Stay tuned.

Don't miss any update

Sign up now to the Radicalbit newsletter and get the latest updates in your inbox.

Kafka Summit 2022: Keynote highlights

Kafka Summit 2022: Keynote highlights

Hello, Kafka enthusiasts!  Kafka Summit, the premier event for developers, architects, data engineers, DevOps professionals, and streaming data lovers got finally back in person on April 25th-26th at the magnificent venue The O2 in London. Hosted by Confluent, the...

How can a Service Mesh improve your microservices architecture?

How can a Service Mesh improve your microservices architecture?

A wealth of interesting technologies and methodologies has risen in recent years under the “Cloud Native” umbrella name, and their impact in our lives as developers has been very deep. We were once used to have big monolithic applications, hosted on enterprise...

Online Machine Learning: Into the Deep

Online Machine Learning: Into the Deep

Online Learning is a branch of Machine Learning that has obtained a significant interest in recent years thanks to its peculiarities that perfectly fit numerous kinds of tasks in today’s world. Let’s dive deeper into this topic.The cool thing about smart speakers is...