Defining clear categories for each part of your design system goes along way to help adoption and maintenance. There are many ways to do this, so here is what worked for me.

Like atomic design?

Like many, listening to Brad Frost talk about Atomic Design was eye-opening for me. The concept of breaking down a design for a website into its constituent parts that were reusable, and therefore consistently used, really resonated with me and changed how I approched designing digital products.

I must admit though, I have always had a hard time figuring out what the difference between a molecule and an organism is. Worse again was trying to communicate with any conviction those decisions. It seemed that I had to be the one to decide which bucket to put an element because I couldn't clearly communicate the rules. That's not a good way to work. As my friend Larry put it, if I won the lottery tomorrow, someone else will be making these decisions.

Starting with Atolls in 2022 as the Design System Lead, I was meant to evolve their initial design system and make it scaleable across all of their products. Unfortunately it wasn't very clear to me how to categorize the different elements, nor was it clear for anyone else.

That's when I settled on a much simpiler grouping; components and patterns.

Clear definitions

Some defining characteristics started resonating with people, and I found it much easier to explain the differences between them.

Component

• A component is a common web interface convention, which is not unique to our products, that the user should reasonably know how to use. Something that just works and we will not waste time reinventing; a button, an input box, a set of tabs

Pattern

• A pattern is a group of components composed expressly to solve a user problem that Atolls has deemed important. It is something that is important for Atolls to get right and worth directly user testing and iterating over.

That simple?

Well, no. I'd like it to be, but there came the question of ownership. At Atolls we've employed a federated design system model. There is a central team that maintains the core and each of the other teams use, consume, depend on its contents. For every other team, they can include component and patterns from other teams, but they can't make changes to them.

In this way, it's very much modelled after object-oriented programming, we are very much after the reusability of the patterns. Additionally, each of our teams are considered subject matter experts on the patterns they maintain and should be unblocked in evolving them as user research dictates.

Take away

The clear categories and definitions that are straightforward to understand are a key ingredient for adoption and continued buy-in for a design system.