When does naming a component well matter more than designing it well?
On this page
Naming a component well matters most when many people have to find, reuse, and talk about it, because at that scale the name is the interface to the component and a confusing one causes duplication and misuse that no amount of visual polish can fix. A beautifully designed component nobody can locate or refer to clearly will simply get rebuilt, badly, by someone who never knew it existed. The dismissal that the name does not matter and only the design does holds only for a component of one, used by one person, in one place. The moment a component becomes shared, the name is how people reach the design at all.
The reasoning is that on a team, nobody interacts with your component through its pixels first. They interact with it through its name in a search box, a layer list, a code import, or a conversation. If that name is vague, misleading, or collides with something else, the design behind it is effectively unreachable. Someone looking for a notification element searches for what they would call it, finds nothing because you named it Toast, and builds their own. Two people discussing the same component call it by different names and end up describing two things that are one thing. The name is the lookup key, the shared vocabulary, and the contract of intent all at once, and when it fails, the quality of the underlying design is irrelevant because the design is not the thing being used.
A concrete case makes the cost visible. Imagine a perfectly crafted component, pixel-accurate, accessible, responsive, that the team named Card2 because Card was already taken and nobody wanted to rename the original. Six months later, half the team does not know whether to use Card or Card2, several have invented Card3 and PanelCard for needs that Card2 already covered, and a code review is spent untangling which card is which. The design of Card2 was never the problem. Its name failed to tell anyone what it was for or how it differed, so the excellent design fragmented into duplicates anyway. A plainer component with the name TransactionCard, which says exactly what it is and when to reach for it, would have prevented every one of those duplicates despite being no more polished.
Worth naming the exception: naming does not replace designing, and the trade-off only bites at scale. For a true one-off built and used by a single person, the name is nearly irrelevant, because the one person who needs it already knows what it is and where it lives. There is no findability problem when there is nobody else to find it. So this is not a claim that names matter more than design in general. It is a claim that as the number of people who must discover, reuse, and discuss a component grows, the marginal value of a clear name overtakes the marginal value of additional visual refinement, because the refinement is wasted on a component nobody can reliably reach.
It also matters that a good name encodes intent, not just identity. The strongest component names tell you what the thing is for and when to use it, which steers people toward correct reuse and away from misuse before they ever open it. A name like DestructiveActionButton does design work that styling alone cannot, because it warns the next person about when this component is and is not appropriate. That is naming functioning as part of the interface: it shapes behavior at the moment of choosing, which is exactly where duplication and misuse begin.
So treat naming as the interface to the component, especially as more people depend on it. Name components for findability and shared understanding, choose names that say what the thing is for so people reuse it correctly, and resolve collisions by making intent clear rather than appending numbers. Before you call a shared component done, ask whether someone who has never seen it would search for the name you gave it and understand when to use it. If not, fix the name with the same seriousness you gave the design, because at team scale the name is how the design gets used or gets rebuilt.