Feature Names Matter

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…

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.