When two teams call the same thing differently, they lose time. Not a little — but systematically, in every meeting, in every handover, in every documentation. UX Components makes this problem visible for the first time, across ten design systems simultaneously.
That sounds like an academic comparison project. It is. But it hits a real nerve.
#The problem has a name — or actually too many
Take the simple component you use to represent a category or a label. In Material Design it's called "Chip". In Carbon it's called "Tag". Somewhere else it's called "Badge". All three mean the same concept at their core — a compact, often interactive marker.
Still, every system calls it differently. Not because the concepts were fundamentally different. But because nobody ever systematically compared what other teams have already solved.
The result: every team invents its own language. Designers talk of chips, developers of tags, the product team of badges. In meetings, silent misunderstandings arise. In documentation, confusion grows. And with every new team member, the onboarding phase starts over.
#Why this is no small thing
Inconsistent naming costs real working time. That's no exaggeration.
Imagine you onboard a new developer. He looks for "Badge" in the documentation. The component is called "Tag" internally. He finds nothing, asks, gets an answer, and moves on. Ten minutes lost — for a question that never had to arise.
Multiply that by the number of handovers, reviews and iterations in a quarter. Then a naming problem becomes a real efficiency problem.
Add to that: whoever builds or expands a design system often stands in front of a blank page. What should this component be called? How deep should the hierarchy go? Which categories make sense? Without reference, you start guessing.
#What UX Components does differently
UX Components is a reference database that compares components from ten established design systems. You can filter by function, by atomic design level — atom, molecule or organism — and by semantic naming.
What's special about it isn't the idea itself. Individual comparisons have always existed. What's special is the systematisation. You see at a glance how ten systems solve the same task. Not as opinion, but as a structured overview.
That changes the way you make decisions. Instead of blindly copying or naming from the gut, you have an informed foundation. You see patterns. You recognise where consensus exists and where systems deliberately diverge.
#Atomic design as a common language
Another aspect UX Components explicitly addresses: classification by atomic design.
Atoms, molecules, organisms — this model is known in the community, but implementation varies greatly. What one team calls an atom is already a molecule in the next. UX Components shows how different systems classify the same components on these levels.
That's valuable because it helps you calibrate your own hierarchy. Not as dogma, but as reference. You see where the community tends to pull, and can then consciously decide whether to follow or diverge.
#The most common counter-argument
"Every product is different. We need our own language."
True — up to a certain point. Product-specific concepts need product-specific names. But standard components like buttons, inputs, modals, tags? There's no good reason to reinvent the wheel.
Own language for own concepts: yes. Own language for universal UI patterns: unnecessary. UX Components helps you recognise this difference.
#What you can concretely do
If you're currently building a design system or documenting existing components, I recommend three concrete steps:
Look into UX Components before you start assigning terms. Not to blindly copy, but to understand which names have established themselves in the community.
Check your existing component names against the reference. Where do you deviate? Is there a good reason for it — or is it historically grown arbitrariness?
Document your decisions. If you consciously deviate from the convention, write down why. That saves your future team the question that otherwise comes up in the next onboarding.
#No replacement for your own thinking
UX Components shortens the path from "which component do I need" to "how do I sensibly name and build it". That's the concrete benefit.
It doesn't replace the decision. It makes it more founded. And in an area long dismissed as taste, that's real progress.
Component names aren't a style problem. They're a communication problem. And communication problems cost time.
