Patterns vs Components

In the early days of design systems (the long long ago), any group of reusable UI elements was commonly referred to as a "pattern library". Over time that language evolved partly because of influential publications by folks like Brad Frost, and partly because of how the term "pattern" had been historically used in other fields such as architecture. Today, most libraries of reusable UI elements are known as "component libraries".

So then what is a pattern in the context of a modern design system?

The one true answer to that question is; a pattern is whatever works best for your team. Yes, words matter. But the more ambiguous their meaning, the less they matter. The best definition is always going to be the one that makes the most sense for your team, because that will always offer the highest degree of clarity against your team's goals.

With that said, here are some common ways of defining the term "pattern", with my own personal thoughts about each...

A Pattern Is UI Top

Like the heading suggests, this defines both patterns and components as largely the same thing; UI elements. Here, patterns and components are often delineated by complexity or dependency. Complex components that require other smaller components as dependencies are reclassified, or "promoted" from component to pattern. Thus, the pattern is always consumable as a UI element, just like a component.

My challenge to this is that it offers no clear conceptual demarcation between components and patterns. By and large, they are the same things. This can and often does result in ambiguity and confusion. How big does a component need to be before it becomes a pattern? How many dependencies are required for patterns? What if the size of the element and its number of dependencies are in conflict?

A Pattern Is UX Build From Components Top

Using patterns as an expression of the experience can offer an additional layer of consideration to a system. This has pros and cons.

On the positive side, this provides greater insights into how effectively components actually work within the product. Without considering the experience, it's difficult to know whether or not your components are actually solving for anything. Additionally, the delineation between components and patterns is much clearer than the above definition.

On the negative side, this gives the system team one more layer of concern to try and manage. It can be difficult for some teams to get in front of system consumers and truly learn about their preferred experience patterns. Guesswork at the experience level only compounds guesswork at the component level.

Though this model focuses on repeatable aspects of the experience, patterns still require components in order to exist. That means that most patterns are essentially still just really big components, which leaves room for ambiguity when compared against components.

A Pattern Is UX Of Any Kind Top

This model largely shares the same pros and cons as the one above, with the caveat that, in this case, patterns don't actually require any components at all. Instead, they are pure expressions of the experience. In other words, patterns can be composed of any combination of components, workflow interactions, design motifs, and many other things.

I'm a fan of this approach, because it separates the concepts of components and patterns exceptionally well. This is also, in my opinion, easier to scale over time and more supportive of experimentation outside of the constraints of existing system assets and guidelines.

A Pattern Doesn't Exist Top

This way of defining a pattern is to simply not define it at all. Instead, experience guidelines (if present) are categorized as foundations, and components of any size or magnitude are always called components.

On the plus side, this may be the single best way of removing ambiguity between the terms component and pattern. On the other hand, it can also cause other areas of the system to bloat out over time, making them more difficult to maintain and scale effectively.

A Pattern Is What Works Best For Your Team Top

Is it one of the above concepts? Something else entirely? Ultimately, your system needs to work for the people who manage it and consume from it.

So while the aformentioned concepts are all fairly common, it's entirely possible that there's a completely different distinction that works better for your team.

Whichever distinction that is, in my opinion, is the one you should choose. Just do your best to be consistent about it.