Welcome back to the next instalment of Development for Designers! If you missed the last article please do give it a read. In this article I will discuss my thinking around a school of thinking which arguably bridges the gap between development and design.
The catch-phrase, keyword or concept that you need to get seriously familiar with is “Atomic Design”. Atomic Design was coined as:
“…a methodology for creating design systems.” – Brad Frost
To me, this was a breakthrough. As a developer I know that logic is built up from the smallest concepts; variables, arrays, functions, classes. As a designer, the same applies. I can build something complex from selecting complementary colours, fonts, positive or negative space and shape. Indeed, it’s one giant metaphor for our own human existence.
Essentially, Atomic Design works as follows: atoms form molecules, molecules form organisms. Organisms can be complex or simple. A bacteria or a human being sitting behind this computer writing about the very concept. We are all examples of Atomic Design.
This very methodology is characterised perfectly for web experiences, the IoT (Internet of Things), or mobile development, as it provides an architecture that solidifies simplicity to create something complex. After all, isn’t simplicity the ultimate sophistication?
Systems, Not Pages
Atomic Design is a system. A system that works together with multiple parts to create something unique. It’s a system that can be understood whether you are a designer or a developer, and thus, makes both jobs easy to maintain, change and push forward. Not to mention, it also relieves stress and pressure if, say, a key designer or developer needs to be replaced or leave a team.
Here’s a quick overview:
Atoms
Atoms are the basic building blocks; entities which can’t be broken down any further whilst still remaining functional. They are the HTML tags such as <p>, <label>, <input>, <span>.
Atoms can also be used for colour palettes or fonts. It would be good to note, however, that atoms can be fairly abstract on their own without context. A well defined atom will produce a well formed molecule.
Molecule
Molecules are combinations and arrangements of atoms. Essentially the backbone of your design system. A molecule would be something like navigation or a search form, comprising for example an <input> atom, <label> atom, and a <button> atom. Along with a few more if you felt like creating a complex molecule.
Organisms
An organism builds even further, giving us a combination of molecules. The entire header of a website may be considered an organism. From its base structure, it involves a unique arrangement of atoms and molecules to create a complex organism. A footer section would be considered an organism. If we look at it in context, the product grid within a WooCommerce template would be considered an organism; it repeats the same molecule with different content, or even the same atoms with different values for each.
Templates
Although this section doesn’t really have anything to do with the analogy Brad has been building up, templates can be used or reused to display arrangements of organisms. At this point, layout becomes really essential. Humans start as simple cells, grow to a foetus, a fully formed baby, child, teenager, young adult, and we’ll stop the analogy when we get to our prime. The prime template being an aesthetically pleasing, semantic arrangement of organisms, molecules and atoms. Essentially, we are referring to wireframes that have been developed over time.
Pages
When a template reaches prime, and we flesh it out with images, content and copywriting etc, we have a page. A page for instance would be uploaded to a tool like InVision for basic user testing before going into development.
Conclusion
I will leave you with a few final thoughts. There is no right way to handle the relationship between developers and designers. Building a web experience: be it a website, platform, network, SaaS or PaaS, is about combining the talents and insights of both designers and developers. The one, cannot live without the other. Thus, no project should ever be void of either designer or developer. I’m hoping by the end of this series that you will understand what I’m getting at in a better light, and maybe it will give you some ideas on how to work better with your team mates.
I would also like to mention that as much as this series is focused on developers and designers, it doesn’t mean to say that I don’t acknowledge content managers or copywriters; your work is just as paramount when it comes to making a web experience great.
Now that you have an understanding of Atomic Design, we can really get to work fleshing out how it transcends into design and development.
In the coming articles we are going to deep dive into the respective worlds of front and back-end. If you are a designer, or even a beginner developer, the next two articles will aid you in gaining requisite foundational knowledge. If you’re coming from the design world, or even print, moving toward development, the concepts that I’ll be explaining will aid you in closing the gap in understanding that is the transition from design to development.
