Craft clear names for features and labels in your app
Learn a practical UX writing framework for naming app features, settings, labels, and plans so they feel clear, trustworthy, and on-brand.
TL;DR
- Use three naming criteria as a guide: the name should belong in your app, set accurate expectations, and work across languages, markets, platforms, and contexts.
- Prioritize the criteria based on context: financial labels should favor neutral clarity, while some product areas can support more branded or evocative names if users still understand them.
- Generate names by starting with the audience and asking what people should think, feel, and do when they encounter the feature.
- Evaluate candidate names in real interface and conversation contexts; good names build a consistent language for your app over time.
Naming is part of the user experience
Feature names, menu items, settings labels, tab labels, and product names all shape how people understand and navigate an app. A name can make a path feel obvious, reduce friction, and build trust; a poor name can make a feature feel confusing, judgmental, or out of place.
The session frames naming as a design decision on the same level as layout, interaction, and visual style. Names are not just descriptors; they establish the language of an app and influence how future features should be named.
Three criteria for better names
Use three criteria to evaluate a name: whether it belongs, whether it sets the right expectation, and whether it works everywhere. These criteria are guides, not rigid rules; teams may also need to account for trademarks, regulations, localization, or industry-specific constraints.
- Belongs: the name fits the app's tone, domain, surrounding terminology, and the user's mental model.
- Sets expectations: the name accurately previews what people will find or what will happen, which supports clarity and trust.
- Works everywhere: the name holds up across languages, markets, platforms, surfaces, and contexts where the app appears.
- Trade-offs are allowed: some contexts require maximum clarity, while others can support stronger brand expression if comprehension is preserved.
Use obvious language when trust matters
The Apple Cash example shows why neutral, concrete terminology is often best in high-trust contexts. A balance label needs to tell people how much money they have available, without adding ambiguity or emotional judgment.
Names like "Spending Power" can sound compelling but may imply a credit limit, score, or personal judgment. "Current Funds" is descriptive but unnatural in everyday speech. "Balance" works because it is familiar, neutral, industry-standard, and immediately understood.
- For financial, health, safety, or other trust-sensitive areas, prioritize clarity and neutrality over cleverness.
- Use a natural-language gut check: if people would not say the term out loud, it may not belong in the product.
- The most obvious word can be the strongest choice when it already matches user expectations.
Generate names from the audience outward
Instead of naming a feature only by its function, implementation, or technology, start with the people using it and the value they need from it. The session recommends a simple exercise: identify the audience, then ask what they should think, feel, and do when they encounter the feature.
The Apple Maps "Visited Places" example demonstrates the process. A feature that remembers places someone has been should feel easy, exciting, and secure. Candidate names can then be grouped by themes and tested against the naming criteria.
- Write many ideas first; do not filter too early.
- Group repeated ideas into themes such as ease, excitement, privacy, security, or usefulness.
- Discard candidates that do not fit the app, feel vague, create the wrong tone, or may not translate well.
- Place candidate names into realistic UI strings or spoken sentences, such as "Search for ..." or "Check out ...", to see whether they read and sound natural.
Different naming styles can all be clear
Clarity does not require every name to be plain or literal. The right style depends on the feature, context, audience, and the app's existing language.
Examples from Apple apps show several valid approaches: "Enhance Dialogue" is descriptive and action-oriented, "Memories" is emotional and user-centered, and "AutoMix" is an invented but understandable branded term whose parts explain its behavior.
- Use verbs when a feature is an action people control, such as turning on a playback enhancement.
- Avoid overly technical terms when they describe the implementation more than the user benefit.
- Evocative names can work when they match what people are trying to recover, feel, or accomplish.
- Invented names can work when their components are immediately understandable and the feature behavior confirms the promise.
Evaluate names in context
A name does not need to satisfy every criterion equally, but it should be evaluated intentionally. The surrounding UI, the sensitivity of the feature, the app's tone, localization needs, and consistency with existing terminology all affect which criteria matter most.
Good names become reusable patterns. Over time, consistent naming choices create the vocabulary of an app, making later naming decisions easier and helping people feel at home in the product.
- Ask whether the name fits the app and neighboring labels.
- Ask whether people will correctly predict what happens before they tap or choose it.
- Ask whether the name remains understandable across surfaces, platforms, languages, and markets.
- Test names in real UI locations, menus, settings, onboarding copy, and spoken references.
Resources
Related Sessions
Design no-code games with Reality Composer Pro 3
Use Reality Composer Pro 3 ScriptGraph to prototype RealityKit games with visual nodes, physics, custom events, reusable subgraphs, and SwiftUI attachments.
Design intuitive search experiences
Design search that matches navigation, scope, and platform conventions, from ergonomic iOS placement to suggestions, filters, tokens, and empty states.