Dubbed the “Predix Design System” as GE’s new Predix industrial internet platform is the first to utilize the structure, it was not purpose built for this one product. GE Healthcare is using this same structure to organize their next design system for their entire product catalog. We began with the intentions of maintaining the Atomic Design taxonomy as defined by Brad Frost. We didn’t want to take the great work Brad has done with Atomic Design and just change the labels to make it a “GE thing.” Our goal was to keep it intact and leverage all the great documentation and videos available on the Internet to teach our colleagues about what makes this methodology so useful.

As we worked on interpreting Atomic Design for the enterprise however, we ran into two issues: taxonomy and scalability for our context.

The commentary that follows was informed less by the intuition of our designers, but more from the practical effort of creating an enterprise level design system and the result of many rounds of iteration.

Issues with Atomic Design Taxonomy

As we showed our initial design system concepts that used the Atomic Design taxonomy to our colleagues, we were met with some confused looks. People were puzzled as to why a website about software design prominently featured words they had last seen in high school chemistry. The metaphor didn’t endear the concept to our users, nor did it increase engagement. We found the taxonomy was simply a barrier to explain and overcome. The evidence was clear, for this to be successful within our organization we had to make the taxonomy more approachable.

Ultimately breaking from the Atomic Design canon was a positive move for us. Sure, we lost out on all the great training material, but it really allowed us to repurpose the levels of the hierarchy to fit the needs of what we are anticipating will become a very large design system spanning multiple products.

Scaling the Atomic Design Concepts

Inverting the Hierarchy

Brad Frost presents Atomic Design beginning with the Atoms level, whereby he describes how Atoms are combined to create Molecules. He starts with the most abstract level, and ends with the most concrete level of a fully designed webpage. Pattern Lab, a website generator to document Atomic Design systems, also follows this sequence of presentation. Presenting Atomic Design in this way works well when trying to educate someone on how the levels of the hierarchy build upon themselves, however we have found that it may not be the best way to actually engage with the design system.

An important requirement we have for our new design system is to be a resource for learning. We want designers to be able to come to the design system website and not just learn what patterns are available, but also how to apply these patterns in appropriate and meaningful ways. To do so the designer needs context — context about the problem space, what a user is trying to accomplish, and how the given patterns facilitate that accomplishment. This context only exists on the most concrete levels of Atomic Design where fully formed pages and applications are documented. It is at these levels where we should direct designers seeking to learn how to apply the design system.

Extending the Taxonomy

In addition to inverting the hierarchy, we found practical value in adding two levels of abstraction: Applications and Principles. Applications provide a place to document overall product and business information to give context about how and why the pages within an application are organized. Principles were added below the Atoms as a repository for our generalized interaction patterns; patterns such as how and why to use animations or the proper way to truncate text. These are the foundational patterns that designers should be aware of and follow when creating new patterns, but don’t by themselves have any source code. Both Applications and Principles will be discussed in more detail later.

The Structure of a New Design System