Writing for interfaces

Highlight

Apple 的 UX Writer 团队分享了他们写界面文案时的思考框架。文案不只是填充文字——它是产品体验的核心部分。去掉文案的 App 就像一个没有路标的城市。

---

核心内容

很多 App 的文案是在界面快做完时才补上去的。按钮需要一个标签，弹窗需要一句说明，空状态需要一段提示。这样写出来的文字，常常只能解释已经定型的界面，不能参与设计。

这场 session 的观点很直接：界面文案也是设计的一部分。Apple 的 UX Writer 把这件事称为 through the lens of language（通过语言做设计）。他们给出一个写作框架：Purpose、Anticipation、Context、Empathy，合起来是 PACE。

这不是 API session，没有官方代码片段。下面用可执行的文案检查清单来代替代码。它的作用和代码一样：把抽象原则变成每个界面都能逐项验证的规则。

Interface copy review
- Purpose: 这个屏幕最重要的一件事是什么？标题和主按钮是否先说清楚？
- Anticipation: 用户读到这里时，下一步最可能想知道什么？
- Context: 用户是在什么场景里看到这段文字？是否被打断、是否赶时间？
- Empathy: 这段文字能否被不同语言、能力和背景的用户理解？

关键点：

• Purpose 要求先定义屏幕目的，再决定保留哪些文字。
• Anticipation 把 App 的文案看成一段对话，提前回答用户的下一步问题。
• Context 要求文案跟出现时机、设备状态和用户注意力匹配。
• Empathy 要求文案照顾本地化、无障碍和包容性表达。

详细内容

Purpose：每个屏幕只承担一个主要任务

（03:12）Purpose 是屏幕存在的原因。Apple 用 Messages 的姓名和头像分享引导页做例子：标题直接说 “Share Your Name and Photo with Friends”，按钮写 “Choose Name and Photo”。用户即使只扫标题和按钮，也能知道这个屏幕要做什么。

这带来一个实际写法：先写标题和主按钮，再写正文。因为用户不一定按顺序读完整个屏幕。标题和按钮承担信息层级里最重的部分。

Purpose checklist
1. 写出这个屏幕的一句话目的。
2. 检查标题是否表达这个目的。
3. 检查主按钮是否表达下一步动作。
4. 删除、移动或推迟与当前目的无关的说明。

关键点：

• 第 1 行把设计问题收束到一个目标，避免一个屏幕同时解释太多事。
• 第 2 行检查用户第一眼看到的信息是否有用。
• 第 3 行检查按钮是否能独立表达动作。
• 第 4 行处理冗余信息，Apple 在 iPhone 温度警告示例里就删掉了过多原因说明。

（04:13）温度警告的反例写了太多内容：可能在阳光下、可能用了太多 App、还能打紧急电话。最终版本只保留标题 “Temperature”、一句 “iPhone needs to cool down before you can use it” 和 “Emergency” 按钮。图片已经传达高温，文字不用重复。

（05:59）多步骤流程也要这样处理。Apple Cash 家庭共享设置里，每一步都有不同目的：先说明谁能使用 Apple Cash，再说明需要验证身份，再说明激活可能需要几分钟并会发送通知。每个屏幕只回答当前步骤的问题。

Anticipation：把界面文案当成对话

（07:40）Anticipation 是预判用户此刻会问什么。Clock App 的闹钟示例里，用户周末临时改闹钟时，最关心的是“只改明天，还是改整个周末计划”。操作表直接问 “Would you like to apply this change to all weekends in this schedule?”，第一个选项是 “Change Next Alarm Only”。

这个例子说明，文案不只是说明按钮功能。它要预判用户最常见的意图，把默认路径说清楚。

Anticipation checklist
1. 用户刚刚做了什么？
2. 用户现在最可能担心什么？
3. 用户下一步可以做哪几个动作？
4. 最常见动作是否最容易理解？

关键点：

• 第 1 行记录触发文案的上一步动作。
• 第 2 行把文案从系统视角转到用户视角。
• 第 3 行确认界面给出了可选动作。
• 第 4 行检查默认选项是否符合用户此刻的真实意图。

（09:06）Apple 还区分 voice（声音）和 tone（语气）。一个 App 应该有稳定的声音，但语气可以随场景变化。Apple Watch 检测到摔倒时，用 “It looks like you’ve taken a hard fall” 和 “I’m okay” 保持冷静；Activity 记录 Move streak 时，语气可以庆祝，所以用了感叹号。

（10:31）写作时要不断问 “What comes next?”。Breathe App 先说 “Be still, and bring your attention to your breath”，接着给出 “Now inhale…” 和 “And exhale”。文案、视觉和触感一起回答“我该怎么开始”。

Context：同一句话要放回使用场景判断

（11:47）Context 要求先想 App 外面的环境。用户是在安静的家里，还是在机场？是在走路、开车、做饭，还是能全神贯注看屏幕？

Apple Watch 的运动提醒例子很典型。设备检测到用户正在户外步行但没有记录 workout。此时用户正在运动，不适合读长文案，所以界面只给一个大按钮：“Record Outdoor Walk”。运动结束后，用户的注意力变多，界面就可以展示距离、配速和活跃卡路里。

Context checklist
1. 文案出现时，用户是否正在做别的事？
2. 这是提醒、确认、错误，还是空状态？
3. 如果只读按钮，用户能否知道结果？
4. 如果这是错误，文案是否给出修复入口？

关键点：

• 第 1 行决定文案长短和信息密度。
• 第 2 行区分不同界面类型，alert、错误和空状态不能用同一种语气。
• 第 3 行来自订阅取消示例：按钮不能只写 Yes 和 No。
• 第 4 行来自 billing problem 示例：错误提示要给出下一步。

（12:56）Alert 是一种打断。Weather App 请求位置权限时，弹窗在打开 App 时出现，并说明位置会用于本地天气和相关通知，因此它是有上下文的。

（13:44）破坏性操作需要更具体。删除设备的 alert 标题是 “Remove iPhone?”，按钮是 “Remove” 和 “Cancel”。取消订阅的反例只写 “Confirm Cancellation”“Cancel”“Confirm”，用户很难判断哪个按钮会真的结束订阅。改成 “Cancel Platinum Subscription?”、“Cancel Subscription” 和 “Keep Subscription” 后，只看按钮也能做决定。

（15:29）错误提示也一样。反例 “Oops! you can’t do that” 加错误码和 “Please try again” 没有告诉用户发生了什么。更好的版本标题说有 billing problem，正文说明要添加新付款方式，主按钮直接是 “Add Payment Method”。

（16:38）空状态可以教育用户。餐厅 App 的 “Nothing strike your fancy?” 语气俏皮，但习语可能难翻译，也没有说明内容怎么出现。Apple Podcasts 的 “No Saved Episodes” 和 “Save episodes you want to listen to later, and they’ll show up here” 更清楚。

Empathy：为不同语言、能力和背景写作

（18:02）Empathy 是为所有人写。Apple 建议使用简单、平实的语言，谨慎使用习语和幽默，因为它们可能无法翻译，也可能排除一部分用户。

本地化是这里的核心问题。英文变成泰语、荷兰语或希伯来语后，长度、垂直空间和阅读方向都会变化。日历里的星期缩写也不是所有语言都有单字母版本：Catalan 用两个字母，Arabic 不缩写。

Empathy checklist
1. 这句话是否依赖习语、俚语或内部术语？
2. 文案变长后，布局是否还能容纳？
3. 从右到左语言下，界面顺序是否仍然清楚？
4. VoiceOver 读出这段内容时，用户是否得到足够信息？
5. 是否有不必要的性别、身份或文化假设？

关键点：

• 第 1 行降低翻译和理解成本。
• 第 2 行提醒设计要允许文字变长或换行。
• 第 3 行覆盖希伯来语、阿拉伯语等从右到左语言场景。
• 第 4 行把无障碍标签当成完整体验来写。
• 第 5 行避免用不必要的身份假设排除用户。

（20:10）无障碍文案也要有设计。使用 VoiceOver 的用户可能完全依赖元素标签理解 App。Apple 以 Memoji Stickers 为例：描述不只写身体动作，还写意图和场景，比如 “as if sharing a secret”、meditating、nervous person biting fingernails。同时使用 “person”，避免不必要地指定性别。

最后一步：读出来

（22:47）如果找不到合适的词，Apple 给的最后建议是读出声。读出来可以检查文案是否像日常对话，也能发现重复、语法错误和错别字。

这条建议很实用。界面文案通常很短，短句里的问题不容易在设计稿里暴露。读出声后，别扭、过长、像系统日志的句子会更明显。

---

核心启发

• 做什么：给每个 onboarding 页面写一行 Purpose。 为什么值得做：session 反复强调每个屏幕都要有明确目的，标题和按钮要先传达这个目的。 怎么开始：在设计稿旁边加一列 “screen purpose”，先写目的，再写标题、正文和按钮。

• 做什么：重写 App 里的 destructive alert。 为什么值得做：取消订阅示例说明，含糊的 “Cancel”“Confirm”“Yes”“No” 会让用户无法判断后果。 怎么开始：把标题改成具体对象和动作，把按钮改成 “Delete File”“Keep File” 这类能独立表达结果的文字。

• 做什么：为错误提示增加修复动作。 为什么值得做：billing problem 示例把错误说明和 “Add Payment Method” 入口放在一起，用户不需要猜下一步。 怎么开始：列出高频错误，把 “出了什么问题”“为什么影响用户”“下一步按钮” 写成固定检查项。

• 做什么：建立本地化压力测试文案集。 为什么值得做：session 展示了荷兰语变长、泰语需要更多垂直空间、希伯来语从右到左等差异。 怎么开始：用长字符串、双行按钮、RTL 预览和 Dynamic Type 检查关键流程。

• 做什么：审查 VoiceOver 标签里的描述语言。 为什么值得做：Apple 的 Memoji 示例把动作、意图和场景都写进描述，并避免不必要的性别假设。 怎么开始：逐个检查图标、图片、图表和自定义按钮的 accessibility label，确认它们能独立说明含义。

---

关联 Session

• Explore navigation design for iOS — 讲解如何用熟悉的导航结构帮助用户理解 App 信息架构。
• Design for Arabic — 从阿拉伯语场景切入，补充本地化、阅读方向和文化适配细节。
• Design an effective chart — 关注图表信息如何用清晰、可访问的方式表达。
• Meet the expanded San Francisco font family — 从字体家族、字宽和语言扩展角度补充界面文字的视觉表达。