A friend of mine recently shared Brad Frost’s Atomic Design Methodology and I feel the need to do a deep dive into how it impacted me as a designer and why you should stay away from this when designing a product.
Atomic design was pretty big after it came out in 2016, made popular by Brad Frost and Dave Olsen. I know many designers I was following were using this pattern to better structure their components for the web. You have to remember that this is a time where React was in its infancy, people were just starting to wrap their heads around how apps should be structured and components were this new exciting things that made it easier to do that. So very different than nowadays.
We didn’t have Figma, we didn’t have the swathe of tools that were built on the premises of atomic design, but we did have this cool new methodology or approach that put a lot of structure into the mess that was called app design. You can imagine why it was exciting.
The idea behind atomic design is simple. Reality is made up of basic building blocks. We might be familiar with there basic blocks from the table of elements. These simple elements, when combined, make up the infinitely complex reality we perceive. So if this is how nature worked, this is how design can work as well. I full-heartedly agree with that premise, being sort of a naturalist myself.
The Atomic Design Methodology meant that we can separate very complex processes into simple parts, that are easy to understand and that we can combine to create progressively more complex interactions. It’s no coincidence that all web frameworks started around that time. You can see that React devs were already using it to consolidate the component-driven approach of React. Just as designers were trying to put everything in order so as to make the next generation of software possible, the developers were working hard on doing the exact same thing for code.
Moving away from dumping everything in a file like we did with PHP, the new approach meant that everything could be coded into simple components. One component did one thing. You could combine components to do more complex things. Because it was easy to keep track of ever more complex actions, apps like the ones we’re using today could be born. Most of social media couldn’t be possible without that change in approach (I wouldn’t call it a revolution).
Product management as a thing I think appeared around the time when these approaches matured into functional web frameworks and designers started working exclusively with a component-mindset for software design. I guess it was a bridge between what designers and developers were doing independently. Product managers had to know a bit of both how the design world worked and a bit of how the developer world worked. It’s all a natural progression to account for more and more complexity piling on, and layers being added to manage that complexity.
You can see how much of an impact atomic design had if you look at the main tool software designers use now – of course I’m talking about Figma. Figma is built around using libraries of components, that are structured exactly like you’d structure them in web or app components. You start from the smallest, most basic user interface elements. You combine those into more complex bits. And voila, you have complex user experience, made possible by simple building blocks.
On the web, this corresponded to an explosion of UI libraries. As a dev, you had to reinvent the dropdown, the modal, the pop-up everytime you built something new. Now you have an extremely long list of good options where those primitives are ready-made, built so you can use them in your app no matter what framework you’re on.
Tailwind itself is a CSS framework built on the premises of atomic design. Tachyons by Adam Morse was first built as a way to add a layer of structure to CSS. Famously used by the UK government, which to my knowledge is the first to make extensive use of atomic design principles to manage something as complex as government services. Tailwind came as an even more advanced version of Tachyons, giving devs and designers a common, easy to understand language. So we not only have HTML structured according to atomic design principles, we can also style it the same way using CSS frameworks.
All fine and dandy. You can see how much of an impact Atomic Design Principles had on the way software was developed the past years. You could say it was pivotal to everything we see on the web today. So why do I say stay away from it?
In software design, the positive drive to make things progressively simpler is only matched by the drive to not see the forest for the trees. Designers (and devs, although I can’t speak in their name) have an amazing tendency towards structure and order. While that’s often very useful, it often tips over the edge into mistaking that structure for usefulness.
As a software person, you’re making tools for people (no, you are not making apps for users). Your app only works because it has a use case. Meaning it helps a certain group of people achieve something they want or provide something they value. Those people don’t care about atoms, components or frameworks. They just want the thing to load fast and to solve their problem.
We’ll come back to why that’s important. It’s pretty obvious why it wouldn’t be useful to the people using your app, just as the inner workings of a carburator are not important to someone driving a car. But is it important to your team? Here’s where we go into dangerous territory. Because of course, it offers more structure, it’s how nature works, so it can’t do no harm and maybe even help.
The Atomic Design Methodology is deeply rooted in functional decomposition. In other words, you’re reducing the essence of the tool you’re building to its features. This component solves that. That component solves this other thing. The heart pumps blood. The lungs turn carbon dioxide into oxygen. The liver is a basically a filter. Our body is machine. That does what? Are we a machine for reproduction? Is our function to eat and breathe and survive? You see the point here? When you do functional decomposition of a complex system, it tells you nothing about what it does.
Atomic Design suffers from the same flaw. It gives you the feeling of control that you get from structuring things. But it tells you nothing about what those components should ultimately do. That extra frame of reference (atoms, molecules, organisms) because dangerous because it creates its own structure aimed not at your use case is solve, but at how your component works.
Let’s turn back at the ‘users’. The pitfall of Atomic Design is that if you think enough about components in that way, the components start taking a life of their own. And unless you’re very lucky, that strays away from what the users really want. This is because Atomic Design is ultimately functional decomposition. Just as domain-driven decomposition focuses on decomposing based on business needs (wrong!), functional decomposition focuses on the functions a system needs to perform. But ask yourself, is the heart designed to ‘pump blood’? Does it not also need to regulate blood pressure? Does it pump the same at 80 or 160BPM? Can it pump while you’re upside down doing a yoga pose? If a designer and a dev worked on a heart on the premise that if needs to ‘pump blood’ we’d probably be dead.
Nature, like always, kicked our ass again by being more complex than we’d imagine. So I’d argue that even if Atomic Design served its purpose in getting closer to how it works, using that model going forward is not only not useful, but limiting. It would also explain why now, when we have all the components we can dream of at our disposal and its easier than ever to build something, we realise that it was not building an app that was a bottleneck. The real bottleneck is, as always, solving a real need.