The concepts of atomic design, yes. The terminology no.

The discipline of component-based design is great. Keeping to a limited set of reusable styles and components simplifies things all the way through a project, from design, development and maintenance.

And the core concept is simple: 'Design the smallest bits first. Combine the bits into progressively larger bits until you end up with a page. Don't start with the page and work down. Use only those bits.'

I worked with someone who tried to explain a fairly simple concept to a roomful of people using the helpful, easy to understand analogy of quantum physics. No-one had a clue what he was talking about. The atomic terminology reminds me of this: cute idea, but makes things more complicated in the long run.

I do. I believe that everyone, that uses it, isn't using it as prescribed, — we're using it in a way.

Also, I don't use the nomenclature. Atoms and molecules? Leave that to Brad :)

I use a system that's close, but I don't use the naming convention, and I've added a few rules.

The categories I use are Foundation, Elements, Components, Templates, and Pages.

Foundation are just basic style properties. This includes font definitions, colors, grid structure, and vertical rhythm.

Elements are the basic building blocks, such as icons, buttons, tabs and form controls. In Atomic Design terminology, they can be both Atoms or Molecules. They should never respond to page breakpoints, but can respond to their own size if absolutely necessary.

Components are groups of Elements that form distinct sections of the interface, such as the main navigation, modal window, or a sortable content list. In Atomic Design terminology, these are the same as Organisms. They can respond to page breakpoints if necessary (like a modal window).

Templates consist of mostly Components, but occasionally Elements. They represent the layout and functionality of a specific page type.

Pages are specific instances of Templates.

Hi there! I'm the person that coined the term "atomic design". I created this vocabulary as a way for people (well, myself really) to think of UIs as thoughtful, hierarchical systems. I hope the general mental model is helpful even if the specific labels I chose aren't appealing. As I say in my book:

“Atomic design” as a buzzword encapsulates the concepts of modular design and development, which becomes a useful shorthand for convincing stakeholders and talking with colleagues. But atomic design is not rigid dogma. Ultimately, whatever taxonomy you choose to work with should help you and your organization communicate more effectively in order to craft an amazing UI design system.

I think we can all agree the discipline and logic behind it is sound and extremely useful on large projects. I've used it across many.

The terminology was great for a blog post (essentially marketing), but not that useful in practice.

I use "Atomic Design" via our CSS (atomic classes) however more often than not, designing a UI may require jumping straight to a "molecule" for it to make sense (e.g. a card UI).

Don't make the conversation about atoms or molecules. Make it about the problem you are solving for your users. The hyper focus on "design systems" lately is putting way too much emphasis on UI and consistency. Yes, those things are important, but the MOST important thing a designer can do is solve problems for users.

I totally agree with you. I love the "atomic design" pattern and have read Brad Frost's book (and reference it frequently), but found it awkward to communicate with others about it - especially if they didn't buy into the naming convention. I created a similar framework, that would make it a little easier for my colleagues to understand and buy into since it used more "universally accepted" terminology. Otherwise, the concepts are relatively the same.

Here is a link to project page of the framework I created. You can use NPM to install the CLI to scaffold and maintain your project:

Project Clarion

I do. Years back even when I was doing graphic design. Even letrasets can be considered as a system. 2018 is a beautiful time to be a designer. Brad doesn't introduce anything new with his atomic design stuff. What he did put all the terminologies and methods perfectly so it could even make sense for anyone who's involved with colours and pixels. Those names are used for just for that case. I could build up muscles by rowing and you can beef up at the gym. But in the end, we'll both have muscles. It's the same. Same stuff different methods. What I'd suggest is to read that book without questioning it. I did question what I've read and now I see it was pointless. These books are not 'definite law to do stuff'. Think like extremely detailed professional tips. After a few yrs of experience, you'll see the fruits.

(sorry for the gym example, I'm in a bit rush and that was the most basic example I could come off lol)

Actually I find it very useful for both designers and developers. It helps to create more modular design system for specific project. After you've prepared everything from atoms to organisms, addressing some design problems, doing a/b tests, iterating new versions of pages, creating new pages from existing modules, etc.

From dev point of view; it helps them to create much better file/folder structure that is much more scalable than traditional one.

Here is the blog post about to understand it bit more, written by our design director.

https://wearenolte.com/blog/understanding-atomic-design-approach/

Noticed the same problem in planning design system. It's either scenario-driven nor easy to be understood by non-designers, which will result in design system's failure. We can also find that no big company uses atomic design.

We (at car2go) do. I recently wrote a blog post about it: https://medium.com/car2godevs/brick-by-brick-save-time-with-modular-design-bonus-free-ui-library-6c1a2af2faa4

When we started out I was also skeptical because basically so many new things come in all the time, elements change, it takes a lot of time to build a library, etc. But actually, once you have a system going, it's incredibly easy to create things in your daily work. Of course, when you first need to find a style, it's a different story. But especially when you need consistent output from multiple people, atomic design is the shit.

I kind of do. But it's because I'm a single design/dev who needs a ton of reusability. Eventually I ended up rolling my bits and pieces into a "framework" of sorts and threw it on npm, mostly for myself, since I needed a simple way to distribute the latest version to all my projects.

I don't call it atoms or molecules or organisms though, I dubbed my system 'coeur' and call the pieces heart/head/neck/torso but it follows a similar principle.

It's clearly not meant or designed for widespread use (not well-documented, buggy and probably missing features), but you can use it if you want: https://janzheng.com/stylecoeur/styleguide.html

I believe I do.

I've designed two smaller sized design systems for SaaS apps, as well as helped to design huge design system for Kiwi.com front end as well as our mobile apps. So ...

I agree that the semantics of using words like atoms, molecules, and organisms isn't very clear for people who haven't read Atomic Design book. But as the book itself states, you can call it however you want. You don't have to be so explicit about it. If components and elements work for your environment, then use it without worry.

The logic behind the naming convention resides in whether the thing can be broken down into something smaller. So if you have a form field with a label, you can separate them into atoms. Into two separate entities.

What worked for me the best was adopting the logic for the three most basic levels. Atoms, molecules, and organisms (as mentioned before, you can call them however you want).

• If you can't split something more, or make it more basic than you know you are dealing with an atom.
• If you have two, three or more atoms together, it is a molecule.
• If you have a molecule, with anything else (it doesn't necessarily have to be another molecule or an atom), you know you are dealing with an organism.

The book follows with a higher level of abstraction for pages and others, but this usually gets complicated, and out of the scope, so I stopped using these for now and focus mainly on the three basic stages.