Atomic design and the dawn of organized UI

Order is nice, order is neat and tidy, order brings peace to our developer minds. Chances are you’re also one of those people who cringe every time a template file is out of that one folder where files are supposed to be, or when SCSS variables are not in the right sequence and you’d go out of your way to reorder them and push a PR for that. Because order is nice.

And that’s why I love frameworks, I get excited every time I’m presented with a new and logical way to organize our work, or a new way to unify the language we use among ourselves at the company, or when that one methodology sounds EXACTLY like that’s what we need for the project we’re just starting.

So you can imagine my excitement the first time I heard about Brad Frost’s Atomic Design. Brad is a very well-spoken person obviously, he conveys the methodology’s main ideas very well and explains what each one of atoms, molecules and organisms are and it just MAKES SENSE. Like with all genius ideas, it’s simple and makes your slap your forehead — “how didn’t I think of this before?!”. Until you decide to use it in a real project.

We at BetaPeak make heavy use of Vue.js for our client projects, so when a large international company came to us with the request to completely rewrite their existing UI using modern frameworks, it was a no-brainer — we’ll use Vue. And what goes well with a component-based front-end framework like Vue? You guessed it — a sweet sweet design methodology to help keep all the components neat, tidy and in order — Atomic Design.

First Try

Right about the time we were beginning the project, I already had some experience with Atomic Design, but on a much smaller scale. My approach in the past has been to build a few components on the fly, then go back on those, identify similar elements and functionalities, and split them into atoms, molecules and organisms. A top-down approach of sorts.

And that works for the most part, if you’re a single developer, working on a small project with limited scope. It works because while you build up those components you subconsciously follow your own ideas of how components will be broken down in smaller and smaller pieces. It doesn’t work on large projects, where you need to build a gazillion components and lead a team of developers at the same time. But we went there anyway.

The first two sprints were a genuine mess. People have a tendency to see things differently and developers, although not perceived as the most creative creatures on the planet, show incredible fervor to see things differently than their peers and go at lengths to prove they can “build it smarter”. So if you have a two-column layout, you’d always have that one person who’ll manage to split it into two rows. It still looks like the mock up, it behaves like the user story describes, but the underlying structure of the markup is non-conventional, it’s not “how you would have done it”.

We ended up with a number of working (but still unsplit) “organisms”, with no apparent similarities both in choice of elements and in general approach to the layout. It was impossible to look at the source code and say “A-HA! So these two components have this and this in common, this shall from this day forward be called SuperAwesomeMolecule”. It wasn’t working, we had to take a step back.

Breakthrough

The solution was the bottom-up approach of course. In hindsight it’s the obvious thing to choose — we’ve seen that conflicting perceptions of the abstract inner workings of a UI component can bring more confusion to the table than provide a common ground for refactoring.

We’ve decided to hold a number of meetings to go over ALL design mockups and literally draw out what we agree are 1) atoms (took two sessions), 2) molecules (two more sessions) and 3) organisms were pretty straight-forwards. Let me clarify something really quick here — we’re a company of doers, we dislike meetings and strive to keep them to a minimum. The fact that it took us 5 separate long meetings to comb over all components, and the fact that we all felt GREAT afterwards is a proof of how much this is the correct approach.

Identifying Bits And Pieces

We decided to use InVision’s Freehand tool to collaborate in real-time so that everyone on the team can express their vision of what entails an atom or a molecule. We would walk through each and every component and ask questions like (props to Alla Kholmatova for the general direction):

• It is a simple bit that we’ll be reusing all over the website, without much of a behavior and more or less a variation of a simple construct like button, paragraph, heading. (probably atom)
• Is this more of a supporting element or a standalone one? Does it have any special behavior or shall we expect any additional functionalities in the near future? (molecule or organism)
• Would it normally be part of something else and be reused within various components, but with its own specific behaviour? (probably molecule)
• Is it a well defined and relatively independent part or section of a page? (probably organism)

Communication, communication, communication…

Defining low-level UI bits (atoms) would in most cases be a relatively easy task. However, distinguishing more complex pieces of the component library, i.e. molecules, can present challenges both in terms of mental load and in terms of having a calm, open and secure communication environment. What I mean is — developers get passionate about tech, and more often than not we tend to lean heavily towards our own opinions, and we quarrel. So a thing to watch out for as a facilitators of such component definition sessions is to interfere and calm the conversation if it gets heated, and promote open discussion without the fear of being scolded by your peers.

Molecule time!

We’ve come to the point where we’ve already defined and developed our atoms. It’s important to understand your atoms’ API surfaces (i.e. their props, events, etc) will likely change the moment you decide to use them in molecules, be prepared for a refactoring session. So how do we identify common structures in our mockups that we can unify under an umbrella name, i.e. a molecule? A few pieces of advice:

• Don’t over-specialize your molecules. Often times it would seem like a particular UI part is specific only to that one component, e.g. a special, weirdly specific little card with a number on it, that’s used only in that one organism called AirlineHorizontalSlider. Don’t call it AirlineNumberCard, try to keep things generic. Even if you don’t have an organism in your library that uses that molecule, imagine ways to reuse it — is it a simple card with an option to specify a number via a prop, e.g. <v-card :number="3" /> or is it a card that you need more flexibility with, maybe add a slot, e.g.

<v-card>
   <number-badge slot=”number”>3</number-badge>
</v-card> 

• Make your components flexible by providing the client the option to swap out virtually every bit of that molecule, but provide sensible slot default contents. This will make you work much easier when you start building out your organisms because it will not force you to go back and extend your molecule props and behavior, you’d be able to just swap them out with a different implementation if you have a weird edge-case or a very specific requirement from the design team.
• Don’t spend hours on what to call that one molecule, just give it a provisional name so that everyone on the team can start referring to that particular piece of functionality as something. This will keep the team from running in circles and will move the discussion forward. You can easily go back and refactor the component name at a later point.
• Use a visual/live library for your atoms/molecules/organisms. We at BetaPeak use Storybook for Vue. This bridges the gap between your design team and the development team. Designers can see what bits and pieces they have at hand to use in their designs, how these pieces function, their variations, etc. Developers, on the other hand, can benefit from live code examples and a live development environment.