Every design system we've worked on eventually has the same fight.
Someone insists the button component should be called <Button>. Someone else argues it needs to be <PrimaryButton> because the plain name is ambiguous. A third person thinks both are wrong because the component isn't really a button anymore once it has an icon slot, a loading state, and a link prop. The thread runs three days. Nothing ships.
What nobody in that thread notices is that the name was never the problem. Nobody has stabilized the language game yet.
Meaning as use
In 1921 Ludwig Wittgenstein published the Tractatus Logico-Philosophicus, one of the strangest and most confident books in 20th-century philosophy. His argument, roughly: every meaningful sentence pictures a fact in the world. Words are labels. Language is logic in disguise. Case closed, philosophy solved.
Then he spent the next thirty years deciding he was wrong.
His later work, published after his death as Philosophical Investigations, took the opposite position. Words don't get their meaning from what they refer to. They get their meaning from how they're used inside specific practices. He called these practices "language games," and his best example of one is the word "game" itself. There's no single essential property that unites board games, sports, solitaire, word games, and video games. What unites them is a web of overlapping similarities, what he called family resemblance.
Meaning comes from use. Of all the philosophy a working designer could steal, I think that's the most useful.
Your design system is a language game
A component named <Button> in your codebase means what your team's use of it makes it mean. Wikipedia, Material Design, and Apple's HIG don't get a vote. It means the set of things your team has actually shipped with that component across six months of pull requests.
We worked with a company once where the <Card> component had ballooned to forty props. Every use that resembled a card had been welded onto it. A dashboard tile, a blog preview, a settings group, a modal body, a checkout summary. By the time we saw the codebase, nobody was using <Card> to render cards. They were using it to render elaborate page sections that happened to have rounded corners.
The team spent a lot of energy trying to rename the component to match what it had become. Rename it to <Panel>. Rename it to <Surface>. Rename it to <Block>. None of the names felt right, because the component's use had become incoherent: it was being pulled into five different language games at once.
The rename didn't fix anything. What fixed it was splitting the component back into distinct uses, stabilizing each one, and then letting the names settle. Once each use was stable again, the right names were obvious.
The people who argue loudest about naming are usually the ones who haven't yet watched the component get used in production. They're reasoning from the dictionary. Ship a few pull requests with the thing in the wild and the name tends to sort itself out.
Family resemblance explains why your tokens keep slipping
Just as nothing essential unites all games, nothing essential unites all "primary colors."
Primary is a family. It's brand accents, CTAs, active states, selection indicators, focused inputs, interactive links. These uses resemble each other without sharing one underlying thing. Each makes its own demands. A CTA might need slightly more saturation to pop. A selection state usually needs a calmer version. A focused input needs enough contrast to read as a ring.
Teams that try to pin tokens to single essential definitions end up fighting their own systems. They decide that --primary-500 is THE brand color, full stop. Then the CTA needs a different hue than the brand header, and the selection state needs a muted variant, and suddenly --primary-500 is wrong in three places and everyone is arguing again.
The Wittgensteinian move is to stop looking for essences. Treat tokens as nodes in a family of resemblances and name them after what they're for. A token called --accent-interactive will age better than one called --brand-primary, because the first describes a family of uses and the second tries to be an essence.
Style Dictionary does this quietly. Radix does it explicitly. Most of the hand-rolled tokens files we've seen in the wild don't, and they're the ones where nobody can agree on what primary means.
The private language argument
This is the strangest part of Wittgenstein's later work, and the one I find most useful.
He argues that a genuinely private language is impossible, in the sense of incoherent, which is stronger than impractical. If only one person has access to the rules of a language, there's no way to distinguish following a rule from misremembering what the rule was. You can't correct yourself against a private standard, because the standard is whatever you happen to remember at the moment you check. Rules require a public, someone who can point at your use and say, "that's not how we use this word."
So a design system that lives in one designer's head is really a set of private associations. The designer feels consistent, because they remember what they chose. Nobody else can correct their memory. When they're sick, the system stops working. When they leave the company, the system evaporates.
Design systems become real on the day a second person uses the system and says, "I used this wrong, what should I have done?" That's the public rule at work: one user being corrected by another. Language games need more than one player.
The most useful thing a solo design system owner can do is get someone else using the system under review. The point is less an audit of the work than a chance for public correction. Without that, all you have is your own memory, dressed up as a system.
Language grows the world
Wittgenstein wrote in the Tractatus that the limits of his language meant the limits of his world. He softened that line later, but the intuition stayed. We can only think clearly about what we can name clearly.
Teams that lack vocabulary for subtle product qualities argue in circles. "I want it to feel more premium." "I want it to feel more approachable." That's two different languages bumping into each other, and neither side has the words to describe what they actually mean.
Writing design principles is, among other things, language work. You're giving the team public terms to think with. "Density serves utility; generosity serves welcome" is a principle that expands what the team can say. It lets someone argue, "this is a density moment, not a welcome moment." Before the principle, they just had taste versus taste. After, they have a claim that can be agreed with, or disagreed with, on shared ground.
The harder a product decision is, the more likely it's a decision that lacks language. Much of the craft is growing the language until the right answer can be said out loud.
Back to the button argument
Back to the thread that wouldn't end.
The members of that team have each seen the component used differently, and each is proposing a meaning drawn from the use they've seen. The fight is productive if it ends with a shared rule that others can follow. It's destructive if it loops forever without one.
The way out is to stop trying to find the correct name. Ask instead: what use are we actually making of this component, across current pull requests? What rule would let someone new on the team use it correctly without asking us? That's the language game the name has to serve. Fix the use and the name follows.
What your system actually is
The uncomfortable conclusion after this much time with Wittgenstein is that language games are what make design systems exist at all. Tokens, Storybook, and Figma libraries are artifacts of the game. What keeps a system coherent across fifty designers is a shared practice of use that anyone can correct and that keeps getting re-stabilized against real decisions.
When the practice breaks, the artifacts stop helping, and no naming convention, linting rule, or governance model will save you. You have to go back to the use, because the system you think you're maintaining depends on a language game you may not have noticed was happening.
This is one of the arguments at the heart of the Philosophical Foundations workshop. We practice it against your actual product, with your team, over the course of a day.
