Finding a war of words in the sphere of design isn't a difficult search.

The word 'Design' is itself the point of much debate and discussion. What is or isn't design has consumed countless hours before we begin to mention familiar terms like UX or interface.

Similar is the path of design systems. Grown from the stylesheets, guidelines, libraries, and frameworks that preceded, the term design systems will generally spark conversation. Usually, any dissent will hinge on what is or isn't included in a design system. Is it really a design system, or is it just a framework?

The examples I've included below fit directly into that category. My perspective is that design systems are purposely developed over time. Systems aren't created by accident, nor does every project produce or require a design system.

With that bit of housekeeping done, let's discuss some of the sticker points where our words get in the way.

On terminology

If you read enough documentation, you'll discover pretty quickly that universal terminology isn't our strong suit. From one set of guidelines to the next, you'll uncover a bevy of slightly different tweaks to the language used to describe the work being performed.

Consistency can be found in the way each system provides a structure for the assets. Smaller parts always combine to help create more significant parts.

In Atomic Design, author and designer Brad Frost described the breakdown of elements as Atoms, Molecules, Organisms, Templates, and Pages. The biology references work because humans are constructed in much the same way. Atoms combine to make cells and cells combine to build tissue and organs. The elements in our bodies can be connected to make virtually everything we need (aside from external resources like food, air, and water).

Organized correctly, you'll likely have smaller parts (atoms and molecules) and fewer large parts (organisms, templates, and pages).

Remember, the categories displayed below are meant to guide the process. The framework encourages the progressive construction of smaller elements first that eventually produce substantial portions of the project.

Source: newpragmatic.com

While the conceptual structure of Atomic Design is ideal, the terminology might introduce hurdles to your process.

History teaches us that language barriers stifle human collaboration. Even when we speak the same language, the way we use and define the meaning of words can divide people who otherwise easily communicate with one another.

Using terms like Molecules and Organisms when discussing your project with a team or client may confuse them. That's why it is essential to show what you are talking about as you present it.

The agency Heavyweight uses more precise terminology to guide their clients through the process. Anyone familiar with design will recognize these terms: Identity, Elements, Components, Compositions, Layout, Pages.

Similar to the Atomic Design framework, the Heavyweight structure displayed below begins loose then defines itself as the project takes shape.

Source: newpragmatic.com

Know that each team you collaborate with will create a unique environment that will push the framework in new directions. The framework may remain the same, but it is highly unlikely that you'll produce identical assets for any two projects.

As an example, let's study the BBC Global Experience Language system. This is a living document of work. The BBC has broken their system down into three core sections — Foundation, Patterns, and How-To.

From a timing perspective, the designers involved needed to have the Foundation resolved mainly before moving forward. The BBC is a large organization with a long history. Because of this, the organization had many existing products that all could be streamlined into a series of design patterns. Because of this, the pattern library produced was robust and prescriptive in nature.

For all the TBD slots listed in the examples above, a loose framework could produce a comprehensive library of assets, as seen below.

Source: newpragmatic.com

The BBC's How To section is unlisted in the diagram above as it provides a design philosophy for the organization. Whether creating voice interfaces or designing for children, guidance for when to use elements is especially important when working for large entities like the BBC.

Building the parts

While we might quibble over word choice, the pattern remains the same throughout. The smaller pieces combine to create the assets our projects will use.

What isn't entirely clear is what you need and when you need it. Let's discuss the process, but for our sanity, I'll use the Heavyweight naming convention.

Identity

It's entirely possible to begin building components as part of your wireframing process, where you lack any usage of color or type. You can also have your styles for color, type, and grid already established. Whichever situation you find yourself in, just remember that components are magical — because we can update them. So it's great if your Identity is established, but you can always add that later if needed.

Source: newpragmatic.com

Elements

Components do require structure. This is provided by the Elements that you'll create. Things like buttons, search fields, icons, headlines, labels, and all other items that will later be used to form more significant components. Also, any states associated with these smaller items will need to be created for use.

It isn't uncommon to smaller elements as components themselves, so try not to get too caught up in the semantics. If it is a small item, like the form fields below, it's an element. If it is a combination of elements — it is a component.

Source: Microsoft, newpragmatic.com

Components

Why has it taken so long to get to the actual part where we talk about Components?

It's important to remember that components aren't created in a vacuum. We either create new components out of existing parts, or we break existing designs apart so that we can make them into components that can be replicated and updated with significantly greater ease.

Navbars, sign-up forms, notifications, keyboards, cards, and so many more items that you will use over and over again are great examples of things that should be components. With each, we often need slightly different versions to allow us the ability to build and update our work quickly.

Some changed by state, others by color mode, still more are dictated by responsive requirements as illustrated by the AXA navbar components displayed below.

Source: AXA, newpragmatic.com

Composition

As we move into the more substantial portions of the design, the work begins combining several components to construct entire sections.

A single page or dashboard might be built out of four or five Compositions. While a page may host some bespoke elements that won't reside elsewhere in the design, most of the work is being handled by compositions.

Hero units, product features, and pricing calculators like the one displayed below are just a few of the possible items you might use components to build.

Source: Uber, newpragmatic.com

Layout

Underneath everything is the basic structure that governs the spacial usage for the entire project. Without determining how grids will be used in a design, the Layout has not been established. Personally, it's difficult to imagine that any of the prior work is going to align with anything. So for me, this is a much bigger deal than the placement it receives in this Heavyweight orientation.

But (steps off of soapbox) ... the average user will only notice the work that layout does when you haven't done a satisfactory job using the underlying structure. Still, in terms of building up from the smallest to the largest items, it's hard to dispute that the layout of a page is pretty huge.

Source: newpragmatic.com

Pages

At the end of the cycle, we arrive at the actual Pages that are the final output of our work. Your homepage, blog template, analytics dashboard, and F.A.Q. all fall under this final banner.

It's unlikely that you'll be saving many of your full pages as components, but there are some cases in mobile design that would test that guidance.

Source: Great Simple, newpragmatic.com

Associated Exercises

Name	Section
Designing Components	Interface Design