Atomic design

Q: Are atomic design and a design system the same thing?

No. Atomic design is the construction methodology; the design system is often its result. Atomic design offers a grammar for organising components by level of complexity. The design system brings those components together with their usage rules, their documentation and the principles that guide design decisions. You can have a design system without following atomic design, and you can apply atomic design without having formalised a complete design system.

Q: Do you absolutely have to apply the 5 levels of atomic design?

No, and Brad Frost himself acknowledges it. What counts is the composition logic: starting from the simplest elements to assemble towards complex structures. In practice, many teams work with 3 or 4 levels depending on the maturity of their product. The important thing is that everyone speaks the same language, not that the terminology matches the book.

Q: Is it a method reserved for large teams?

Not necessarily. It becomes relevant as soon as a product is shared between several designers or several developers, or as soon as a project is meant to evolve over time. Setting up a clear architecture from the start often avoids months of design debt in the medium term. A small team that anticipates its growth has everything to gain from drawing on it, even partially.

Q: How does atomic design fit together with the code?

That is the main contribution of the method. Atoms correspond to design tokens and to the most basic components on the development side, a React button, a CSS variable. Molecules become composed components. When designers and developers share the same naming scheme, the back-and-forth between Figma and the codebase becomes rarer.

Design method

Atomic design, designing an interface by assembly

For a long time, designing an interface meant drawing pages based on the print model. Screens have multiplied, from watches to wall projections, and a fixed page no longer holds up. Interfaces are now conceived as assemblies of components.

Brad Frost formalised this logic in 2013 under the name atomic design, borrowing its vocabulary from chemistry. An interface is broken down into 5 levels, from atoms to pages, each assembled from the previous one.

The value of the method lies less in the breakdown than in the shared vocabulary it creates. A designer and a developer who say "molecule" mean the same thing, and that thing exists on both sides, a component in Figma, a component in the codebase.

What is atomic design for?

Giving interface components the same names in Figma and in the code
Reusing an existing component rather than redrawing a variant of it for every screen
Spotting duplicates in an interface that has grown, two buttons for the same action, three almost identical cards
Changing an element in a single place, a colour or a border radius that propagates everywhere the atom is used
Documenting a component once, with its variants and its usage rules, rather than answering the same question on every project

Why adopt atomic design?

Setting up or restructuring a design system in an organisation that has many products
Reducing design debt in a product where components have multiplied without a shared logic
Making it easier to onboard new designers into a team with a clear structure

For a long time, designing an interface meant drawing pages based on the print model. Screens have multiplied, from watches to wall projections, and a fixed page no longer holds up: interfaces are now conceived as assemblies of components.

Brad Frost formalised this logic in 2013 under the name atomic design, borrowing its vocabulary from chemistry. An interface is broken down into five levels, from atoms to pages, each assembled from the previous one. The value of the method lies less in the breakdown than in the shared vocabulary it creates: a designer and a developer who say “molecule” mean the same thing, and that thing exists on both sides, a component in Figma, a component in the codebase.

Atoms

individual elements. For example: an image template, a button, an icon.

Molecules

made up of atoms that form a whole. For example: a navigation menu is a molecule, built from atoms like the logo, a button, the various links, and so on.

Organisms

formed from molecules. They correspond to groups of blocks

Templates

which represent the overall structure of the page (but without the final content). Then pages, holding all the final elements (along with text and images)

Still with a view to improving communication and work between developers and designers, it is important to name your components properly. Each element must be named in lowercase, with words separated by hyphens. This convention gives developers elements that are easy to implement. Start with the letter representing your atom (a for atom, m for molecule, o for organism, and so on); then the type of element and its variations.

Example for your primary button: a-btn-primary. Be careful to name components according to their function, not their form (colours, shapes, visual style). Don’t forget that your style guide will evolve. Example not to follow: a-btn-red

Are atomic design and a design system the same thing?

Do you absolutely have to apply the 5 levels of atomic design?

Is it a method reserved for large teams?

How does atomic design fit together with the code?

Bordeaux.fr: a portal that informs Bordeaux residents as much as it serves them, with no compromise on accessibility and eco-design

View the case study

Giving a digital home to design in Nouvelle-Aquitaine

View the case study

Toutvabiens: bringing the two sides of the property market into dialogue

View the case study

Related methods

Design system

A design system is a component library and the governance that comes with it. What sets it apart from a design kit, and when it becomes necessary.

Design pattern

A design pattern is a proven solution to a recurring problem: breadcrumb, modal, accordion. These conventions exist because they work for users.

Design Kit

The design kit, or UI kit, brings together a product's components in a design file: buttons, forms, cards, navigation, icons.

Information architecture

Information architecture organises content and navigation so that users find what they're looking for. It guides interface design

Design Ops

Design Ops optimises the practice of design: tools, processes, handoff, documentation. It lets designers focus on designing rather than on managing.

Interface design

UI design shapes the visual layer of a product: layout, colours, typography, components. It turns the experience into tangible elements.

Curious to learn more about us?

Everyone talks about user experience, service design, ergonomics...
It's not always clear, and you'd like to find out, or sharpen what you already know.

Let's talk