译 | 发布版本通知优化的几个建议

2017-03-22 11:13:00

译者前言：手机中app更新时，我有时会看下更新说明（也就是发布版本通知优化）
看了本文之后，想不到小小的更新说明竟然有这么大的学问，也正如作者文末所说，这就是优秀和卓越之间的差距。

写版本发布通知一直以来都存在争议。有些公司不喜欢撰写版本发布通知（有着它们自己的理由），而有些公司则十分重视这个，全身心投入撰写，争取[做到引人入胜](https://slackhq.com/a-little-thing-about-release-notes-997d2e06842d# .jfjmjhl0u)。

使用一些简单的结构和格式技巧，你可以显著提升外观、可读性以及使用纯文本字符编辑发布版本通知的经验。

本文将介绍一些关键要点，并且给出了「一篇完美的版本发布通知」，可直接滑到文末进行查看。

最佳范例

总结先行，然后再详细阐述

你最好的朋友......TL;DR（too long; didn’t read 太长了，不会去看）

以防用户没有时间阅读，因此建议总结先行。然后再阐述更新的细节。

1Password & Medium过去都曾用过这个说明

记住主要版本

在一个主要版本更新之后需要快速迭代一个修复版吗？请记住一定要在下方补充主要更新版本的发布通知，提醒用户产品所做过的重大改进。

Trello & Evernote

让用户方便联系你

需要有一个恒定的签名部分，强调问题的反馈渠道，可以避免一些负面评论。

简明扼要，「我们十分重视您的反馈，请联系xxxx@email.com」,这是用户体验中非常关键的一部分，用户越容易向你沟通反馈越好。

The Guardian & Onefootball

基本格式

项目符号

· 拆成短句，用户想看到的是总结性的话语，而不是长篇大论
· 如果有疑问的话，每个要点用一行说明，并使用 ‘•’开始
· 可以使用一些创造性的项目符号。ESPN 使用的就是[+]
· 有些甚至会做一些额外的事情，比如说二级项目符号—
· 创意是一种乐趣，然而，不要仅仅为了噱头而去喧哗取众。如果你曾经使用了这样的项目符号，请保持一致性，在后续的发布版本通知中也请保持。ESPN在这方面做的很好，项目符号上每次发布都保持一致性。

项目符号有助于将长段文本分成短句— IMDb & ESPN

标题

你需要给你的每一小段内容配上合适的标题。用大写字母来做标题是最好的，也可以使用 — * = ~ # + … 来突出你的标题。请保持你所完成工作的一致性，标题都使用同一种风格。

Two Dots & Trello

章节

新功能 :sparkles: ~vs~ 改进 :injured: ~vs~ BUG 修复:ant:

让你的标题更进一步。发布版本分解成以下两个部分：想要大力宣传的新功能和已修复改进的功能。

不言而喻，想要大力宣传的新功能自然会率先出现。

MindNode & 1Password

间隔

多留点空白，让用户能够轻松的看清楚你的主要观点而不是一整页的文字。

并不是针对Slack. 你们这伙人可以写出灿烂的发布版本通知… 如果在‘new’ 和‘fixed’多增加1行的间距会更佳惊艳 — Outlook & Slack

撰写风格&内容创意

不要害怕提到Bug:ant: …:bug::bee::beetle::spider:

修复了一个影响过很多用户的Bug？告诉他们！这正是他们一直在等待的更新。当小错误修复的时候可以使用这个策略，不需要删除它。

Clear Score 发布bug修复通知

将你的bug提升到一个整体级别

（我不知道这样做有多大价值，尤其是对除了公司以外的人而言，但是......）

在主要的修复或版本发布中，会给Bug编号。就这点而言，其实做不做都无所谓，但总要的是，你一旦开始做，后面最好保持连续性。

1Password 疯狂而又详细的努力— 票ID :anguished:

即将到来的更新...

当一个重大更新的版本即将发布的时候，你可以告诉用户这个版本正在快速赶来的路上！

即将到来...但不是现在 — IFTTT

人格化

和你的用户聊天，人格化的开头或结尾让气氛更佳融洽。

Onefootball & Photobox 写作风格里加入了一些个人性格

:snow_capped_mountain: 遇到的挑战及解决办法

给一个大的跨国公司工作，在发布版本通知时会遇到一些挑战。下面是我们遇到的一些共性问题及解决办法。

:snow_capped_mountain:许多更新都是非常细小的，甚至只是一些底层或者像素级的调整...

不要撰写独立的发布版本通知。做一个协同文档，让设计师和开发人员一起参加。无论用户认为是多么微不足道的更新，每一个人都是非常努力的工作。如果你认真对待这个文档，团队的同事肯定会想要写上几句。这样你就可以轻松的收集大家的总结。

:snow_capped_mountain:有时候，我们需要经常更新去修复Bug...

没有关系，超级小或者无聊的Bug修复可以称为「小错误」，但是如果出现了如下图所示的模板化的段落，你需要把它组合起来，避免重复。

如我之前所提到的，现在是添加一些人格化语言或反馈邮件地址的好时机。

:snow_capped_mountain:没有人去阅读App Store的更新提示

随着iOS和Android平台提供了自动更新的功能，这也难怪越来越少的人会去阅读App Store的更新提示。

不过如果你听取了我之前的建议，你应该已经对你的发布版本通知做出了一些努力。如果你想要主动和用户互动，不要等到用户自己来App Store中查看。

相反的，告诉他们，一些新功能已经就绪。SofaScores 在这方面做的很好，使用一个小红点 :red_circle:来告诉用户，引导去存放功能更新的页面，查看新功能介绍。

SofaScores 用一种非强制性的方式引导用户

你为规范化发布版本通知的努力都不应该被浪费。同样可以用到的地方是：内部的电子邮件、应用程序中的新功能更新。Withings 在App Store和应用程序内部使用的都是同一个版本的发布通知。

一篇完美的版本发布通知:lower_left_fountain_pen::heart_eyes:

终于等到你最期待的这个部分了。关于你如果把它们拼接在一起，没有什么比纯文本更好了。

这是介绍。简短的段落。可以适当人格化。e.g.“圣诞节快乐！你的提问，我都听到了。- 这一次的更新就是为你的圣诞节准备的”
TL; DR
· 所有笔记的简短摘要
新功能
· 你可以在这里写更新的一些功能
· 解释这些功能在app中的哪些地方
· 用户如何找到它们
· 哪些用户会从更新中得到好处又或是此次更新对用户的好处
· e.g. “[谁得到好处？] Apple watch 的用户会很高兴看到此次更新 [为什么？] 此次更新可以支持和Mac的自动传输功能 [在哪里？/怎么用？] 不要忘记把蓝牙打开，你可以做到的！”
改进
· 如果改进了一个已经存在的功能，而不是一个新功能，请使用改进标题，而不是新功能标题
· 如果你是根据用户反馈做的改进，可以考虑用这样的句子：我们根据你的建议...这是一种让你的用户觉得被尊重认可的好办法
修复
· 列出主要的bug及可能受到影响的用户
· 如果你只是进行了一些小错误或不重要的修复，可以参照如下写法：
· e.g. 小错误的修复
· 如果你还在使用其他标题的话，请保持使用修复标题
签名，和开头的介绍类似，你可以适当人格化。在通知中，你可以存在好几个这样的变化。
最后是反馈，添加反馈邮箱，欢迎用户的任何想法。e.g. 如果在使用中遇到任何问题，请发送邮件至xxx@email.com，我们会认真回复每一个反馈。