I am working with the CA Technologies Design Center team on Mineral UI, an open source design system aimed towards enterprise software. CA features multiple suites of software all at the enterprise level, some existing for many years. Our goal with the design system can be attributed to three simple design rules: Consistency, usability and accessibility.

Structuring our symbol library

Most of you are probably familiar with Sketch symbols. Symbols are reusable components that layer multiple design elements into a single object. These objects can have different variables to allow for state changes, content changes, or even responsiveness on a primitive level. Of course there are Sketch plugins such as launchpad that allows for advanced responsive design.

Plugins and dependencies other than the core software can get out of sync quickly especially with large teams. To make sure everyone is on the same version and everything syncs properly, we have to limit the number of plugins we use.

There are multiple design system paradigms out there, one of the most popular being atomic design. Atomic design goes by the principle of atoms which are basic HTML elements (such as input fields) that then come together to build molecules which can be input fields plus their labels and statuses, and later organisms which is a form field. It then grows from there into blocks, templates and so on.

Atomic Design

With atomic design as your library grows larger it becomes a full-time job on it’s own to decide what level each element was at (if we were to be strict to the methodology of atomic design). We didn’t have the time and resources to spend on these decisions so we opted for a simpler solution.

Our symbol libraries goes with the simple model of:

Utilities

Anything that is native to HTML, input fields, buttons, checkboxes, etc

Anything that is native to HTML, input fields, buttons, checkboxes, etc Subcomponents

Any element that may be a building block for a component

Any element that may be a building block for a component Components

Stand-alone interactive elements (made up subcomponents)

Stand-alone interactive elements (made up subcomponents) Layouts

Components that define user flows

You’re probably thinking what’s the difference, isn’t all of this just renamed? Not exactly. Atomic design takes a very scientific approach, for example, you cannot redefine an atom as a molecule. With our definitions, we can easily interchange these where it makes sense.

Using the example image given above, we would have to decide if “Avatar” is an atom, “name card” is a molecule, and does that make “Select field” an Organism? What about the full form interface, and the page interaction beyond that? Some companies that have used Atomic design add sub-atomic and other molecular levels to fix these issues. It all becomes convoluted very quickly and we found it much easier for our own sake and sanity to keep a loose definition.