― Finally, since we now also have “color schemes” —aka Dark UI— , all the above variations can be easily doubled:

― For a global projects, we also need to support different languages and writing systems:

― Also, the different statuses after people interact with them:

― On top of that, add all the possible interactions, such as:

These properties and their resulted variations can be easily illustrated if we think of a basic Atom: a button .

All types of components —either are Atoms, Molecules, or Organisms— are sharing sets of properties which are not captured by the Atomic Design structure.

At the same time, I had experienced Design Systems where the components structure suffer from providing massive amound of variations, becoming difficult to keep them organized, creating inconsistencies, and most importantly, becoming difficult to communicate and inefficient to be used by the Design System end users .

The initial motivation to create “Ions”, was that people who are building Design Systems —including myself— where often missing details on the component’s structure. Details that are important for the overall structure, and also for the output consistency and quality.

Atomic Design should continuously be a solid solution when a project becomes larger, always simplifying the complexity of a growing component library. More importantly, Atomic Design should always support the efficiently on adjusting and adapting a living Design System.

While Atomic Design is providing a feasible, easy to understand and adapt solution on the component’s structure, I often felt that it can be improved.

On my previous article “ Atomic Design for Design Systems ” I wrote my experiences adapting the Atomic Design on building Design Systems and on the benefits gained to build systems that can grow successfully.

Ions is an additional layer, on top of the Atomic Design.

By providing hundreds of variations for any component, it is a matter of time to create inconsistencies.

As the Design System grows, we need to always keep these properties aligned, in order to keep consistent output. For example, a “ disable ” button, should share —at least— a similar logic with a “ disable ” input field.

Even a simple Atom can have that many variations, resulting to a massive component library that becomes difficult to navigate, difficult to understand the use cases of all these variations, and as a result, difficult to consume as a pattern library.

Now, imagine that as a Design System user, I just want to use a button; and when I open a Sketch library, I am facing more than 190 variations for just a button!

That is a hell a lot of variations that we need to build, maintain and communicate.

Ions Atoms Molecules Organisms

Ions is the place where we can store all the properties that can be applied to some, or all components, either are Atoms, Molecules, or Organisms. Being an additional common repository of properties that can be shared among components of the Atomic Design hierarchy; while at the same time, removing the complexity of embedding these properties within the Atomic Design structure.

Examples of Ions

To understand the benefits and power of Ions, let’s take a look on some use cases.

Atom: Button

As we describe earlier, a button has quite a lot of properties that we need to define. While we describe the Ions of a single Atom, a “button”; these Ions can be shared both with other Atoms, and also with Molecules and Organisms.

Ions for Atoms Animated graph that highlights how Ions changes are affecting the related Atom components. Ions Atoms Molecules Organisms In the example above, Ions that are assigned to Atoms are highlighted. When an Ion needs to change, the related only Atoms are affected.

Molecule: Buttons group

Molecules consist as a combination of Atoms. Ions are helping us to verify that each Atom with its related Ions, continues to provide a solid UI against other Atoms within the Molecule.

As example, we can think of a group of buttons where one is primary and the other is secondary. By applying to each Atom all the related Ions, we can quickly verify that any combination of Atoms with its Ions, continues to provide a clear message to the user.

Ions for Atoms and Molecules Animated graph that highlights how Ions changes are affecting the related components. Ions Atoms Molecules Organisms In the example above, the Ion that changes affects directly the assigned Atom and Molecules. While through the Atomic Design relations, the related Molecules are also affected.

We might find that the disable primary button shares a similar UI with the secondary button next to it. In that case, we can easily go back to the “disable” Ion that is applied on this Atom, and adjust the styling to differentiate enough from the secondary default button.

Organism: Registration form

On the Organism level, we can validate additional functionality, based even on user stories.

For example, in a registration form that contains —among others— a group of buttons, we can validate how a required field error with its message, performs as UX and UI against applicable Ions.

Ions for Atoms, Molecules and Organisms Animated graph that highlights how Ions changes are affecting the related components. Ions Atoms Molecules Organisms In the example above, the Ion that changes affects directly the assigned Atom only. Through the Atomic Design relations, the related Molecules and Organisms are also affected.

Ions on the whole range of the Atomic Design

Most Ions should be defined at the Atom level. That doesn’t mean that Ions are only for Atoms. There are plenty of cases that Ions are for Molecules or Organisms but not for Atoms. Some examples can be…

Ions for Molecules

An accordion menu is a case that we need to assign Ions on the Molecule level only.

Ions such as, “Multiline labels” and “Narrow viewport” for small mobile screens, to validate that long labels that renders in 2 or more lines remains legible, while the alignment with the icon next to them, remains correctly aligned with the text label, communicating a clear message for the accordion status — i.e. is expanded or collapsed.

Ions for Organisms

A situation‐based Ion, such as “Mobile with one hand usage” is a common case for an Organism only Ion.

In this example, we can verify if a form or navigation Organism provides a structure that allows users to hold a device and perform the expected actions, using only one hand.

How Ions can improve UX

Ions can become the main tool to validate a wide range of UX related scenarios.

Ions for personas

Personas are a group of “properties” assign to a fictional person, creating users to helps us test, prioritize and validate scenarios and user stories.

These “properties” can assigned to existing Ions, or even generate additional Ions.

Since each Ion should always assigned to —at least— one component, by connecting personas with Ions, we are actually creating trackable connections with the related components. Combining that with the Atomic Design structure, we can track personas informations down to the Atom level of components; enabling us to resolve conflicts or any persona related issue, on the core level of the component structure.

Ions and Unit Testing

On software development, unit testing is a “must have” method to track and resolve issues based on different data or procedures. Unit testing is based on testing these “properties” on various realistic, or even extreme scenarios.

These also “properties” can be assigned to existing Ions, or again, generate new ones.

Even more interesting use case, is that Ions can play the role of unit testing on the UX and UI design side. Creating an omnichannel between UX, UI and development, sharing the same automations on testing and validating.

Ions for Design Languages

Design Languages are built around concept and principles, based on the corporate or product vision. Usually Design Languages also are integrating business metrics (such as KPIs).

All these informations, that are the backbone of a Design Language, consist of high‐level “properties”, that can be also assigned as Ions; connecting them with the component structure.

Ions categories

Since Ions consist of diverse type of properties that can —and should— increase as a Design System is growing, is highly recommended to organize them within categories.

Note: The list bellow links to detail tables, to provide (highly opinionated) examples.

Modes For the various display types and entries methods. Viewports For the different screen sizes. Styles For all UI stylings. Variations For multi‐language or content variations. Types For the information types. States For all states of interactive elements. Statuses For all statuses of interactive elements. Situations For situations on use cases or environments.

Why “Ions”

In physics, ion is in fact a kind of property for the electrical charge of the actual atoms and molecules. Also I found that as a term, “Ions” is a well known word for non‐English speakers.

Since I believe Ions can become a very powerful tool, when are placed within an Atomic Design structure, it was an easy and obvious decision on starting using this term.

Conclusion

Ions are a repository to manage the variety of properties that any component can have.

By separating these properties from the main structure of the Atomic Design, we ensure that we are keeping a straightforward structure of components, being always easy to understand their hierarchies and relations.

Ions can be a very powerful tool when we assign them dynamically with the Atomic Design structure — e.g. through JSON mapping. So that at any point, we can track relations both between Ions and components, but also between Ions and the Atomic Design structure. By that, Ions can play a critical role on the scale and growth of any Design System.

Finally, Ions can hold information for various types of UX, IA, Design Language, even high‐level business metrics. Becoming a critical tool to manage, test, measure and validate almost any type of information related to a Design System.