Highlight
Apple 用三个标准（Belongs、Expectations、Works everywhere）和一套 Think-Feel-Do 推导框架，把 App 命名从文案玄学变成了可验证的设计决策，开发者可以直接用来审视自己产品中的每一个按钮、菜单和功能名称。
核心内容
命名失败的代价
（00:11）打开一个 App 就能知道该去哪，这种感觉是被设计出来的。而命名是最容易被忽视、却最强大的设计工具之一。一个糟糕的名字会让用户困惑、产生错误预期，甚至破坏信任。
Apple Cash 的余额显示是一个典型案例。团队考虑过 “Spending Power”（消费能力），这个词听起来有吸引力，但不够具体。用户会困惑：这是信用额度？还是一个评分？在金融场景里，模糊是最危险的东西。而且当余额为零时，“Spending Power” 听起来像一种评判，直接破坏金融产品的信任感。
另一个选项 “Current Funds”（当前资金）虽然描述准确，但像是从电子表格里搬出来的词。没人会在日常对话中说 “让我查一下我的 Current Funds”。
最终团队选择了 “Balance”（余额）。这是行业标准术语，清晰、中性、无需解释。在这个场景里，明确性和信任优先于品牌表达。
命名的三个标准
（01:18）Apple 提出了三个评估标准：
Belongs（契合）：名字不仅要听起来像你的 App，还要在每一层都工作——用户期望在那里找到什么，它和你已经命名的其他东西如何共存。
Expectations（预期）：用户读到名字时，已经在预测他们会找到什么。正确的名字兑现这个预期，信任由此建立。
Works everywhere（普适）：名字要能跨语言、跨市场、跨平台保持有效。
这三个标准不是必须全部满足。你可以有自己的额外标准，比如商标考量或行业法规。关键是知道自己在做取舍。
从用户视角出发：Think-Feel-Do 框架
（05:25）开发者习惯从技术实现或功能角度命名。但用户不关心技术，他们关心”这对我有什么用”。
Apple 推荐了一个推导练习：先明确你的受众是谁，然后问自己——当用户遇到这个功能时，他们应该：
- Think（想什么）：这个功能让他们觉得简单、有用、还是聪明？
- Feel（感受什么）：找到一家记不清名字的咖啡馆时的惊喜？知道数据被加密的安全感？
- Do（做什么）：找到这个功能、使用它、分享地点。
以 Apple Maps 的”记录去过的地方”功能为例。团队 brainstorm 后归纳出三个主题：Ease（轻松找到）、Excitement（重新发现喜爱之地的惊喜）、Security（隐私加密）。最终选择了 “Visited Places”（去过的地方）——描述清晰，和 Maps 界面中大量使用的 “Places” 一词自然融合，也传递了”这些地方属于你、Apple 无法读取”的隐私预期。
不同风格的命名策略
（09:35）命名不只有一种正确答案。Apple 展示了三种不同风格的命名，各自满足不同的设计目标：
情感驱动：Photos App 的 “Memories”（回忆）功能自动整理照片。用户打开 Photos 发现五年前的照片时，不会想”算法好厉害”，而是在寻找一段回忆。“Memories” 从情感角度建立清晰，而非解释。
描述驱动：Apple Podcasts 的语音增强功能，团队排除了 “Vocal Isolation”（技术实现）和 “Clarify Speech”（只说对一半），最终选择 “Enhance Dialogue”（增强对话）。它回答了”增强什么、为谁增强”两个问题，而且 Apple TV 上已有同名功能，证明它属于 Apple 生态。
组合造词：Apple Music 的 “AutoMix” 是一个原本不存在的词，但 Auto（自动）+ Mix（混音）的组合让用户能立刻理解——自动处理歌曲间的过渡。造词的清晰度来自组成部分，而非词本身。
详细内容
命名的具体评估方法
（08:35）Apple 推荐了一个简单的测试：把候选名字放进日常对话或界面文案中。
比如测试 “Private Memories”：
- “Hey, check out Private Memories”
- “Just search for Private Memories”
如果读起来、听起来不自然，就值得怀疑。“Visited Places” 在对话中自然流畅，这是它胜出的关键原因之一。
命名的取舍原则
（04:51）健身房 App 的订阅方案，“Basic Access” 和 “All Access” 清晰易懂。如果改成 “Lightweight” 和 “Heavyweight”，虽然有趣且符合品牌，但增加了学习成本——用户需要额外理解这两个词代表什么。
这里没有绝对的对错。有时候你偏向清晰，有时候你偏向品牌。关键是根据功能所在的位置和重要性，决定优先满足哪个标准。
命名是复利
（14:15）好的名字会建立模式。你在一个页面把 “Places” 用明白了，后续所有相关功能直接复用这个词根，能省下巨大的认知和翻译成本。每一个好名字都让下一个名字更容易取。
核心启发
1. 审计现有 App 中的所有命名
打开你的 App，逐个检查每个按钮、菜单项、设置开关的名称。用 Apple 的三个标准过滤：它属于这个 App 吗？它建立了正确的预期吗？它在其他语言里还成立吗？
2. 在 Figma 设计阶段引入命名评审
不要等到开发阶段才处理文案。设计师在 Figma 里给按钮起名时，拉着开发一起过 Think-Feel-Do 框架。如果设计师给删除按钮起名叫 “Let it go”，用 Expectations 原则反驳——明确性受损会直接导致用户困惑。
3. 为金融/交易类 App 建立命名黑名单
Apple Cash 的案例给所有涉及金额、积分、额度的 App 敲了警钟。永远不要用带有主观评判色彩的词描述用户的资产数值。“Spending Power” 在余额为零时变成嘲讽，“Balance” 才是安全的选择。
4. 为造词和隐喻补充无障碍标签
当 UI 上的名字为了品牌调性采用了隐喻或简短造词时，必须通过 accessibilityLabel 把真实功能讲清楚。视觉上看是 “AutoMix”，但 VoiceOver 读出来的应该是”自动混音，无缝过渡歌曲”。
5. 建立跨团队的命名词汇表
把经过验证的好名字整理成团队共享的词汇表。Apple Maps 用 “Places” 贯穿整个界面，这种一致性不是偶然，是有意识的设计决策。你的团队也应该有自己的”属于这个 App 的词”。
关联 Session
- Design principles — Apple 的设计原则体系，命名是其中用户体验的一环
- Brand identity — 品牌识别与命名的关系，如何在品牌表达和清晰性之间取舍
- Accessibility Controls — 无障碍设计，命名直接影响 VoiceOver 等辅助技术的可用性
- AppKit modernization — macOS App 现代化，命名是 UI 现代化的基础工作
- SwiftUI — SwiftUI 中的文本和本地化实践，把好的命名落地到代码
评论
GitHub Issues · utterances