WWDC Quick Look 💓 By SwiftGGTeam
中文 EN 日本語
Make a big impact with small writing changes

Make a big impact with small writing changes

Design
观看原视频

Highlight

Apple UX Writer Liv 和 Jennifer 给出四个文案优化动作：删废话、去重复、好处前置、建词汇表。

核心内容

我在国外租车出差，把车停进一个需要 app 付费的车库。打开 app，看到一句”Simply enter your license plate number to quickly pay for parking”。问题是租来的车，我不知道车牌号，要走回车里看一眼，再走回出口找信号才能下载 app。这句文案里的 “simply” 和 “quickly” 不仅没帮上忙，反而让产品显得不诚实。

Liv Huntley 和 Jennifer Bush 是 Apple 的两位 UX Writer。她们在这个 session 里讲了一个朴素的观点：app 没有最低字数要求，写得越少越好。Apple 推出新的设计系统正在跨平台铺开，是重审 app 内文案的时机（00:20）。她们给出四个具体改动：删废话（fillers）、去重复（repetition）、好处前置（lead with the why）、建词汇表（word list）。每一个都不需要重构架构，花一两个小时就能完成一轮 pass。

详细内容

删废话（01:15）。Liv 列了四类常见废话：副词（easily、quickly）、形容词（fast、simple）、感叹词（uh oh、oops、hooray）、客套话（sorry、please、thank you）。判断方法是：删掉这个词，意思有没有损失。停车 app 的例子去掉 simply 和 quickly 后变成 “Enter your license plate number to pay for parking.”，信息量不变（02:48）。

  • 关键点：不要把描述性形容词当默认装饰。
  • 关键点：例外是当形容词承载关键功能信息——宠物喂食器 app 的 “Feed your pets automatically when you’re away” 中 automatically 说明了「按计划自动喂食」这个核心特性，不能删（03:14）。
  • 关键点：错误消息里的 “uh oh”、“oops”、“oh no” 让产品显得对问题不认真；推送里的 “We’re sorry”、“10 short minutes!” 把致歉和感叹号当填空，反而稀释了主信息（04:35）。

去重复（06:11）。重复不只是同一句话说两遍，还包括用三种说法表达同一件事。送货迟到的通知原文：标题 “We’re running late”、正文 “Your delivery driver won’t make it on time”、后面还有 “in 10 minutes”——三处都在表达「迟到了」。Liv 把它合并成 “Delivery delayed 10 minutes.”，一句话同时说清「延迟」和「多久」（06:43）。

  • 关键点：UX writing 的本质是 economy of language（语言经济），空白不需要被填满。
  • 关键点：合并的判断标准是信息量。新句子和旧句子信息量等同，就保留新句子。

好处前置（07:13）。Jennifer 给的公式是 “To [获得好处], do [做某事]“。Apple News+ Puzzles 的通知 “Keep your streak going by solving today’s crossword” 之所以有效，是因为 why（保持连胜）放在了开头（07:38）。餐厅 app 的例子更直接：原文 “Enter your phone number to get reservation updates” 改成 “To get reservation updates, enter your phone number.”，字数不变，但读者第一眼看到的是好处（08:57）。

  • 关键点：适用场景是错误提示、推送通知、操作引导这类需要用户行动的文案。
  • 关键点：用户看到通知第一反应是「跟我有什么关系」，把答案前置。

建词汇表（09:23）。这是唯一一个发生在 app 之外的动作。Jennifer 推荐的格式是三列表格：用的词 / 不用的词 / 定义。游戏里的玩家昵称统一叫 alias，不叫 handle、user name、title；玩家生命值统一叫 health，不叫 lives、hearts、energy、stamina（10:45）。词汇表的好处是任何参与 app 开发的人都能查询，文案在设置、搜索、通知里都保持一致。

  • 关键点：不要试图一次写完整词汇表，遇到一个加一个。
  • 关键点：参考起点是 Apple Style Guide。

最后 Liv 给出最实用的一个建议：写完读出声。读出声能听到那些「写的时候没问题但听起来很冗余」的词。

核心启发

  • 做什么：在下一轮 release 前预留 1-2 小时专做文案 pass。

    • 为什么值得做：文案优化几乎没有技术成本，但用户感知非常直接。一个动作能同时改善可用性、品牌感、错误处理体验。
    • 怎么开始：列出 app 里所有 user-facing 文本（按钮、空状态、错误提示、推送），逐条用四个原则过一遍。

  • 做什么：把所有错误消息里的 “oops”、“uh oh”、“sorry” 全部删掉。

    • 为什么值得做：这些词让产品在出错时显得敷衍。直接说发生了什么、用户该怎么做，反而更显尊重。
    • 怎么开始：在代码库里 grep “oops” / “Sorry” / “uh oh”，挨个改写。

  • 做什么：所有推送通知改成「好处前置」。

    • 为什么值得做：推送是用户最浅注意力的场景，前 5 个字决定是否打开。
    • 怎么开始：找一句现有的 “Do X to get Y” 通知，改成 “To get Y, do X” 的结构，做一轮 A/B 看打开率。

  • 做什么：建立产品词汇表，从最常用的 5 个术语开始。

    • 为什么值得做：词汇不一致会让用户怀疑产品是不是同一个团队做的。一致性是廉价的信任。
    • 怎么开始：开一个共享文档，三列「用 / 不用 / 定义」。第一批先写 alias / username / 头像 / 账户 / 订阅 这种最容易混用的词。

关联 Session

评论

GitHub Issues · utterances