为 App 中的功能和标签构思一目了然的名称

一句话判断

这场 Session 最值得关注的一件事是，Apple 终于把“起名字”从文案玄学变成了可量化的工程标准，明确告诉你为什么 Apple Cash 叫 “Balance”（余额）而不叫 “Spending Power”（消费能力）。

这场 Session 讲了什么

以前开发者给功能起名字，习惯从底层技术实现出发，搞出 “Vocal isolation”（人声隔离）这种让普通用户一头雾水的极客词汇。现在 Apple 给出了三个硬性评估指标：Belongs（契合 App 调性）、Expectations（建立正确预期）、Works everywhere（跨语言跨平台普适），并配套了 Think-Feel-Do（思考-感受-行动）推导框架。

这对负责产品定义的 PM、UX 设计师，以及最终要把这些名字塞进 String Catalog（字符串目录）和处理多语言适配的 iOS 开发者影响最大。别再让设计师在 Figma 里拍脑袋定名字，开发在代码里硬编码英文字符串了，这套方法论要求命名在写第一行代码前就必须经过严谨的逻辑推导。

值得深挖的点

技术视角的自嗨 vs 用户视角的预期管理 (Expectations)

Apple Podcasts 团队在给“降低背景噪音、突出人声”的功能命名时，放弃了 “Vocal isolation”（技术实现）和 “Clarify Speech”（只说对了一半），最终选择了 “Enhance Dialogue”（增强对话）。这个选择背后的 trade-off 非常经典：开发者总想炫耀自己用了什么牛逼的算法，但用户只关心“这玩意儿能给我带来什么结果”。

“Enhance Dialogue” 好就好在它把主体交给了用户（对话），而不是机器（隔离）。在金融类 App 中这个原则更致命。Apple Cash 放弃了听起来很酷的 “Spending Power”，因为当用户余额为零时，这个词听起来像是一种嘲讽和评判，直接破坏了金融产品的信任感。老老实实叫 “Balance” 才是正解。明确性永远优先于品牌抖机灵。

“普适性 (Works everywhere)” 在工程落地时的灾难与解法

设计师在英文语境下造出一个绝妙的词，比如 Apple Music 的 “AutoMix”（自动混音），到了多语言本地化（Localization）和无障碍（Accessibility）阶段往往会直接崩盘。“AutoMix” 在英语里是 Auto 和 Mix 的拼凑，用户能秒懂，但直译成其他语言可能就是一堆乱码。

作为 iOS 开发者，我们不能只把 UI 上的字翻译了就完事。对于这种为了品牌调性而创造的“合成词”或“隐喻词”，必须在代码层面通过 Accessibility Label（无障碍标签）来兜底预期。视觉上看是 “AutoMix”，但 VoiceOver 读出来的必须是“自动混音，无缝过渡歌曲”，用代码把设计师省略的解释补回来。

代码片段

作为 iOS 开发者，如何把这些 UX Writing 原则落地到 SwiftUI 代码里。

1. 用 String Catalog 管理“普适性”命名

场景：千万不要在代码里硬编码设计师给的英文原名，使用 String Catalog (.xcstrings) 让本地化团队能根据 “Works everywhere” 原则调整各语言的具体表述。

import SwiftUI

struct MusicPlayerView: View {
    // 开启自动混音的状态
    @State private var isAutoMixEnabled = false

    var body: some View {
        Toggle(isOn: $isAutoMixEnabled) {
            // 使用 LocalizedStringKey，自动关联 .xcstrings 文件
            // 视觉文案保持简短，本地化团队可以在 xcstrings 中处理语境
            Text("AutoMix")
        }
        // 为这个造词补充详细的上下文，帮助翻译人员理解
        .help("Automatically crossfade between songs for seamless playback.") 
    }
}

坑：如果在 Text("AutoMix") 里直接写死字符串，Xcode 的 String Catalog 虽然能提取它，但翻译人员看不到上下文，极容易把 “Mix” 翻译成“混合”而不是“混音”。

2. 为“隐喻命名”补充无障碍预期 (Accessibility)

场景：当 UI 上的名字为了“契合 (Belongs)”而采用了隐喻或简短造词时，必须通过 accessibilityLabel 把“预期 (Expectations)”给视障用户讲清楚。

import SwiftUI

struct PodcastPlayerControls: View {
    @State private var isDialogueEnhanced = false

    var body: some View {
        Button {
            isDialogueEnhanced.toggle()
        } label: {
            // 视觉上只显示一个图标和极简的标签
            Label("Enhance", systemImage: "waveform.badge.mic")
        }
        // 坑：别把 accessibilityLabel 写得和视觉文案一模一样
        // 必须解释这个功能到底会“做”什么，建立正确的预期
        .accessibilityLabel("增强对话")
        .accessibilityHint("降低背景噪音，让人声更清晰")
        .accessibilityValue(isDialogueEnhanced ? "已开启" : "已关闭")
    }
}

坑：很多开发者把 accessibilityLabel 写成 “Enhance Dialogue button”，这是废话。VoiceOver 已经知道它是 button 了，标签应该只描述功能和预期结果。

最佳实践

已有项目的迁移策略：全局搜索你的 .xcstrings 或 Localizable.strings，干掉那些带有浓厚技术视角的命名。把 “Fetch Data”（拉取数据）改成 “Refresh”（刷新），把 “Sync State”（同步状态）改成 “Up to date”（已是最新）。
新项目的采用建议：在 Figma 设计阶段就拉着开发一起过一遍 Think-Feel-Do 框架。如果设计师给某个按钮起名叫 “Let it go” 来代替 “Delete”，直接用 Apple 的 Expectations 原则怼回去，明确性受损会直接导致客诉。
实战中容易踩的坑：不要为了追求三个标准（Belongs, Expectations, Works everywhere）全占而陷入死胡同。Apple 明确说了，不需要每个名字都完美打勾。像 “AutoMix” 牺牲了一点跨语言的直白性，换取了极强的品牌调性，这是合理的 trade-off，关键是你得知道自己在牺牲什么。

还有什么值得关注

Apple Maps 的推导过程：给“去过的地方”命名时，团队排除了 “Private Memories”，因为 “Memories” 在 Apple 生态里已经被 Photos（照片）App 强占，跨 App 的命名冲突会破坏用户的预期。
金融 App 避坑指南：Apple Cash 案例是给所有做交易、积分、额度类 App 的警钟，永远不要用带有主观评判色彩的词（如 Spending Power）来描述用户的资产数值。
命名是复利：好的名字会建立模式（Pattern），你在这一个页面把 “Places” 用明白了，后续所有相关功能直接复用这个词根，能省下巨大的认知和翻译成本。