Atomic Design system with ABEM naming convention
Many times I hear stories about the tense relationship between designers and developers, specially on delivering UI style guides and assets. Being an UX/UI designer working directly with frontend developers, it’s important to understand and share some knowledge for both sides.
On designers’ side, we are concerned about how users will interact with websites, apps or systems; so, this leads us to think over users needs with visual appealing design. On developers’ side, design implementation and connection with backend are the main focus.
When a designer has a solid background of HTML5/CSS3 and Javascript (you don’t need to be an expert 😌), is halfway through to understand developers’ side and to know what you can or can’t design. It helps a lot in the communication between designers and developers and comprehension of technical constraints.
I had to learn HTML5/CSS3 and a bit of Javascript (almost forced, I may say) back in the days that I had to do UI design and development. Against all my fears, I realised that this coding knowledge made huge improvements on my designs and how important is organisation and consistency for the development part.
We all have seen how devices evolved over these last years, and designing and implementing an app or a website has become more complex. Hardware and software differences, various devices with tons of screen sizes and new design patterns made us to rethink how to do our work. It’s easy to get confused and overloaded with all needed requirements and new types of content — social media, artificial intelligence, augmented and virtual reality — coming to our daily lives.
Fortunately, there is a culture of sharing knowledge in our community and new softwares (such as SketchApp, Figma, Invision, Zeplin, among others) have been developed to improve our work as designers and developers. No more slices in Photoshop, heavy files and messy assets all over the place! UI style guides are becoming more flexible and complete, turning into design systems.
It does not rely only on designer’s side; actually is a symbiosis of Design and Development and it’s interesting to see how these two fields are intrinsically connected.
You probably heard and/or read about design systems in last year. If you work alone or with a team of designers, you can share all elements, components and assets in a single place, work in a collaborative way, and see if all UI patterns are visually and interactively consistent. Developers can download all assets, consult styles (some programs and plug-ins convert into CSS code) and implement in a hierarchical and organised way.
In order to build a consistent UI, having in mind all complexity involved, Brad Frost developed the Atomic Design methodology:
Atomic design is a methodology composed of five distinct stages working together to create interface design systems in a more deliberate and hierarchical manner. — Brad Frost
Imagine when you were at your Chemistry classes: you probably have learned there are atoms that all together become molecules and a group of molecules make an organism. This concept can translate into the design and development work: we have single elements (like buttons, inputs, labels) that together became blocks (heros, media, navigation, pagination) and a group of blocks make a component (header, footer, lists, sections).
To construct all pages, we use templates to know how organisms are inserted in each layout. We can see this stage as a wireframe, a low fidelity prototype. At this point, we are beginning to see all elements and how are they going to work together. The next step is to design pages as the final look and feel — a high fidelity prototype. Here you can test your design and predict situations like “how many items lists will be displayed?” or “if a label exceeds the given horizontal space, will have multiple lines or will be hidden?”.
It can be tricky to know what can be an atom, a molecule or an organism when you are doing design systems. To overcome this issue, designers and developers have to solve about that specific situation by asking questions like “what is it going to do?”, “what are these elements?” or “how is it going to be implemented?”. Sometimes this is resolved through a theoretical approach.
So, why did I choose this design system methodology?
Like I said before, communication between designers and developers is crucial, and I have been talking with frontend developer about our next project and he told me that he will use ABEM naming convention that makes CSS easier to maintain. I didn’t know about it and, with his help, I started my research. ABEM comes from Atomic Block Element Modifier, which separates CSS styles into small components. It goes like this:
[a/m/o]-blockName__elementName -modifierName
For a better understanding, let’s imagine there is a button that can have different background colours, depending on the context. In CSS, it goes like this:
I also wanted to try Atomic Design approach and this project just suited well because it is a complex structure, with tons of components that will be reused in different contexts, so a design system that have the same [a/m/o] concept was a great solution for designers and developers. It’s easy to modify and create new elements, designers can see all elements and compare them to obtain more consistency and developers have full access from atoms to complete pages.
Regarding software, I design in SketchApp — amen to symbols, layer and text styles — with Craft plugin to sync with Invision. Developers can consult design systems there, download assets, copy CSS codes, view all styles and measurements, do comments and access to previous versions. I would like to tell you that Invision Inspect has some flaws so be careful when you sync.
To begin with this process, I was inspired by Carbon Design System, Pattern Lab and Salesforce Design System. First step was to design all Atoms, naming them with respective classes that will be used in Sass, adding the prefix “a-” to refer these specific elements are atoms — except on colours and iconography because first ones are variables and icons are SVG sprites. I share with you some examples of what I am doing at the moment:
As you can see, there are classes that will be used on Sass file, with respective modifier and states. There are also small indications like padding, color, type, border and background, global and specific ones, and you may question that if is going to be presented in Invision App, developers can see all specifications at Inspect tool, so why are these specifications written here? In conversation with frontend developer, we agreed that is easier and faster for him to look in Invision on a smaller screen and implement at the bigger screen (btw, we work with two screens :)). He has only to look at it without going to click on each element to see the needed specifications and Invision Inspect is not much accurate with colours that have opacity. It reduces the time by shorting the number of clicks between Invision and coding software.
These written specifications are not meant to be required at all projects; the way you work at design systems is adjusted by design, development and projects needs. Each project is a case study and people have their own methods to improve their work 😉
Regarding checkboxes and radiobuttons, every state is defined, even if they are selected or not. Toggles and sliders are considered atoms instead of molecules because these elements are going to be implemented as a single object. But if you have any doubt, follow the golden rule: ask your frontend developers!
At Photo Avatar atom, there are three avatar sizes, defined by the modifiers -small -medium and -large. Default state has blue background and the first letter of username is white, font size differs according to avatar size. You can see when user uploads a photo for his/her profile, the modifier -photo is added, where the only difference is avatar area is filled with photo, so there aren’t new written specifications.
In near future, I want to do design systems not only in Sketch and Invision, also doing frontend reusable code, just like Carbon and Salesforce have in their design systems. Of course this method can and will be improved by trial-and-error process. Nothing is more powerful in acquiring knowledge than committing mistakes and learning from them 😉
This is part one of work in progress on the project I am in. On part two, I will design molecules and organisms and on part three (or four 😛), I will design templates and pages. I’m going to share with you my experience with Atomic Design and ABEM naming convention as long this project is progressing.
If you want to know more, check these links:
- Atomic Design by Brad Frost;
- ABEM naming convention by Daniel Tonon;
- Atomic design: how to design systems of components by Audrey Hacq;
- Yes, we use Atomic design! What is this? by Ubie Digital;
- Wireframing tools and atomic design: user experience from the bottom up by Emily Grace Adiseshiah;
- Pattern lab;
- Styleguides.io;
- Carbon Design System;
- Salesforce Design System;
Feel free to comment, correct or question and I will be glad to answer. It would be great to share experience from designers and developers as well!
Well, it’s been 2 years ago that I wrote this article. Meanwhile, I moved into a new project, and they have a different approach. That’s why I didn’t write the following parts ;)
