Defining clear categories for each part of your design system goes a long way toward adoption and maintenance. There are many ways to do this — here's what worked for me.
Like atomic design?
Like many, listening to Brad Frost talk about Atomic Design was eye-opening. Breaking a design down into constituent, reusable parts really resonated with me and changed how I approached designing digital products.
I'll admit, though — I've always struggled to explain the difference between a molecule and an organism, and struggled even more to communicate those decisions with any conviction. I ended up being the one who had to decide which bucket an element belonged in, simply because I couldn't articulate the rule clearly enough for anyone else to apply it. That's not a sustainable way to work — as a friend once put it, if I won the lottery tomorrow, someone else would need to make these calls.
Starting at Atolls in 2022 as Design System Lead, I was meant to evolve their initial system and scale it across all their products. It wasn't clear to me — or to anyone else — how to categorise the different elements. That's when I settled on a much simpler grouping: components and patterns.
Clear definitions
A couple of defining characteristics started resonating with people, and the difference got much easier to explain.
Component
A common web-interface convention, not unique to our products, that a user should reasonably already know how to use — something that just works and we won't waste time reinventing: a button, an input box, a set of tabs.
Pattern
A group of components composed expressly to solve a user problem Atolls has deemed important — something worth getting right, worth user testing and iterating on directly.
That simple?
Well, no. I'd like it to be, but then came the question of ownership. At Atolls we run a federated design-system model: a central team maintains the core, and every other team uses, consumes, and depends on its contents. Any team can include components and patterns from another team, but can't change them.
It's modelled fairly closely on object-oriented programming — we're chasing reusability above all. Each team is the subject-matter expert on the patterns it maintains, and should be unblocked to evolve them as user research dictates.
Take away
Clear categories and definitions that are straightforward to understand are a key ingredient for adoption — and for keeping the buy-in that follows it.
