UI Design

Atomic Design, a Promising Co-Creation Method


Atomic Design

At Backelite, we regularly question our workflow and our co-creation techniques in order to be more efficient without jeopardizing a project’s quality and consistency.

With the increasing number of responsive web sites and the new principles of universal applications, our way of designing interfaces is evolving. We need to take a wide range of screen sizes and resolutions into account, as well as interfaces that go beyond the screen real estate (e.g. HoloLens, Oculus Rift, etc.)

So we started to look closely at Atomic Design, a method that seems suitable to the current — and future — context. Developers have already been working with components for a while and it is high time that these methods of interface design and development meet.

Atomic Design: What is it?

Atomic Design is a method of designing by components, explained in detail by the great Brad Frost (


Atomic Design

It is born from a simple fact: the page is a concept dating back to books and transposed to the web. But today, page design is no longer valid. One no longer designs pages, but UI elements which need to find their place in environment of all sizes: from huge (projected on a wall) to tiny (smartwatch screens).

Get your content ready to go anywhere, because it’s going to go everywhere. — For A Future-Friendly Web

We need to stop thinking in terms of screens or pages, but in components and modular systems. And if you think about, that’s what Google does with Material Design: a library of components adapting to various media,

We’re not designing pages, we’re designing systems of components. — Stephen Hay

In detail


It’s an element which, alone, has no functional purpose. It is “irreducible”, cannot be divided, and it’s the basis of any graphical interface element. For example: a logo, a color, a typographic style, an image block, an icon, an input field.

Atomic Design


These are collections of atoms forming simple interface components. Molecules must be designed to be responsive. One needs to define if they are fixed or fluid, and on which device sizes they will display, or not. For example: label + input field + pictogram = search molecule.

Atomic Design



These are more complex combinations of molecules or molecules and atoms. They help build the final interface. For example: search field + nav + logo = header.

Atomic Design



The scientific analogy ends there. All of these organisms will be used to compose interfaces, depending on the different media.

In Brad’s Atomic Design, templates are already developed as code. They can be devoid of real content (for example, lorem ipsum instead of text and placeholders for pictures or icons). They are there to verify the organization and hierarchy of the various created organisms, and test their responsive behavior.

Atomic Design



They are templates which have evolved to be the screen, in its final version. All placeholders have been replaced by real content (text, images, colors, pictograms, organisms and finalized molecules, etc.)

Atomic Design


Iterations between atom/molecule/organism component libraries, templates and pages will, of course, be numerous before achieving the final result (in test & learn mode). That’s why design and implementation teams should work closely together.

It’s not “content then design”, or “content or design”. It’s “content and design”.

And what about creativity?

To me, this design system doesn’t restrict creativity, on the contrary…

We all share the same basic skeleton and the same flesh, and yet the combinations are endless and every person is unique.

The interface designer’s job is to define the proper typography, color, hierarchy reports, graphical components, so all these elements fit together and have a purpose.

The designer may also reflect on the animated behavior of these atoms/molecules (like Google did so well, once again). And of course, follow development (since it is a continuous process) to ensure that the final result matches the team’s shared vision.

Atomic Design comes to life at Backelite

As interface designers, we’ve already been working with graphic component libraries for some time. But usually, we build them at the end of a project, during the specifications phase or just before getting into the massive screen declinations.

The idea behind this new method is to no longer wait until a project’s closure to build its library, but rather pretty much to start with that. That’s again what Brad suggests with his pattern lab ( which can build a common framework for all new projects, a framework that evolves with the design.
We have started testing this method while redesigning ING Direct’s subscription forms. We have designed components independently from each other and quickly integrated them into a StyleGuide to test them within a more global set.

We will, of course, share this experience with you in a future post!