Craft clear names for features and labels in your app

Highlight

Apple turns app naming from copywriting guesswork into a verifiable design decision through three criteria, Belongs, Expectations, and Works everywhere, plus a Think-Feel-Do framework that developers can use to review every button, menu, and feature name in their products.

Core Ideas

The cost of failed naming

(00:11) The feeling that you know where to go as soon as you open an app is designed. Naming is one of the easiest design tools to overlook, and one of the most powerful. A bad name can confuse users, create the wrong expectations, and even break trust.

Apple Cash’s balance display is a typical example. The team considered “Spending Power”, which sounds appealing but is not specific enough. Users might wonder whether it is a credit limit or a score. In a financial context, ambiguity is dangerous. When the balance is zero, “Spending Power” also sounds judgmental, directly undermining trust in the financial product.

Another option, “Current Funds”, is accurate, but it sounds as if it came from a spreadsheet. No one says in daily conversation, “Let me check my Current Funds.”

The team ultimately chose “Balance”. It is an industry-standard term, clear, neutral, and self-explanatory. In this context, clarity and trust matter more than brand expression.

The three criteria for naming

(01:18) Apple proposes three evaluation criteria:

Belongs: A name should not only sound like your app, but also work at every layer: what users expect to find there, and how it coexists with everything else you have already named.

Expectations: When users read a name, they are already predicting what they will find. The right name fulfills that expectation, and trust builds from there.

Works everywhere: A name needs to stay effective across languages, markets, and platforms.

These three criteria do not all have to be satisfied equally. You may have extra criteria of your own, such as trademark concerns or industry regulations. The key is knowing which tradeoffs you are making.

Start from the user’s perspective: Think-Feel-Do

(05:25) Developers often name features from the perspective of implementation or functionality. Users do not care about the technology; they care about what it does for them.

Apple recommends a derivation exercise: first define your audience, then ask what users should:

• Think: Does this feature make them think it is simple, useful, or smart?
• Feel: The delight of finding a coffee shop whose name they forgot? The sense of safety from knowing data is encrypted?
• Do: Find this feature, use it, or share a place.

Take Apple Maps’ “Visited Places” feature as an example. After brainstorming, the team grouped ideas into three themes: Ease, meaning easy to find again; Excitement, meaning the surprise of rediscovering favorite places; and Security, meaning privacy and encryption. They ultimately chose “Visited Places”. It is descriptive, naturally fits the Maps interface where “Places” appears throughout, and also carries the privacy expectation that these places belong to you and Apple cannot read them.

Naming strategies with different styles

(09:35) There is not only one correct answer for naming. Apple shows three different naming styles, each serving a different design goal:

Emotion-driven: The Photos app feature “Memories” automatically organizes photos. When users open Photos and find pictures from five years ago, they are not thinking “the algorithm is impressive”; they are looking for a memory. “Memories” creates clarity from an emotional angle rather than an explanatory one.

Description-driven: For Apple Podcasts’ speech enhancement feature, the team rejected “Vocal Isolation”, which describes the implementation, and “Clarify Speech”, which only gets half the idea right. They chose “Enhance Dialogue”. It answers both “enhance what” and “for whom”, and an Apple TV feature already uses the same name, proving that it belongs in the Apple ecosystem.

Constructed compounds: Apple Music’s “AutoMix” is not an existing word, but the combination of Auto and Mix lets users understand it immediately: it automatically handles transitions between songs. The clarity of the coined word comes from its parts, not from the word itself.

Details

A concrete way to evaluate names

(08:35) Apple recommends a simple test: put candidate names into everyday conversation or interface copy.

For example, test “Private Memories”:

• “Hey, check out Private Memories”
• “Just search for Private Memories”

If it does not read or sound natural, you should be suspicious. “Visited Places” feels natural in conversation, which is one of the key reasons it won.

Principles for naming tradeoffs

(04:51) For a gym app’s subscription plans, “Basic Access” and “All Access” are clear and easy to understand. If you change them to “Lightweight” and “Heavyweight”, they become more fun and more on-brand, but they also add learning cost because users need to understand what the two words represent.

There is no absolute right or wrong here. Sometimes you lean toward clarity; sometimes you lean toward brand. The key is to decide which criterion should have priority based on where the feature appears and how important it is.

Naming compounds over time

(14:15) Good names establish patterns. Once you make “Places” clear on one page, every related feature can reuse that root, saving enormous cognitive and translation cost. Every good name makes the next name easier to create.

Key Takeaways

1. Audit every name in your existing app

Open your app and inspect every button, menu item, and settings toggle one by one. Filter each name through Apple’s three criteria: does it belong in this app, does it set the right expectation, and does it still work in other languages?

2. Bring naming review into the Figma design stage

Do not wait until development to handle copy. When designers name buttons in Figma, review the Think-Feel-Do framework with developers. If a designer names a delete button “Let it go”, push back with the Expectations principle: damaged clarity directly causes user confusion.

3. Build a naming blacklist for financial and transaction apps

The Apple Cash example is a warning for every app involving money, points, or limits. Never use judgmental language to describe the value of a user’s assets. “Spending Power” becomes mocking when the balance is zero; “Balance” is the safe choice.

4. Add accessibility labels for coined words and metaphors

When UI names use metaphors or short coined words for brand tone, clarify the real function with accessibilityLabel. Visually it may say “AutoMix”, but VoiceOver should read something like “automatic mixing, seamless song transitions”.

5. Create a cross-team naming glossary

Collect validated good names into a shared team glossary. Apple Maps uses “Places” consistently across the interface. That consistency is not accidental; it is a deliberate design decision. Your team should also have its own “words that belong to this app”.

Related Sessions

• Design principles - Apple’s design principles system, where naming is one part of the user experience
• Brand identity - The relationship between brand identity and naming, and how to trade off brand expression against clarity
• Accessibility Controls - Accessibility design, where naming directly affects the usability of assistive technologies such as VoiceOver
• AppKit modernization - Modernizing macOS apps, where naming is foundational UI modernization work
• SwiftUI - Text and localization practices in SwiftUI, turning good naming into code