A brand is not static, it is like a living thing that responds to its environment. Big and small changes happen all the time. If a website has millions of products, thousands of pages and multiple brands making changes is time-consuming and it is easier to deviate from brand consistency. Over the years a beautiful website can turn into a bit of a Frankenstein.

There is a way that is designed to be flexible and consistent from the very beginning, it is called “Atomic Design”. The idea of atomic design was introduced by Brad Frost. He is a well-known web designer, speaker, writer, and consultant. Through atomic design, he introduced a methodology to create and maintain effective design systems.

He quoted that-

In searching for inspiration and parallels, I kept coming back to chemistry. The thought is that all matter (whether solid, liquid, gas, simple, complex, etc) is comprised of atoms. Those atomic units bond together to form molecules, which in turn combine into more complex organisms to ultimately create all matter in our universe.


What is Atomic Design?

Atomic design uses atoms, molecules and organisms to create something completely adaptable helping the website to flourish. It's a way for breaking down user interfaces into their most basic components, which are subsequently utilised throughout the website. It is divided into five levels.

Levels of Atomic Design
  1. ATOMS
  5. PAGES


Atoms are the most fundamental elements of building blocks that are yet functional HTML elements that cannot be further broken down such as buttons, typefaces, and search boxes.



Molecules are formed when atoms come together. Components such as heroes, alerts, and search navigations are referred to as molecules. They are simple, reusable components that can be placed anywhere on a website.



Organisms are more purposeful beings with specific user interface sections. When atoms combine with molecules or molecules with molecules we create organisms. Organisms are things like headers, footers, and stack forms. They make the website more engaging and easier to use.



Templates are like blueprints for page-level structures that are later filled with content. Organisms are sections of a website but they need something to hold them together. Templates are the glue. A template is a home for organisms like a wireframe of a fully functional page without actual content.



Pages are the final stage in the Atomic Design System. These are templates filled with actual content. They are the final UI pieces of the design system and what the user see and experience. Pages have the highest level of fidelity, and because they are the most palpable, they are where most people in the process spend the most of their time, and where most reviews focus.



Consider three atoms, for example, a title, form field, and a button. These atoms do anything when they are separate but when they are combined to form a molecule they have a function- search.


Take this search organism and apply it to a home page template. Now it can be moved anywhere and can also set some standards like image size. In this case even if the content changes this standard remains the same. While testing, if the design is not working or functioning as it should have, we can just loop back and modify our molecules, organisms, and templates to better address the needs or create a new pattern or design. If any change that needs to be done can be done at atom level, across those millions of products and thousands of pages it only takes one change, one little atom, and everything updates. 

What is a BEM?

BEM is an acronym for Block Element Modifier. Block Element Modifier is a methodology that helps you to create reusable components and encourages code sharing in the front-end. BEM was invented at Yandex to develop sites which should be launched fast and supported for a long time. It helps to create extendable and reusable interface components.

Birth of the methodology

In 2006, developers at Yandex started working on their first large projects: Yandex.Music and Ya.Ru. These projects, with dozens of pages, revealed the main drawbacks of the current approach to development:

  • Any changes to the code of one page affected the code of other pages.
  • It was difficult to choose classnames.
  • Typical CSS files had long selectors.
  • ID and tag name selectors were used at the same time, there were no strategies for writing the CSS selectors

So a big project's layout was unmanageable. To avoid this, they decided to set rules for dealing with classes, tags, visual components, and so on. That is how they started formulating the BEM methodology.


To solve these problems, they introduced blocks. A block is a part of a page design or layout that has a specific and unique meaning defined either semantically or visually. In most cases, any page element (either complex or simple) may be viewed as a block. The block's HTML container gets a unique CSS class that uses the same name as the block. 

At present there are so many developers following the BEM methodology. Some important rules to be followed when creating blocks are:

  • You also shouldn't use CSS tag or ID selectors when using BEM.
  • The block shouldn't influence its environment, meaning you shouldn't set the external geometry (margin) or positioning for the block
  • Blocks can be nested in each other.
  • You can have any number of nesting levels.
  • The block name describes its purpose ("What is it?" — menu or button), not its state ("What does it look like?" — red or big).


Elements are atomic nodes inside a block. The developers at Yandex called these inner nodes block elements, or simply elements. The key difference between a block and an element at that moment was:

  • An element can't exist outside of its parent block context.
  • An element can't be detached from the block.

Elements are composite parts of a block that can't be used separately from it. Some important rules to be followed when creating elements are:

  • The element name describes its purpose ("What is this?" — item, text, etc.), not its state ("What type, or what does it look like?" — red, big, etc.)
  • The structure of an element's full name is block-name__element-name. The element name is separated from the block name with a double underscore (__)
  • Elements can be nested inside each other.
  • You can have any number of nesting levels.
  • An element is always part of a block, and you shouldn't use it separately from the block.


Modifier is an entity that defines the appearance, state, or behavior of a block or element. Some important rules to be followed when creating modifiers are:

  • The modifier name describes its appearance ("What size?" or "Which theme?" and so on — size_s or theme_islands), its state ("How is it different from the others?" — disabled, focused, etc.) and its behavior ("How does it behave?" or "How does it respond to the user?" — such as directions_left-top).
  • The modifier name is separated from the block or element name by a single underscore (_).
  • A  modifier cannot be used alone, it should change the appearance, behavior, or state of the entity, not replace it.

In the above image, one of the tab elements is active. The active state style should be written inside the modifier class and that particular class should be used for the active tab. 

For example: menu_ _link_active, here _active is the modifier

Different Naming Schemes using BEM

  1. Classic
  2. Two Dashes style
  3. CamelCase style
  4. React style

Classic Naming Scheme

block-name_ _elem-name_mod-name_mod-val

The rules for this scheme are:

  • Names are written in lowercase Latin letters.
  • Words are separated by a hyphen (-).
  • The block name defines the namespace for its elements and modifiers.
  • The element name is separated from the block name by a double underscore (__).
  • The modifier name is separated from the block or element name by a single underscore (_).
  • The modifier value is separated from the modifier name by a single underscore (_).
  • For boolean modifiers, the value is not included in the name.



<div class="menu">
  <span class="menu__item menu__item_visible menu__item_type_radio">


.menu { background-color: red; }
.menu__item { color: green; }
.menu__item_visible { display: block; }
.menu__item_type_radio { color: blue; }

Two Dashes style


The rules for this scheme are:

  • Names are written in lowercase Latin letters.
  • Words within the names of BEM entities are separated by a hyphen (-).
  • The element name is separated from the block name by a double underscore (__).
  • Boolean modifiers are separated from the name of the block or element by a double hyphen (--).
  • The value of a modifier is separated from its name by a double hyphen (--).



<div class="menu">
  <span class="menu__item menu__item--visible menu__item--type--radio">


.menu { background-color: red; }
.menu__item { color: green; }
.menu__item--visible { display: block; }
.menu__item--type--radio { color: blue; }

CamelCase style


The rules for this scheme are:

  • Names are written in Latin letters.
  • Each word inside a name begins with an uppercase letter.
  • The separators for names of blocks, elements, and modifiers are the same as in the standard scheme.



<div class="mainMenu">
  <span class="mainMenu-backButton mainMenu-backButton_visible">


.mainMenu { background-color: red; }
.mainMenu-backButton { color: green; }
.mainMenu-backButton_visible { display: block; }

React style


  • The rules for this scheme are: 
  • Names are written in Latin letters.
  • Names of blocks and elements begin with an uppercase letter. Names of modifiers begin with a lowercase letter.
  • Each word inside a name begins with an uppercase letter.
  • An element name is separated from the block name by a single hyphen (-).
  • The separators between names and values of modifiers are the same as in the standard scheme.



<div class="Login">
  <span class="Login-SubmitButton Login-SubmitBtton_visible">


.Login { background-color: red; }
.Login-SubmitButton { color: green; }
.Login-SubmitButton_visible { display: block; }


  • Consistency and predictability
  • Specificity
  • Self documented codebase
  • Maintenance and other benefits
  • Support of CSS Preprocessors like SASS/SCSS

Consistency and predictability

Once you know the scheme of creating css classes using BEM methodology, the class names will be consistent and can be predicted. We should not use tags, id selectors while implementing BEM  methodology.


Since most of the elements inside the block will be having a unique class name as an identifier, it will be very easy to select the specific elements inside HTML pages.

Self documented codebase

A developer would be able to understand the HTML DOM structure with just looking at the CSS file which is following BEM convention.

Maintenance and other benefits

If we want to change the style of a block_element, we just need to update the block level styles, which will automatically update the whole application.

Support of CSS Preprocessors like SASS/SCSS

Let’s see an example of a SCSS file which is following the BEM convention.

.menu {
	// block
	&_ _item {
		// block_ _element
			&_visible {
				// block_ _element_modifier

The above SCSS file will be converted to the below CSS file

.menu {
.menu_ _item {
//block_ _element
.menu_ _item_visible {
//block_ _element_modifier

Does Atomic Design help with an understanding of CSS naming conventions such as BEM?

Yes. Since Atomic Design is about dividing the HTML pages into atomic and molecular levels, BEM is also similar to that methodology. In BEM, a group of re-usable elements are grouped as blocks, which is similar to atoms grouped as molecules.


Atomic Design | Brad Frost

Video: Brad Frost – Atomic Design – beyond tellerrand 2013 (vimeo.com/67476280)

BEMantic: DRY Like You Mean It https://medium.com/@stowball/bemantic-dry-like-you-mean-it-133ea3843d98#.e99b7e4pt

Methodology/BEM https://en.bem.info/methodology/