Naming and taxonomy

In Lecture 1 we ended on a promise: naming is how you bridge the gap between the interface and the model in a user’s head. This lecture pays that off. On the surface it is the most modest topic in the course, just what do we call things. In practice it is one of the highest-leverage decisions you will make, because a name propagates. It shows up in Figma layer trees, in CSS class names, in token keys, in Slack conversations, in the mental map every new hire builds of your system. A bad name is not a typo you fix later. It is a wrong turn that thousands of downstream decisions inherit.

Alla Kholmatova opens her chapter on naming with an idea borrowed from the educator James Britton: by conferring names on things, we start “bringing them into existence.” For interfaces the consequence is precise.

That last line is the whole lecture in eight words: a “pink” button can only be pink. Name a thing by how it looks and you have welded its appearance to its identity. The day the brand changes, or the day someone needs the same component in a different colour, the name lies. Name it by what it is for and it survives every restyle. That is the first principle: name by purpose, not by appearance.

The Sipgate failure: what presentational names cost

This is not a theoretical worry. Kholmatova documents a real system that learned it the hard way. Sipgate, a German telecommunications company, began by naming their patterns after how they looked, names like “Prominent tile” or “Circle with a dot.” It seemed harmless enough. It was not.

The failure mode is a doom loop. Presentational names are unsearchable: nobody looks for “Circle with a dot” when they need a status indicator. Because they cannot find the existing pattern, people build a new one. Now there are two patterns doing the same job, both badly named, and the library is more fragmented than before, which makes the next person even less likely to find the right thing. Ritterbach’s phrase sticks: it “makes the problem worse and worse over time.” A naming mistake is not static. It compounds.

FutureLearn’s three qualities of a good name

So what works instead? Kholmatova’s own team at FutureLearn ran the experiment. They tried precise, descriptive names like “Progress toggle button” and “Binary radio button,” and they tried playful ones like “Whisperbox.” Then they watched which names the team actually used. Their working definition of a good name came out of that.

Three qualities, each doing real work:

1. Metaphorical. A metaphor from another discipline gives the team an image to hold. FutureLearn’s “Brackets” are named after architectural brackets that support and strengthen a structure; in the interface they support the main content with small chunks of additional information. “Spotlight” is a promotional element that draws attention to one piece of content. Set those against “Progress toggle button” or “Binary radio button,” which create no image at all. As Kholmatova puts it, no one remembered the descriptive names, and “if no one remembers it, there’s a high chance that people will recreate the pattern instead of reusing it.” The same doom loop, headed off by a good metaphor.
2. Has personality. This is the famous one. FutureLearn’s small, secondary buttons are called “Minions.” And, Kholmatova writes, “where there are minions there should also be a boss”: so the large primary call-to-action button is the “Boss.” The class names .minion and .boss even show up in the CSS. Names with personality stick, and they breed families: a discreet promotional module called “Whisperbox” later spawned a louder sibling, “Boombox,” when a team needed something more prominent. A memorable vocabulary that hangs together beats a precise, forgettable one.
3. Communicates purpose. The best names carry their own usage rules. “It’s easy to remember there can be many minions (on a page) but only one boss,” Kholmatova notes. You do not have to write a guideline saying “use only one primary button per view”: the metaphor enforces it. The name does the governing.

Naming as a diagnostic: the red flag

The most useful idea in the chapter is easy to miss. Naming is not just labelling, it is a test. When a name will not come, the problem is usually not the name.

Her example is Eurostar, which introduced a module purely to improve SEO. In the naming workshop the team hit a wall: “It’s an SEO module! It doesn’t have a function. There’s no meaning to its existence!” The struggle was the signal. They eventually settled, with some humour, on “le blurb.” The lesson is not the name. A naming struggle is a symptom, and the disease is unclear or overlapping purpose. When you cannot name it, stop and ask what it is really for, or whether it should exist at all.

Verbs over nouns: view patterns as actions

Kholmatova offers a concrete technique for surfacing purpose: describe the pattern by what it does, not what it is.

A noun freezes a pattern to its current content: “course card” can only ever hold a course. A verb opens it up: “promote” or “encourage people to join” describes an action that could apply to a course, a discussion or an event. FutureLearn followed the action to a name and landed on “Billboard”, a prominent promotional element, precisely because “Billboard” reflects the action (promote something loudly) rather than the content (a course). Start from the verb and the purpose-based name usually falls out on its own.

From evocative names to a strict grammar: Curtis’s taxonomy

Everything so far has been about components, the human-facing modules where memorability and personality matter. There is a second layer where the opposite discipline applies: tokens. A thousand playful, metaphorical token names would be a nightmare. What you want is a rigorous, predictable grammar that a machine and a newcomer can both parse. This is Nathan Curtis’s contribution. In “Naming Tokens in Design Systems” (EightShapes, 2020) he decomposes a token name into ordered levels.

Assembled, these read left-to-right from general to specific: rai-color-action-primary-hover or button-color-background-primary. The governing rule is worth memorising:

Unpack it. Homogeneity within a class: every value in the same category should share one naming shape, so all your colours look alike, all your spacing looks alike, and a reader can predict the next name before seeing it. Heterogeneity between classes: colour names should not look like spacing names, so the level a token belongs to is obvious at a glance. This is the exact inverse of the component advice. Kholmatova wants component names distinctive so they lodge in memory; Curtis wants token names uniform so the whole set is predictable. Both are right, because they are solving different problems for different audiences.

Atlassian’s doctrine: the semantic layer is the only public API

Curtis gives us the grammar. Atlassian’s design system gives us the discipline about which names a consumer is even allowed to touch. Their rule is uncompromising: semantic tokens are the only public API. Raw, primitive tokens (the palette, the raw scale) exist, but they are private. Product engineers reach only for intent-named tokens like color.text.danger or color.background.selected, never red-500. The primitive can change underneath and every semantic consumer updates for free, since they never depended on the raw value in the first place.

That doctrine comes with a blunt rule:

Atlassian also treats names as a governed resource with a formal lifecycle, not a wiki someone edits on a whim. Every token moves through three states:

The lifecycle exists because a name is a promise. Renaming or deleting a token silently breaks every product that consumed it. The active / deprecated / deleted ladder lets the system evolve without betraying its consumers: nothing vanishes without first being flagged and given a successor. That is what treating naming as engineering rather than labelling looks like.

Where brand belongs in a multi-brand name

This course serves four brands from one system, so one naming decision matters more here than anywhere: where does the brand go in the name? The wrong answer is to bake it into the semantic name, rai-button-primary versus acme-button-primary. Do that and every consumer’s code turns brand-specific, and you have four systems pretending to be one.

The right answer follows directly from Curtis’s taxonomy: brand is a mode (or a namespace), never part of the semantic name. The semantic name stays identical across every brand, color.action.primary, and the brand mode resolves it to a different value. RAI mode gives it the RAI blue; another brand’s mode gives it that brand’s colour. The consumer writes one name and never knows which brand is active. This is the functional / perceptual seam from Lecture 1, now in the naming layer: the functional, purpose-based name is shared and stable, and the perceptual, brand-specific value lives in the mode. Keep the semantic names brand-neutral and the mode does all the brand work. We build this for real in Lecture 4.

The panel: three authorities, three naming disciplines

These sources do not contradict each other; they govern different layers, and the skill is knowing which discipline applies where.

Kholmatova governs components. There, names should be evocative: metaphorical, personality-bearing, purpose-communicating, distinctive enough to lodge in a team’s memory so the pattern gets reused instead of rebuilt. “Minion,” “Boss,” “Billboard,” “Brackets.” Distinctiveness is the goal.

Curtis governs tokens, where names should be the opposite: a strict, ordered grammar, homogeneous within a class and heterogeneous between classes, predictable rather than memorable. You should be able to guess the next token name without looking. Uniformity is the goal.

Atlassian governs the contract. Only semantic names are public; primitives are private; you pick a token by meaning, never by matching colour; and every name lives on a formal active / deprecated / deleted lifecycle so evolution never silently breaks a consumer. Stability is the goal.

Put together, the division is clean: be a poet when you name components, be a grammarian when you name tokens, and be an engineer about the contract that binds them. Most systems fail by applying one discipline everywhere: playful token names that no machine can predict, or rigid component names that no human remembers.

Further reading

• Nathan Curtis: “Naming Tokens in Design Systems”
• Atlassian: design tokens overview
• IBM Carbon: colour token names