Mirrored atomicity: designers and developers speaking the same language
How to make it happen
If you like it, don’t forget to 👏
What motivates me to write is knowing that someone liked what they read. So, give me a clap if you see anything that made you think a little bit about something new :)
The concept of atomic design and front-end development is already well established, but here is the problem:
designers and developers tend to create different component structures.
One day, I found myself thinking about why the atomic structure of my layout was different than the one used on the same project’s front-end. I had a “eureka” moment and the term mirrored atomicity came up to me.
At the time, I thought I had all the answers to solve this problem, but I wasn’t even close… this article is about my failures, successes, and good practices around my experiences when applying this idea to the daily lives of a team in a real product.
Premisses I followed
To explore this idea, I started off from the following points:
- Atomic design is good thing;
- “Mirroring the structure” is an idea, but not a life or death matter. The most important thing is that this logic keeps alive during the process;
- Both designers and developers are used to componentizing things. Either with symbols, variables, web components, or any other method;
- In this context, Sketch is the most well-prepared software for the UI work;
- Communication is fundamental, especially among the professionals that are directly involved in a project.
My point of view on atomicity
The foundations of atomic design were there even before Brad Frost and you should understand how to take advantage of this concept in your daily life.
Atomic design is not a technique or a methodology. It’s a concept: componentizing something, from the smallest element to the largest.
Even on different platforms (code editor vs image editor), it’s possible to improve the alignment between design and code by applying the same concept, and from there, a hierarchic tree and similar controls.
Every designer loves to work with symbols, and developers were already componentizing things before you even opened Photoshop for the first time. But is there still room for improvement? There always is :)
I’m not going to take long on this subject since this isn’t new, but I want to make it clear as to why I consider it a fundamental part of the design process:
Consistency
Well-defined components don’t leave room for consistency problems, no matter how many screens your project has.
Flexibility
The logic that “fixed” components generate flexibility might sound conflicting, but I have one word for you: LEGO.
Speed
Once the component set is structured, the construction of new screens becomes incredibly quicker (around 80% faster, from my own personal experience).
Control
An atomic structure naturally implies an increase on the scale of control. If an icon is a quark, by altering it, you alter even the most complex elements, such as molecules or pages.
As a reference, I currently more or less use Suissa’s proposal, made up by Bosons and Quarks, besides Atoms, Molecules, Organisms, Templates, and Pages.
It’s just a button…
How does each one see the same element?
On the front-end, it can be an atom, with controlled properties through quarks (icons, fonts…) and bosons (colors, sizes, media queries, heights, alignments…) or something like that.
UPDATE: Henrique Perticarati mentioned the difficulty some people might have on interpreting these metaphors with physical elements. It’s not my goal to explain Brad Frost’s idea, but you can research more about it here.
The general idea is to go from the smallest element to the largest, it doesn’t really matter if the analogy is made with chemistry, physics, a sandwich, or a car engine… ;)
On design, it is a symbol. On a usual workflow, its variations don’t go beyond copies with altered colors that manually generate new symbols. You could evolve that, applying symbol and text override systems, but even so, without a clear atomic structure, this doesn’t have much value.
This dichotomy interrupts the flow of the work between developers and designers.
It’s as if they spoke the same language, but with very different accents. They can understand each other, but it would be much easier if everyone spoke the same way.
By performing the exercise of mirroring the front-end structure, you can achieve something similar to this:
Mirrored atomicity
Following the same atomic structure from the layout until the front-end.
The theory is simple:
If the UI and the code follow the same componentization structure, this will reduce frictions between designers and developers.
The term “mirrored” comes exactly from the principle of following the same rules of structure, classification, variables, etc. I’ve been preaching this concept for some time, but the truth is that applying it is much harder than I thought it would be when it came to my mind…
The path I’ve been following:
OPENING
Understand the code and design structure
Talk to your developer friend and ask him or her to tell you how he or she works or how he or she could work (in case he doesn’t already) in an ideal scenario (and atomic).
Understand in practice what are the quarks, bosons, atoms, molecules, templates, pages, and whatever other structure you could create to solve a real problem.
Listen, with an open heart, to the problems a developer faces when he gets a poorly done layout and to the suggestions on how this process could improve.
INTELLIGIBILITY
Speak the same language
From now on, when you draw as much as a new rectangle, you need to know that the name of the layer will make a huge difference! A button that was a symbol in your Sketch file now needs to be named according to the same class nomenclature (or equivalent) as your code.
So, if you called a button “button”, but his class was “btn”, you should fix that.
SUITABILITY
Structure your file
I use Sketch to draw interfaces, which doesn’t mean anything. There is a generation of new tools coming out all over the place, and which one of these you will choose is not important. I’m talking about concepts.
Having said that, I believe Sketch is the one among all of them that is more prepared to support the logic of mirrored atomicity. That is because there is a mix of plugins and native features that help in the process of setting up a graphic file that is the closest possible to a code.
In my case, I had to create a new design system and study new ways of designing elements in a way to keep it as close as possible to what happens in the code. It was really hard… In the end, this represented a technical leap between the designers, and it was worth the effort :)
Honorable mention to Subform which has a pretty cool system to store states of an element in itself and that also explicitly uses cascade style sheets (CSS).
EVOLUTION
Share the knowledge
Once the Herculean work of creating files that are aligned at the atomic level is done, don’t let this methodology die with you!
Document everything, expose the case inside your team and company, talk about your failures and successes during this process on meetups. Only then we can mature the concept together!
UPDATE: Macgyver added an advantage to this process and I thought it was a great point of view:
PREDICTABILITY
When the designer manages to be in the same reality as the developer, and vice-versa, it’s easier for both to have a better idea of the task, and that way, break it down so they have the same “size”. With standardized tasks in terms of complexity/difficulty, it’s easier to stipulate goals with delivery expectations.
Applying atomicity on design
To be honest, I’ve been developing this thought on a daily basis as we find technical issues.
Again: this idea is a work in progress.
If you want to help with suggestions, leave a comment in this article! :)
I personally use Sketch and some useful plugins such as Auto Layout and Sketch Runner.
As a standard, I use the first letter of each atomic layer on the classification of the elements inside the sketch. That is only my convention. B for Boson, A for Atom, M for Molecule, and so on.
Bosons
In general, bosons reflect modifications on other elements, for example:
- the color of a text;
- a border radius in a button;
- the size or alignment of a text…
For this reason, the presence of bosons in the graphic file is especially on the adjustment panels.
Having reached a behavior specification (if the symbol is fluid, if the text is aligned to the center and in bold, etc.), save that in styles which reflect these specifications. Don’t forget to be faithful to the same classifications used on the code level.
Examples of bosons modifying texts:
- paragraph/bold (where “bold” is the boson and refers to the paragraph’s bold text style)
- link/secondary (where “secondary” is the boson and refers to the color and underline applied to the text style for links in the website’s footer)
- H2/center (where “center” is the boson and refers to the alignment of the text)
Examples of bosons modifying symbols:
- A/btn/small (where small is the boson and refers to the static dimensions of the button, in pixels)
- M/card/danger (where danger is the boson and refers to the red color in the alert box)
When we think of colors, Sketch still doesn’t support the use of colors as variables that affect many aspects of the file.
To modify the color in symbols, I usually create color symbols that are only squares of an applied color. From there, I apply symbol overrides to change specific colors in elements.
Example 1: Bosons as colors
Which I use to modify a button (which is an atom):
Example 2: Bosons which control position and height
In this case, there isn’t a boson in the shape of a symbol. It is contained on the atom’s adjustments and could be reflected on the same symbol’s classification.
Quarks
These are the simplest elements in the context. They don’t exist “alone” in a layout.
- an icon;
- typographic families…
Example: Quark as an icon
Which I apply in a button (that is an atom):
Atoms
- a button
- a picture of the user in a round mask
- text inputs…
Molecules
- a card
- a search bar…
This is a molecule (dummy table):
This is the same table after changing the symbols and text:
Organisms
- the header of a website;
- a footer;
- a sidebar…
Templates
- a search results screen;
- home page;
- purchase flow screens…
Page
It’s a template with real content, including images, styles, texts, etc.
Get your hands dirty!
The theory is beautiful, isn’t it? Putting it in practice is still a bit hard because of the logic upon which the available software was built.
Photoshop was born with a purpose, embraced the world, expanded, got heavy as hell, released artboards, etc… Adobe XD is amazing and has a lot of potential, but it still doesn’t have everything I need to work, for example.
Sketch is great because it’s open to modifications in the plugin layer. That’s powerful.
There is Figma, Subform, and a lot of others coming. Everyone is attacking more or less the same niche. What will happen, I don’t know!
If you will try to implement mirrored atomicity, tell me what happened! I’m very interested in knowing the failures and successes of other teams.
If you like it, don’t forget to 👏
What motivates me to write is knowing that someone liked what they read. So, give me a clap if you see anything that made you think a little bit about something new :)
