A name is a usage contract
A component name is the first documentation anyone reads, and it is read at the exact moment of decision: 'which component do I use for this?'. A name that describes what the component *is* ('Card', 'Panel', 'Box') says nothing about what it is *for* — so it gets used for everything, and the system rots into a pile of interchangeable rectangles. A name that describes the job ('DisclosureList', 'ConfirmButton', 'EmptyState') makes the right usage feel obvious and the wrong usage feel like a category error — which is precisely what an API is for.
- Name the job, not the anatomy: 'ToastStack' says where it lives and what it does; 'Notification' says what it kind of is and forces a decision every use. When the name ends in the component's shape ('Box', 'Row'), the system is naming furniture, not functions.
- Name the state it manages: 'SegmentedControl' names the state (one of N); 'TabMorph' names a visual effect — the first teaches the system's logic, the second teaches a party trick.
- Names should disagree with misuse: the test of a name is whether using it for the wrong job feels wrong — 'ConfirmButton' on a routine submit should make the developer pause and reach for 'SubmitButton' instead.
- Rename early, rename loudly: the cost of a bad name compounds with every use, so the rename is cheapest in the first month — and a changelog entry ('Card → Panel: it is a surface, not a container') is the documentation the rename deserves.
Ask of every component name:
[ ] Does it say what it is FOR, not what it is MADE of?
[ ] Does the wrong usage feel wrong?
[ ] Does it name the state or behaviour it owns?
[ ] Can a new developer pick it for the right job
from the name alone, without reading the docs?
[ ] Would you search for it by this name?The system is an API
A design system with good names is a pleasure to build with; one with bad names is a place where every task starts with archaeology. The discipline is cheap and the payoff is compounding: names are the interface between the design's intent and the developer's daily decisions, and an interface that tells the truth is the whole game. Naming is not the last step of building a component — it is the design review that happens every time someone reaches for the catalog.