Naming things in design systems–and why it’s the worst

The exercise of naming can easily descend into a mindfuck death spiral. I often joke that every design system conversation devolves into a naming argument. As the years go by, it feels less and less like a joke. I vacillate between naming being performative navel-gazing and the most important part of the job. Given I consider it so critical half the time, I thought I’d write about it.

I hold extreme opinions on naming because I think there are really effective and equally ineffective ways to do it. The effective ways seem important. The ineffective ways seem like navel-gazing.

Fun is only fun for the people having fun

Gestalt’s color palette is probably my biggest regret. I consider it a great case study in clever, creative, fun, and horrible naming. I distinctly remember the meeting where everyone acknowledged how much we fucked up. You could literally hear pain in the engineer’s voice when they asked, “So I need to type Matchacado every time I want to color something green?” “Why not just call it green?”, was the next question. Which, to be fair, was a damned good question.

Fun names aren’t as fun as the namers think they are. Don’t get me wrong, it’s fun as hell to come up with clever new words. Even when there’s a perfectly functional existing word available. Pharmaceutical ads may well be the zenith of make-shit-up naming. Where we once had “General Steel”, in today’s marketing-driven mindset we’d have “Ferraxa”. These names are creative (I guess?), but I don’t think creativity is a good thing when it comes to naming. At least not in design systems.

Anyone reading this who’s worked with me is rolling their eyes now. I’ve been public enemy number one for creating stupid names purely for the sake of juvenile humor. Guilty as charged. My case nonetheless stands.

Clear or flexible (you choose)

A name should clearly and concisely describe its subject. Dishwasher may be the best name ever invented. “What’s a dishwasher do?”, is not a question people ask. A name has succeeded if it’s self-descriptive.

Concise and clear naming is all fine and dandy to say, but much harder in the realm of systems. Specifically in the realm of design tokens. Tokens are design systems’ magnum opus in masochism. Design tokens defy clarity because they are abstract by design. Tokens shift based on context. Things like color schemes and density settings mean that what was once dark is now light. What once was big is now less big. We can’t just call a thing what it is, because it isn’t always the same thing.

How do you name a thing that changes? Abstraction. Terms like light/dark are replaced with negative/positive. Which is fine, but it chips away at clarity. People innately get “dark” faster than “positive”. Abstraction gives us flexibility at the cost of clarity.

To make things harder, a lot of things in design systems are relative. Think size/color ramps. Sure, we could just name each size its actual value, but what happens when that value has to change? Now that name makes no sense whatsoever. Going back to our friend abstraction, we’ve historically named ramps in relative terms (e.g., small, medium, large or light, medium, dark). This also sucks. Because what happens when you need to add a value between small and medium? You get the infamous smedium. Too many sizes and you get a bunch of Xs in names (e.g., xx-small, xxx-small, xxxx-small). No one will convince me those are good names.

So, to combat this, we’ve typically used numeric stops for ramps (e.g., size-100, size-200 and red-100, red-200). More abstraction. This fixes the issue of needing to shunt a size/color in the ramp (size-150/red-150) but it’s even more abstracted. Meaning it’s even less clear. Someone tell me what size-100 is. It’s nothing. In a way, that’s the point.

In real life, I can call a chair a “chair” and know that it will always be a chair. In the world of design systems, a chair could become a sofa, or a table, or a Volkswagen. I know we haven’t cracked design tokens because they continue to make no goddamned sense. Due in large part to obtuse naming conventions.

Rules of thumb for naming components

I don’t see a world where token naming doesn’t devolve into said mindfuck death spiral. At least not in the near future. But that doesn’t need to be the case for other areas of a system. Luckily, many other areas of systems can be much simpler. And it’s important to lean into that simplicity.

I think it’s important to have one name–and only one–for a thing. This seems obvious. But different platforms have different names for the same thing. What would be considered a list on Web has been called a table on iOS. There’s a million of these discrepancies once you get in the weeds. As difficult as it may be, I maintain the opinion that a design system needs to settle on one name.

Once that name is settled, the focus should be short, simple and clear. As few simple words as possible that clearly describe the thing. Mind you, this is deceptively hard. Maybe even deceptively impossible. But a few smart decisions during the naming phase can at least reduce pain down the road. For example, is, “Loading Spinner” a good name? What if it’s redesigned to no longer spin? What about, “Loading Indicator”? Well, “indicator” is a pretty big word for a pretty small meaning. Maybe, “Loading Sign”? What about just, “Loading”? Too vague?

Side note, I don’t think I’ll ever understand why “Floating Action Button” isn’t called “Floating Button”. Aren’t all buttons, action buttons? Floating Action Button, in particular, sticks in my craw. This overly complicated name led it to become FAB. It committed the ultimate sin of becoming an acronym. A name has failed once it’s become an acronym. I could go on and on about the blight of acronyms, but that’s for another day. I’d argue that naming simplicity is critical solely to avoid being acronymed.

Lastly, names should have decent separation between each other. The more components differ in form/function, the more their names should differ. For instance, “Tag” and “Tab” are pretty damned different components, but the sound really similar. That alone can cause confusion. It doesn’t help when the “G” and “B” keys are so close together. One fat-finger typo and now there are tags where there were supposed to be tabs.

Think before you name

I could go on and on about naming in design systems. Suffice to say, it’s important (as much as I can think otherwise). Design systems are many things. Their role as a language may be its most critical. The nomenclature used in a system is what creates common understanding or general confusion. It can bring people together or keep them siloed.

For as critical as naming is, it’s not always treated that way. Many teams don’t have people with the background, expertise or even general interest to deftly handle taxonomy. Think twice before you name that component Floating Upsell Card. You may end up regretting it.