The Language Games of Design

Every design system I'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.

Here's what everyone in that thread is missing. They aren't actually fighting about the name. They're fighting because nobody has stabilized the language game yet.

Meaning as use

Ludwig Wittgenstein (1889–1951). Published one confident book, spent the rest of his life quietly unwriting it.

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. That's the whole move. And it turns out to be the single most useful piece of philosophy a working designer can steal.

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. It doesn't mean whatever Wikipedia says a button is. It doesn't mean whatever Material Design or Apple's HIG says. It means the set of things your team has actually shipped with that component across six months of pull requests.

I 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 I 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 wasn't doing one thing. It was being pulled toward five different language games simultaneously.

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. The language game got re-established. Only then did the right names become 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 become obvious, because the language game has done its stabilizing work.

Family resemblance explains why your tokens keep slipping

There's no essential property that unites all games. There's no essential property that unites all "primary colors" either.

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. The selection state needs a muted variant. Suddenly --primary-500 is wrong in three places. The fight begins.

The Wittgensteinian move is to stop trying to find essences. Tokens aren't definitions; they're family-resemblance nodes. Name them after what they're for, not what they are. 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.

No essential "primary." A family of related uses, each making its own demands. Naming the family rather than any single member is what lets the system stay coherent.

Style Dictionary does this quietly. Radix does it explicitly. Most of the hand-rolled tokens files I'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 and most powerful part of Wittgenstein's later work.

He argues that a genuinely private language is impossible. Not impractical. Incoherent. 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."

Which is why a design system that lives in one designer's head isn't a design system. It's 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 the second person uses the system and says, "I used this wrong — what should I have done?" That sentence is the whole point. It's the public rule, being corrected by another user. Language games require players, plural.

The highest-leverage thing a solo design system owner can do, practically, is get someone else using the system under review. Not to audit the work. To create the conditions for public correction. Without that, you don't have a system. You have your own memory, dressed up.

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." These aren't arguments. They're 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. The craft isn't picking the right answer. The craft is growing the language until the right answer becomes speakable.

Back to the button argument

Which brings us back to the thread that wouldn't end.

The team isn't fighting about naming. They're fighting because different members have seen the component used differently, and each is proposing a possible 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, name follows.

What your system actually is

The uncomfortable payoff from spending this much time with Wittgenstein: language games are what make design systems exist at all.

Not tokens. Not Storybook. Not Figma libraries. Those are artifacts of the language game, not the game itself. What keeps a system coherent across fifty designers is a shared practice of use, publicly correctable, continuously re-stabilized against real decisions.

When the practice breaks, the artifacts stop helping. No naming convention, no linting rule, no governance model saves you. You have to return to the use.

The system you think you're maintaining is downstream of 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.