Back in the prehistoric haze of design systems, any little cluster of reusable UI bits was slapped with the name "pattern library". That's just what we called it. No one asked questions. But then the winds shifted. Mad prophets like Brad Frost came howling out of the digital desert, waving manifestos and smashing the old lexicon with atomic sledgehammers. Fast-forward to now, and what we once called patterns have shape-shifted into “component libraries.” Clean, efficient, and just sanitized enough for mass consumption.
So then what is a pattern in the context of a modern design system?
The only real answer to that question; the truth, if such a thing exists, is this: a pattern is whatever the hell works for your team. Sure, words matter. Of course they do. But the more slippery and double-jointed a word becomes, the less weight it actually carries. Semantic quicksand. The best definition is the one that clicks with your crew, the one that slices clean through the noise and points squarely at your goals without flinching. Everything else is just semantic foreplay.
With that said, here are some common ways of defining the term "pattern", with my own personal thoughts on each...
A Pattern Is UI Top
As the heading suggests, patterns and components are defined here as two sides of the same twitchy UI coin. Both are interface elements, worshipped differently by different tribes. The line between them? Purely bureaucratic. Sometimes it's complexity. Sometimes it's dependency. Sometimes nothing at all. Slap enough little components together, stir 'em into a glorious pasta of abstraction, and boom! It gets “promoted” to a pattern, like some kind of UI merit badge or magic potion. But don't be fooled. At the end of the day, it's still just a consumable chunk of UI, same as its humbler siblings. We're all eating from the same trough, just arguing over what to name the slop.
Here's my beef. This whole distinction offers no real conceptual line in the sand between components and patterns. Nada. Zip. They might be treated like different species, but in practice, they're the same damn animal, just dressed in different jargon depending on who's holding the whiteboard marker. And that, my friend, is a breeding ground for confusion. How big does a component need to be before it's knighted as a pattern? Is there a sacred number of dependencies? Three? Five? Twelve? And what happens when the size and the dependency count start arm-wrestling? Which metric wins? Nobody knows, and nobody wants to say. We're navigating a semantic swamp wearing blindfolds, just vibes and arbitrary thresholds.
A Pattern Is UX Built From Components Top
This version tries to paint patterns as an expression of experience. A noble idea, sure, and one that adds a whole new layer of philosophical hand-wringing to the system. There are upsides, no doubt. It gives you sharper intel on whether your components are actually doing anything, or just sitting there looking pretty in the void. Without factoring in the experience, you're basically tossing UI spaghetti at the wall and praying it sticks. And hey, it does draw a cleaner line between components and patterns. Some welcome relief from the semantic mush above.
But then the hangover kicks in. Because now the system team's juggling another conceptual layer; an extra cognitive plate spinning in the air. Getting in front of system consumers to understand real experience patterns? That's a luxury, not a guarantee. Most teams are too busy putting out fires to run UX seances. And when you're forced to guess at the experience level, all you're really doing is compounding the chaos that already exists at the component level. It's turtles all the way down, and every one of them is wearing a different hat.
Even in this model, where patterns are framed as repeatable slices of the experience, they still lean heavily on components to stand upright. No components, no patterns. Just vibes and broken dreams. Which means, when you peel back the layers, most patterns are really just a bunch of oversized components in a trench coat, pretending to be something bigger. Sure, they come with experience considerations baked in, but structurally? Same bones. And that's where the ambiguity sneaks back in through the side door. If a pattern is just a big component... then what the hell are we even talking about? We're splitting hairs with a chainsaw, defining things into obscurity until no one actually knows where one ends and the other begins.
A Pattern Is UX Of Any Kind Top
This model doesn't mess around. Patterns here are seen as pure, unfiltered expressions of the experience. Components aren't even necessary. We're talking recurring human behaviors, emotional beats, the vibe, man. A pattern might be made of components like buttons and cards, sure. Or it might be built from interaction flows, layout rhythms, design motifs, or other strange combinations of feedback loops and pixel voodoo. The point is, it's not shackled to the parts bin.
And that's the magic. It draws a bold, glorious line between components and patterns. None of this mushy, size-based promotion nonsense. It scales cleaner. It breathes easier. It leaves the door wide open for experimentation, mutation, and creative chaos, outside the rigid fences of system guidelines. It's a model for people who want to actually build things instead of just managing assets like librarians on the edge of a nervous breakdown.
A Pattern Doesn't Exist Top
This approach takes the nuclear option: it doesn't define patterns at all. Patterns? Never heard of 'em. Instead, any whiff of experience guidance gets dumped into the “foundations” bucket, like a philosophical junk drawer, and everything else, no matter how monstrous or micro, gets stamped “component” and sent on its merry way. Clean. Efficient. Orwellian.
On the surface, it's genius. No more tortured debates over whether a 3-component Franken-widget is a pattern or just a needy component with a God complex. The ambiguity evaporates like bourbon on a dashboard. But the flip side? The system starts to bloat; slowly, then all at once. You've shoved the complexity out of the naming, sure, but now it festers elsewhere. In foundations that swell with ungoverned experience doctrine. In components that grow fat and unwieldy. Scaling becomes a knife fight. Maintenance becomes a myth. And eventually, someone has to pay the bill.
A Pattern Is What Works Best For Your Team Top
At the end of the day, a pattern is whatever makes your team high. Maybe it's one of the models we've just dragged through the philosophical meat grinder. Maybe it's something totally off the grid. Some weird, beautiful distinction that only works for your particular brand of chaos. That's fine. That's great, actually. Because design systems aren't about chasing universal truths, they're about building tools that actually work for the humans using them and the poor souls trying to maintain them without losing their minds.
Sure, all the above ideas are common, well-worn paths through the forest. But that doesn't mean they're right for you. Draw your own damn map if you need to. Just do it with intent, and for the love of god, stick to it. The only thing worse than ambiguity is pretending it's clarity.