The perils of naming

Or, how to name features that people will remember

Question: what’s this object called? ↴

From my investigations it turns out that this really familiar object has no name.

If you follow the pattern of the people I asked, at this point you might be sure that you know its name, and feeling like it’s on the tip of your tongue… You might even have got as far as “Party…”, but finding a solid ending will escape you.

You might suggest:

• Party Tooter
• Party Blower
• Party Horn
• Party Favor
• Party Noisemaker
• Party Raspberry
• Carnival Blower
• Party Kazoo
• or just the jaunty: ‘Tooter’.

But even if you find a name, you’ll be left with nagging doubt.

Ok, yes, but why does this matter?

Imagine you have to ask someone else to buy one. Ask a friend to nip out and grab a Party Raspberry, and they’ll either look at you funny or give you a decorated fruit.

Without a name, you can’t just ask. First you must go through a long description or an expressive mime to describe how and where you use it (defining physical description and context). All this pain to describe a common object.

Now think about doing that for something like a new feature in a piece of software which nobody has used before.

If we name a new feature, we need the name to be distinctive, consistent, and understandable.

Distinctive — don’t recycle names

The more distinctive a name, the less it relies on context to prop it up.

If I mention texting or uploading, you know exactly what I mean regardless of our context. If I mention a streaming feature, you’ll most likely think of video or music — unless we’re standing in a garden center.

If you use an already common term for something new and different, the meaning of the name is diluted and it takes more effort to understand it in any particular context.

If you get a note to “buy chips” are you buying:

• poker chips
• wood chips
• hot chips
• snacky chips
• or some other form of chip?

The more context description you need to provide, the higher the mental effort needed to understand what you are talking about. This gets even more complex if the term is used in similar contexts to mean something different. We hit this in Bitbucket pipelines, when we discovered that the cache feature from one of the other major players in our product space is very different from ours. This means we have to put extra effort into making this difference clear, and it still causes support cases and customer pain. 😢

If, after you’ve explained the name, you need to explain the new feature, your audience has already been taxed and will find it harder.

Consistent — don’t use lots of terms for one thing

To strongly define a name, you need to use it precisely; all your conversations should use the same term for it.

Don’t have some developers talking about Party Raspberries, and the product managers talking about Party Horns. The initial design sketches shouldn’t have different terms on different screens. Your documentation should use the same term whenever it refers to it. The name might have to change during development if the feature changes, or if you discover some other issue with it (“It means WHAT in Spanish!?! 😱”), but make sure that if you do change it, you change it before it launches (do that research!), and use it consistently.

Consistency should be the default, right? To show how easy it is for differences to slip in, here’s a real world example:

Bitbucket Cloud was adding a version of the Branching Model feature, popular in Bitbucket Server. This feature is made of many parts, so we started creating the feature: “prefixes for branches,” the minimum viable product (MVP).

When we discussed this new feature, people used terms like Branching model, Branch model, Branch prefixes, and Branching prefix. In our early designs some screens talked about Branching model, but the “what’s new” highlights mentioned Branch prefix. We didn’t even notice this discrepancy when we were talking with each other. All of the terms had some variation of the word “branch” in them, and we had the strong mutual context of “a feature we are developing.” As you read this they might all sound similar enough to be fine.

The problem occurs once this feature is released into the wild, as it no longer lives in such a well defined context. During a first user experience, would Branching model be obviously the same thing as Branch prefix, but not the same as Branches, Branch workflow, Branch permissions, and Branch filters? If you needed to search for help with this feature, what words would you use to get information on this (but not another) branch feature? Google can forgive a lot but there’s only so much it can do.

To reinforce this, in my “Party Tooter” research, one person thought we could definitively find the correct name by finding out when and where these devices were invented. They confidently opened their laptop, and then froze: what to google to find the birthplace of this item? That is, without biasing the results with a bad word choice. They closed their laptop again, defeated.

Understandable — make it easy for people

To be understandable, the name needs to visually and linguistically make sense.

A feature suite with things named list1, list2, and list3 is never going to catch on.

Don’t try and be clever with the naming, either. An inspirational but unclear name may seem like a good idea at the time, but falls flat if people are not really sure what it means. “Dream, plan, & go” might sound like a lovely heading for a website menu, but if someone is visiting your site to book a flight, they’ll find what they need more easily if it’s labelled with the more straightforward: “Flights” or “Book a flight.”

Also, if you use a diverse spelling for a common word, be prepared to live in the Google search graveyard.

It can be tempting to come up with a different name for a feature compared to all your competitors, but it will be much more memorable if it connects well with mental models people already have.

To find your feature name:

• Do any major players have a similar feature, what do they call it?
• What terms are people asking you to develop a feature, using?
• What search terms are people using?
• Maybe just ask them! Conduct some user interviews, and you’ll find out a bunch.

Finally, disregard technical accuracy. Especially in the field of tech. Wait, what?

I’m not saying that technical accuracy has no place, it’s very important. However, when technical accuracy gets in the way of understanding, throw it away. Use the “wrong term” if it’s the one that everybody uses. This is a painful lesson to learn, especially for writers, where meaning is so precise and precious. One word can make a huge difference.

A striking example of the fault of clinging to a technically correct term is that one person’s refusal to change a menu item from the legal term: single family housing to the more commonly used: condominium, is cited as a key reason that Denmark’s entire Electronic Land Registry failed.

I’m wrestling with this one myself. Early indications are suggesting that in the Bitbucket Pipelines docs we should standardize on the term “your build” rather than “your pipeline’’ to describe a specific time when the pipelines software kicked in and acted on some code. The action taken might not be actually building anything, maybe it’s deploying the code somewhere, or testing something that’s already built, but even so, some people still call that process a “build,” even if technically inaccurate. Similar to how people might say they Googled something, even if they used another search tool.

Before going through and changing all the references immediately, we’re going to conduct some research on how understandable/confusing the terms are, after all, it may be even more confusing to now change the term after we’ve been using it for a while!

Does it need a name?

After all this, sometimes something doesn’t need a name. Does having a name actually add anything (i.e. are people going to need to refer to it by name or search for it?)? Will putting a title on it just bulk out the user experience for no benefit? “Let’s call this the ‘enter text’ feature, and put a big label saying ENTER TEXT at the top!” 😓

If it does need a name, but choosing one is proving difficult, this may be a clue that the benefit of the feature isn’t that clear in the team’s mind or that it’s trying to do too much in one feature. If so, time to research further and make sure you have the problem statement clear. And remember that your name doesn’t have to express everything about the feature.

Summary

It can be tempting to just get straight into the design and coding of your exciting new thing, and describe it with a term that makes sense to you, and publish with that same name. If you do you may be setting yourself, and your users, up for pain and confusion.

Remember to keep the name Distinctive, Consistent, and Understandable; and you’ll be in a better position. Then, research your proposed term early, even if it’s quick and dirty. Check some translations, ask some people unrelated to the product what they’d expect from that name, google it and see what comes back. It’s better to find out as soon as possible that the name needs to change, than three years into the product!

Did you enjoy this post? Want more of the same? Consider following Designing Atlassian.