When Everything’s a Design Component, Nothing Is
#022: Why imprecise naming undermines design system ownership in hybrid models.
In most design system conversations, the word component gets thrown around like we all agree on what it means. Spoiler: we don’t.
In one team’s mind, a component is as small as a button. In another’s, it’s a fully functional order status widget. In some cases, a “component” could contain dozens of smaller “components” inside it.
This is more than a semantics problem — in federated or hybrid design system models (where a centralized team manages a core system, and product teams extend it), vague terminology muddies ownership, slows decision-making, and leads to duplication.
Why the Hybrid Model Makes This Worse
In a hybrid model, ownership lines are already more complex:
Centralized DS team: maintains the core system and foundational elements.
Product teams: build specialized patterns and features on top of that foundation.
When the same word — component — applies equally to a button and an order status widget, who owns the widget? The Order team? Or the design system team, because the widget technically contains core components?
Without clear definitions, you can’t have clear ownership. And without clear ownership, governance becomes a never-ending negotiation.
Draw the Line at Complexity (In Hybrid Models)
In a hybrid setup, I argue the centralized design system team should stop well before building complex patterns.
Here’s how I frame it for hybrid:
Particles → design tokens
Atoms → fundamental UI elements like buttons, inputs, icons
(A handful of) Simple Molecules → lightweight, reusable groupings like a form field or search bar
From there, it’s up to the product teams to compose:
Organisms / Patterns → feature-level UI, like an order status widget
Templates / Pages → layouts and full experiences
Why? Because the moment the DS team crosses into organism territory, ownership becomes ambiguous — especially in large organizations with many teams and overlapping priorities.
But Don’t Let Everyone Rebuild the Same Thing
This doesn’t mean “every team for themselves.” The risk in pulling back the DS scope is that product teams will re-invent molecules, organisms, and templates in slightly different ways.
That’s where strong design operations and governance come in — ensuring visibility across teams, alignment on patterns, and a shared registry of what’s already been built.
That’s a topic I’ll cover in a future issue.
The Federated Exception
In a purely federated model, where there’s no centralized team owning the core, it’s a different story. Here, the “everything plus the kitchen sink” approach is more common — complex components, full patterns, and even templates can live in the shared system.
Why? Because without a core team, the shared library has to do more heavy lifting to maintain any semblance of cohesion. You’re effectively “throwing it over the wall” for other teams to use without ongoing stewardship from a central authority.
The trade-off: while it can reduce the need for every team to reinvent the wheel, it also risks bloating the library, locking in patterns that may not adapt well over time.
The Takeaway
If you want your hybrid model to work, stop calling everything a component. Define your taxonomy, draw a clear line between base elements and assembled patterns, and let ownership follow the complexity curve.
Because when everything is a “component,” nothing is truly owned let alone managed.