When someone starts using your software, they need to build an understanding of how it works and how the pieces interact. The UI text you write and the feature names you choose can build or break a mental model.

From a marketing perspective, the importance of the name is clear. You want something catchy, marketable, searchable, memorable, all these things. But most importantly, a feature name must help a user build a mental model of what your feature does.

The mental model helps the user understand why they might use this feature, and what for. One of the riskiest part of shipping something new is adoption. If people don’t know what it does or how it works, they won’t use it. A crucial element to that understanding is what you call the new thing and how you describe it in the product. If I can’t guess based on the name what it does, I might not click on it at all and explore it.

Let’s look at some feature names…

• Google+ vs GoogleDocs. One of these is pretty opaque, and the other is pretty clear. I might think that Google Docs is google FOR docs, but as soon as I click into it, I’ll see what it is and understand that it’s for writing docs. I might never click into Google+ because I have no idea what it is based on the name.
• Dropbox vs Box. There’s a reason both of these companies are named practically the same thing. Because you put things in boxes that you want to share and store. It’s a super evocative mental model, so it gets a bit overused, perhaps.
• Slack vs HipChat. HipChat is a bit more descriptive, but you know automatically that it’s a chat app. Slack turns a verb into a noun, and hopes that you start using it and understand that you slack off while using it… kind of.

It’s harder to come up with examples in software of things that truly failed, because they aren’t very well known. But the example that brought this to life for me is from a card game I learned how to play recently. Red7 uses the concept of a “canvas” and a “palette” to tie the metaphor of color across the game. But combining those concepts with the established mental model that you have in a card game with a discard pile and a hand of cards took quite a bit of work. In reality, the clever metaphor broke down and impeded what could have been quick understanding by burdening an existing card game mental model with a mental model of painting ephemera. It was marketable, but not intuitive because it didn’t help people build a mental model to understand how the game works.

The simplest way to pick a good feature name is to test them out. Do some word association exercises with your team, but also with people that don’t work on your team and don’t even work in software. Diverse teams matter a lot in this exercise. This can help identify names that build mental models, break them, or are irrevocably associated with irrelevant mental models.

Another way to pick good feature names is to rely on scenarios when building features. That way, you’re less likely to conceptualize a feature based on its architecture, or your internal team structures, and more likely to think of it from a problem-solving perspective. If you know exactly what the feature is doing, and for whom, it’s easier to pick a useful name.