GE’s Predix Design System
Our first design system at GE, created in 2012, was similar to many design systems you find on the Internet today. It was designed to appeal to and support a broad audience within GE and contained a large selection of common design patterns (a term I’ll be using to encompass both user interface components and interaction patterns) grouped by function. This was purposely done to drive adoption of design standards by a team of 10 designers trying to get some 40,000 software developers globally to make consistent looking software. dave cronin gives a great talk about the challenges this team faced.
The original system was a success internally, but had some growing pains. It worked well for buttons and text boxes, but didn’t scale to consistently address our needs for more complex patterns such as mapping or data visualizations. The constant need to modify and extend design patterns per application worked counter to the purpose of a design system and introduced inconsistency and wasted effort. Additionally, a design system that simply provided a “kit of parts” also left a lot open to interpretation. This resulted in questions and requests for additional design direction, something unmanageable even when designers aren’t outnumbered 4,000 to one. A more sustainable approach was needed.
A design system should not simply be a collection of user interface components along with some design theory.
With these lessons in mind, we wanted our next generation of design systems at GE to emphasize learning and sharing. A design system should not simply be a collection of user interface components along with some design theory. It should demonstrate how design patterns have been applied in real products and document how other teams have extended patterns for specific use cases. Our goal with this design system is to enable product teams to focus their efforts on the solving for new customer needs, and enable them to share those solutions with the rest of the company.
Starting with Atomic Design
Pioneered by Brad Frost, the Atomic Design methodology is a hierarchical way of organizing design patterns. On the base level (Atoms), there are simple design patterns, like a button, a text box, or a label. An email submission form which combines the button, text box, and label into a more complex pattern is at the next level in the hierarchy (Molecules). Each ascending level in the hierarchy builds upon the simpler patterns found in the levels below. The benefits of this methodology are twofold. First, when documenting a design pattern like an email submission form, the designer doesn’t have to rewrite how buttons or text boxes work. Second, the email submission form provides a real life case study of how to use the button, text box, and label effectively. Atomic Design makes it easier to learn how patterns in a design system work while also making it easier to create content for the design system.
Atomic Design at GE
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
Applications
The Applications level is the entry point to the design system. It is where we document the various applications or products built using the design system. Applications can be thought of as case studies that are entrenched into the hierarchy of the design system. Each Application entry contains the necessary context to understand what the application does, the problem space it exists within, how it meets customers’ needs, and its unique organization of Features.
Features
Features are the interfaces that, when working together, allow users to accomplish a task or solve a problem. As collections of capabilities that provide value to your users and customers, Features don’t necessarily have to be sexy. A feature to manage user accounts and permissions will never grab headlines, but it is incredibly important to the success of many enterprise applications. It is also something that should be consistent and reusable across a company’s various application offerings.
In some ways Features are akin to Pages in Atomic Design. In fact the transition from Pages to Features was the last change we enacted. The reason behind this change was the realization that in enterprise software a single interface very rarely completes one user story. Focusing on a feature instead of a singular page allows us to provide more context as to how and why a user of an application navigates from screen to screen to accomplish a task.
Templates
Templates are not a foreign concept to designers or developers. They exist to document the layout and structure of a section or the entirety of an interface. In Atomic Design, Templates are reserved for the layout of a whole page. In our system we expand on that role just a bit to help eliminate the need for the Organisms level of Atomic Design.
The Case Against Organisms
The elimination of the Organisms level is our largest departure from traditional Atomic Design, but we found it makes the hierarchical structure introduced by Atomic Design much easier to both create and consume content.
We discovered that the delineation between Templates, Organisms, and Molecules was a burden for consumers of our design system. To both our designers and developers it often seemed to be a case of semantics as to which level of the design system common user interface patterns were stored. Simple items like buttons and text boxes could easily be determined to be Atoms, but more complex items such as a time series graph were more ambiguous and required more thought.
Indeed it required an uncommon familiarity with the content of the design system to determine if a pattern was the result of the combination of Atoms or Molecules. We found it more user friendly to remove the Organisms level and distribute its content into the two adjoining levels. Design patterns that dealt more with layout (header, footers) went into Templates, while patterns that deliver more complex interactions (data visualizations) remain in the Molecules level despite the fact that they may contain Molecules themselves.
Components
Components, known as Molecules in Atomic Design, contain the user interface patterns that fall on the moderately complex side of the spectrum. Design patterns for search fields, data tables, and range pickers are examples of items one would find in Components. We chose the name ‘Components’ because it is typical vernacular found in most design systems. We anticipate that Components will be one of the most heavily used levels in the hierarchy for designers and developers alike and we wanted to choose a familiar term for them to gravitate towards.
Basics
Basics, known as Atoms in Atomic Design, contain the design patterns that fall on the simple side of the spectrum. User interface controls that have a standard html tag are the most obvious form of Basics. Buttons, check boxes, and links are examples of the design patterns one would find at this level. Borrowing from Atomic Design, Basics are the smallest structures of a user interface. They can not be broken down any further. The Basics level is almost identical to the Atoms level in Atomic Design, except that we decided to exclude design patterns that document more theoretical constructs and place them into a lower level called Principles.
Principles
Principles, as the name implies, are the guiding principles that designers should reference and respect when creating new design patterns. Principles are the foundational level of the design system and ground it in a predictable logic. Examples of Principles might be the proper use of infinite scrolling over pagination, or how text truncation should operate. The Principles provide philosophical continuity, but don’t provide any actual code.
In Practice
The internal launch of the Predix Design System included design patterns created and documented by the Predix platform design team, as well as patterns contributed by teams building products on top of Predix. Launching with contributions from multiple teams allowed us to fill the entire hierarchy of the design system with content. The Platform team, as the stewards of the design system, provided most of the foundational design patterns for Principles, Basics, Components, and Templates. The product team on the other hand, provided design patterns from the more applied levels of the design system.
The inclusion of design patterns created by multiple product teams not only helped fill out the design system hierarchy — but it has demonstrated how we can achieve our goals of sharing and reuse. Teams are now drawing upon design patterns which have been used in other products, and are eager to share and show off their designs to the rest of the community. Based upon the reactions in the months since the launch, the Predix community within GE is eager both to learn and share new design patterns.
Creating and maintaining a design system is a significant amount of work. Brad Frost’s Atomic Design methodology has been a solid foundation on which to build, and we are firmly committed to the value of a hierarchical design system. We hope that sharing our adaptations of the Atomic Design methodology keeps the public conversation going and provides value to the design community. Internally we are building out design system resources for Predix and other GE design teams, as well as meeting on a weekly basis to share work, get feedback, and grow the design system. We’ll share more of what we have learned later on in the year.
