Before anyone makes any changes in the name of Atomic Design, which every leader in every team will be eager to do, there are a bunch of foundations that need to be dealt with first. Everyone wants to take on the biggest pain points [usually a couple of core components or some old band-aid solution] and wave the Atomic Design flag over it for an easy buy-in and a good metric at the next quarterly update.
There is often some brief discussion about making sure things are done the right way, but all this goes out the window pretty quickly once the work starts. Please trust me when I say DO THE FOUNDATIONS FIRST.
Everybody wants a quick win.
We did the same thing when we first talked about implementing Atomic Design too. There was this one component, a drop-down box with a million-billion options, that was against everything us designers believe about usability and accessibility. We had it pinned on the wall with a big red target. Fun fact: after a year or so of trying alternatives we came back to the drop-down.
I read through some books and blogs about Atomic Design and, with my fellow designers, proceeded to fall into the “quick win” trap. It felt good! We were solving the world’s problems, our stakeholders celebrated us like Heracles after the Hydra, and we thought we had done such a good job.
This is when a senior member of a grizzled design team would sit me down and explain how I have messed up.
I skipped the foundations.
None of the success of a quick win was worth squat in the long run. Even after reading and preparing to make scalable components, all I really did was make slightly smarter components, broken down into “lego block” pieces.
Oh. In Figma, when you make a thing [a component] you can assign various properties to either use switches to turn parts of the thing [i.e. buttons] on or off, or drop-down options to change parts of the thing [change one button to another button]. This is what “smarter components” means.
I had solved some accessibility and usability concerns, and user testing had me feeling confident about a better overall conversion rate [good for business]. Unfortunately, I had also put the product into one hell of a corner.
I had a system that did not work.
I was pooched! The team now had a heap of work that could have been avoided if we had dealt with foundations the right way first. Unfortunately, this is where I landed and the work had to get done.
Piece by piece, I tore apart every single component, every screen, and every tiny little detail. With all my lego pieces laid out in front of me, I could start defining my foundations.
I should be clear, the engineering team [who I love and appreciate every day] did not like this. Every new foundation I defined meant day’s to week’s worth of work to clean up. It is tough, frankly we are still in the midst of it, but it is also necessary if we are going to support our 100+ different brands and customers. And supporting our customers is the whole game.
So what are the foundations anyway?
[prepare for the boring part]Atomic Design Foundations
Atomic Design’s foundations are elements that are shared across all components, even across an entire product. I have done a cursory summary below, but if you’re serious about Atomic Design, then I suggest researching beyond this summary.
Colours
Colours need to be defined as variables in a system that has multiple layers. The first layer should be a collection of all the colours that will be used. This is usually a few brand colours, some ui colours [like white, grey, black] and signal colours [green, blue, red]. It’s not unusual to have 40 or more colours here. They have boring names like brand-100 or light-blue.
The second layer, which technically belongs to a Semantic Design System but will help you here too, is the semantic layer: colours with names that mean something. It’s a colour that points to another colour. For example, success-light which would inherit colour from light-green.
Typography
Fonts, font sizes, and font weights all need to be categorized and named. There are a few ways to approach typography, but it’s generally closely aligned to what’s in HTML, which is Header [H1 through H5], Title, Body, and Small.
Spacing
The white space between or within elements on a website need to be categorized and named. Usually it’s something like small, medium, large; but I have seen others. For developers, this means defining padding AND margins separately using variables.
Other visual elements
So many elements make up a digital product that it’s hard to capture them all, but they need to be documented. This includes border radius, border width, box shadows, how a mouse behaves, and on and on.
