The idea of atomic design has changed the world of designing complex system UIs with the help of the atom-molecule-pattern abstraction. It's a simple way to understand the dynamics and relationships of UI components in web design from the simplest elements (e.g. a button) to the most complex ones (e.g. a dynamic table with a crud feature).
On his website, Brad Frost describes the atoms in the following way:
If atoms are the basic building blocks of matter, then the atoms of our interfaces serve as the foundational building blocks that comprise all our user interfaces. These atoms include basic HTML elements like form labels, inputs, buttons, and others that can't be broken down any further without ceasing to be functional.
Brad Frost (2016, Nov 28). Atomic web design.
I'm going to continue with the atomic metaphor to cover two topics or dimensions that are part of the system building process but from my point of view, the atomic design methodology fails to cover since it's mainly focused on structural elements: properties and structure relationships.
The atomic properties
Fig 1. Atomic Properties and Periodic Trends. (2019, August 8).
One of the most common things I've seen in design systems that are applying this methodology is the definition of an atom itself. For some, the atoms are the core principles (e.g. color, typography, spacing...). Since Brad Frost describes atoms as the building HTML blocks. Where are the CSS properties applied to these atoms represented in the model?
Brad covered this topic in the article "extending atomic design" where he wrote:
In the world of UI, design tokens are subatomic particles. The design token color-brand-blue is a critical ingredient of a UI, but it’s not exactly functional on its own. It needs to be applied to an “atom” (such as the background color of a button) in order to come to life.(2)
A button from the functional point of view is still a button no matter the style properties we apply to that element, but contextually the role a button can play in the interface depending on the visual properties it has is substantially different (e.g. the visual properties define the primary and secondary variants of a button, that express hierarchy in the interface design).
Some authors, like Chris Cid, had acknowledged this gap and created extensions of the atomic design methodology in order to incorporate multiple component variations and shared properties across the different atomic levels.
All types of components —either are Atoms, Molecules or Organisms— are sharing sets of properties which are not captured by the Atomic Design structure.(3)
Chris added a layer with a higher level of abstraction called "Ions" that "store and distribute" all the properties that a component can have (including aspects related to personæ definition or unit testing).
The atomic arrangement
Fig. 2 - Quartz (Left) and Glass (right). Source: Iowa State Univerity - Physics of Nondestructive Evaluation.(4)
In the image above we can see an example of two elements made by the same two building blocks (silicon and oxygen) but what is defining the final form of the material is the spatial arrangement those elements have in the space. The Quartz is crystalline SiO2 (silicon dioxide) and the Glass is an amorphous solid. Fun fact: SiO2 is not a molecule.
Translated to the field of design, the arrangement of the building blocks (even if they are the same) defines the final form an element will have in the interface, the relationship with other elements, and, in the end, the form of the page itself. This arrangement can change also depending on the conditions of the environment since we are working in a fluid medium.
(4) Figure 2 is reused with permission from: ©Iowa State University Center for Nondestructive Evaluation (CNDE).
The euclidean design model
This article is nothing but an intent to extend the atomic design methodology to cover the two areas previously presented. I personally find (and this is my humble opinion) Chris Cid's "Ions" concept a Jack of all trades, master of none, and still lacks to represent the inter-relationships of the different system elements and properties.
I tried to elaborate a model where all the actors involved in the definition of an interface design system were represented, and because we have been talking too much about physics and chemistry since 2013, let's change the field to maths...
It is not only necessary to make sure your own system is designed to be made of modular parts. It is also necessary to realize that your own system, no matter how big and wonderful it seems now, should always be designed to be a part of another larger system.(5)
The euclidean space
Fig. 3 - The three-dimensional euclidean space. Source: Jorge Stolfi (2009, May 23). Illustration of the Cartesian coordinate system for 3D.
What is a euclidean space and what is the relationship whith design systems?
Tip
A Euclidean space is an abstraction of our physical space used by ancient Greeks to prove all geometry by starting from very few basic properties.(6)
The idea behind is to be able to represent every aspect that plays a part in the interface design systems creation in the three-dimensional space like all geometry was tried to be proved by few properties.
A design system, as the Euclidean space, has also postulates or axioms. Any axiom is a statement that serves as a starting point from which other statements are logically derived, this idea resonates to me with the core principles of a design system which at the same time derivate from the ethos(7) of the product.
My intention in this article is not to cover the axioms of the space but the derived properties that model the system, their definition and the relationships between them.
(6) Euclidean space. Wikipedia.
(7) Alla Kholmatova (2017). Design systems. Smashing Media AG, Freiburg, Germany.
Defining design systems in the euclidean space
Adding the two dimensions commented before to the atomic design methodology I ended up with a model with three different axes:
The y-axis - Properties: represent the visual and behavioral properties.
The x-axis - Relationships: represents the arrangement methods in the tridimensional space.
The z-axis - Ingredients: represents the building blocks.
Fig. 4 - Crafting model schema: Ingredients, properties and relationships.
Let's see how the model works with a simple example, a button component. This button structurally has an icon, a label and container:
//Tier 2
<button>
<svg>{button.icon}</svg>
<span>{button.label}</span>
</button>
Following the z-axis: we have a tier-2 ingredient (the <button>) composed internally by two tier-1 ingredients (an <svg> and a<span>).
Then, the button has different visual properties applied to his elements:
/* defaults */
:root{
--color-papaya-100: papayawith;
--color-transparent: transparent;
--color-peach-100: peachpuff;
--border-radius-medium: 0.25rem;
--spacer-8: 0.5rem;
--spacer-16: 1rem;
}
/* variants */
button-primary{
background-color: var(--color-papaya-100);
border: 2px solid var(--color-peach-100);
border-radius: var(--border-radius-medium);
}
button-secondary{
background-color: var(--color-transparent);
border: 2px solid var(--color-peach-100);
border-radius: var(--border-radius-medium);
}
/* modifiers */
button-primary:hover{
background-color: var(--color-peach-100);
}
...And last but not least, the relationships of the elements are defined:
/* relationships */
button{
display: flex;
align-items: center;
gap: var(--spacer-8);
padding: var(--spacer-8) var(--spacer-16);
}
And the result:
After seen how the model works in the surface, probably you'll find some touchpoints between this idea and the SMACSS (Scalable and Modular Architecture for CSS) approach categories. I'm going to go axis by axis describing a little bit more about each axis of our own euclidean space in order to understand how is focused in the design systems definition and development.
References
Ingredients
The ingredients axis is the representation in the tridimensional model of the atomic design principles. The combination of the simplest building blocks (tier-1 ingredients) creates more complex forms (tier-(1+n) ingredients)
Ingredients tier level
Tier 1 ingredients - The most basic structural elements that are used across the system
Tier 2 ingredients - The combination of tier 1 elements
Tier 3 ingredients - The combination of tier 1 and tier 2 elements
Tier n ingredients - And so on...
I'm sure you already know how the atomic design methodology works...
References
Properties
The properties are the elements that define the visual and behavioral representation of the system elements, they affect both ingredients and relationships and are subdivided in three main groups: defaults, variants and modifiers.
Defaults
These are the design decisions that define your whole system. They don't need to be high-level variables that are reused across the whole system, but also specific decisions that affect a particular ingredient or relationship element of the system. Just to make it clear, I'm not entering into the specificity/flexibility of your defaults.
Variants
A variant distinguishes alternative use cases of an ingredient or relationships element. Through variants propertiesm, we define the differences in the visual configuration that are applied to a particular ingredient bringing flexibility to the system.
Note
In some cases, the properties are not enough to define a variant and it's necessary to change the anatomy or the relationships between the inner elements, that's why the three-dimensional model comes in handy.
Modifiers
The modifiers change the base styles depending on the status. Depending on if they are applied to ingredients or relationships:
Ingredients: modifiers could change the base styles whe the ingredient state changes (e.g.
:hover,:focus,:activestates)Relationships: modifiers could change the base styles depending on the available space (e.g. media queries)
Note
If you want to know more about component status design, I recently wrote an article called "State and <main>" talking about that.
Themes
The definition, arrangement and hierarchy of the properties and sub-properties of the model depend directly of the system design requirements, if the system can be themed, for example, the variants, defaults and modifiers could be defined as sub-properties of each theme.
Fig. 5 - Properties hierarchy example. Theme sub-properties
References
Relationships
The relationships dimension defines how the different ingredients are arranged in the space.
The element's arrangement is considered a different dimension in the model since:
They are not simply properties of the ingredients.
They are not only defined by CSS properties but also by the parent/children/sibling relationships in the document tree.
Relationship elements can have variants, default properties or modifiers.
Spacing
Spacing elements help to create both horizontal and vertical rhythms at the same time a well defined spacing scale improves consistency. The space relationships vary from the values applied to the padding, margin orgap of the ingredients to the outline-offset.
Grouping
Grouping elements not only help to create a hierarchy of elements, but also to define how they're going to be displayed and aligned in the space.
Depth
Depth is the only relationships sub-category that work in the third dimension. The depth scale helps to organize the system layers in a more hierarchical way.
@media
I see the @media properties in the same way themes are applied to properties, a category that groups the previously defined relationships sub-groups different values (mostly spacing and grouping) depending on the size of the screen.
