原文标题：As a Designer I want better Release Notes ——Simple visual design, applied to plain text release notes
作者：Rob Gill，UX Manager @PerformGroup.
翻译：王很远
原文地址
写版本更新说明是个有争议的话题。有些公司选择简单处理（通常有一个「好」理由[1] ），有些公司则煞费苦心[2]。
通过应用简单的文本结构和基本版式，在只使用纯文本的前提下，也可以大大提升你的版本说明的视觉效果和阅读体验。本文涵盖几个关键领域，最后提供「完美的版本说明模版」。
最佳实践
1.先总结再详述
大家都很忙的，先从总结开始，再说明更新细节。
TL；DR.（太长不看）——1Password 和 Medium 都使用过这种先总结再说明细节的方法
2.重新提醒重大更新
如果在发布一个大版本之后紧急修复了重大 Bug ，确保在新版本的说明中再次提醒上个版本的重大更新。有助于未及时更新的用户了解你更新的新功能。
在大版本后修复 Bug？别忘了你那些幸苦的工作
3.让用户轻松联系到你
一个统一的外部反馈渠道可以有效避免负面评价。确保这里的文案简洁到位。「我们很重视您的反馈意见，您可以通过这些渠道联系我们：Email、QQ 群、微信 etc.」如何让用户的反馈渠道更简单方便，是专业用户体验设计的关键。
The Guardian & Onefootball
基本版式
1.项目符号
- 拆分说明，不要使用大段文本，请精炼总结
- 每个功能点单独占一行，行首建议使用圆点「•」
- 可以使你的项目符号富有创造性以获取额外效果。例如 ESPN 使用「+」
- 甚至可以在一个项目下使用子项目
- 保持创造性是很有意思的事，但是别哗众取宠。一旦你确立了一种写作风格，一定要自始而终保持统一。ESPN 一直都保持他们独特的风格符号
使用项目符号分割能使一坨文本快速提升可读性--IMDB & ESPN
2.小标题
你可能还需要使用小标题来区分更新的功能点。考虑使用一些符号譬如「-、#、+、*」来表示小标题。不管如何你还是要确保写作风格保持统一。
标题 —— Two Dots &Trello
3.区分内容
新特性 vs 改善 vs BUG FIXES
使你的标题更简洁精炼。把你的版本更新说明分解为你需要用户知道的新特性，还有已修复的问题。新特性／功能应该写在前面。
Mindnode & 1Password
4.空间
你的段落应该留有呼吸空间。使你的用户更容易阅读每个更新点而不是丢给用户一大坨文本。
没有对比就没有伤害 ——Outlook & Slack
写作风格和内容观点
1.不要担心把 Bug 说出来
修复了一个影响大量用户的 Bug？快告诉他们吧！这对他们来说是一个很好的改进。小修小补则可略过。
Clear Score 宣布解决了一个大问题
2.把你的 Bug Fixes 提升到另一个高度
（我不知道这样做有没有卵用，尤其是对外部人员来说。但是谁知道呢……[3]）
考虑把错误代码写进你的版本说明。我想说的是，这一步做不做都关系不大。但是别忘记，写作风格统一是关键。
1Passeword 丧心病狂地把错误编号也写上
3.即将更新
有些功能研发过程很曲直，但是你知道这些大招就要完成研发。快告诉用户一切都在计划之中，新功能就要憋出来啦！
就快憋出来了，再等等…… —— IFTTT
4.个性化
热情地和你的受众人群打招呼别害羞。
Onefootball & Photobox 使用了讨巧的写作风格
如何克服挑战
在一个多语言的大公司工作，对于版本说明我们面临许多挑战。以下是我们解决常见问题的一些方法。
1.许多细微的更新，比如底层和小像素调整：
不要独立写版本说明。如果你付出了努力，你的团队肯定有话要说，无论用户认为改动多么小。每个人都为这个版本付出了努力，使用协作文档让每个人都参与进来，最后总结输出。
2.有些时候，我们需要快速发布版本以修复 Bugs：
超级小或者无聊的 Bugs Fixed 可以成为写成「Bugs fixes（修复小错误）」。但是准备一段贴心的反馈路径或个性化应用说明可以避免这种重复。
3.没人阅读应用商店的更新说明怎么办
随着 iOS 和 Android 推出自动更新功能以来，毫无疑问在应用商店阅读更新说明的人越来越少。
如果你采取了以上的建议，你肯定会认真对待你的版本说明。如果你想要与用户产生互动，千万不要等着用户去应用商店阅读你的版本说明。
在告诉用户新特性（功能）的引导上，SofaScores 做了很好的示范。通过醒目的小红点，引导用户去到有详细说明更新内容的「What's New」页面。
SofaScores 在应用内完成引导
另外，你用心排版编写版本说明不应该浪费。相同的文案和版式可以在宣发邮件或 App 内部的 What's New 页面重复使用。不管在 App 内部或 App Store Withings 的文案都保持一致。
Withings 内部和 App Store 上的文案一致
理想的版本说明
以下是一份理想版本说明模板
开头写一段简短的个性化介绍。比如说「Hi，老铁！春天到了，这个版本>我们也更新了许多生气勃勃的功能和提升了整体性能哦！」
TL；DR（Too long；Didn't read 的简写：太长不看）
- 这里写上这个版本说明的总结
~ 新功能 ~
- 这里写上新功能是什么
- 解释这些功能在你 App 中的位置
- 用户如何找到这些新功能- 哪些用户会受益，或者这对他们有什么好处
- 举个栗子：（谁会受益？）Apple Watch 用户会对最新版本特别满意。（为什么？）我们现在支持与您的 Mac 自动切换。（在哪里／如何？）不要忘记打开你的蓝牙，你是最棒的！
~ 改进~
- 如果改进现有功能（而不是全新功能），请使用「改进」标题而不是「新功能」
- 如果你根据用户的反馈改进了某些内容，试着使用这样的句子，例如「你说，我们听」。让用户感受到他们是受重视的。
~ 修复 ~
- 列出影响大量用户的 Bugs- 如果只是修复了小问题，请使用这样的句式「修复了一些小错误」
- 如果你使用了分标题编写说明的话，请保留「修复」这个小标题
这里是底部签名。类似于介绍，尽可能个性化一点。你要知道，有这样一个介绍段落也是极好的。
最后是反馈渠道，可以是 Email 地址、QQ 群号、微信号等。确保用户可以方便的联系到你。例如：
您可以通过以下方法联系我们，告诉我们您的宝贵意见：
QQ 群：XXXXXX
Email 地址
微信号
从「好」到「优秀」
我前老板的一段话影响了我很长一段时间。
从「平庸」到「好」的差距很大，人们需要努力工作才能达到「好」。但是，从「好」到「优秀」只有极短的 2 毫米的距离，他们从来不知道他们离实现「优秀」是多么接近。
——Danyl Bosomworth（基于 Tony Robbins 的 2 mm 规则）
编写优雅的版本说明，是 2 毫米差异一个很好的例子。一个小区别，对于推动你的 App 从「好」到「优秀」有着极大的帮助。
如果你是设计师，找到你的发布经理或项目经理。用你的专业知识，帮助他们达成这额外的 2 毫米。
-
Facebook 员工解释 Facebook Release Note 简单的原因
https://www.reddit.com/r/iphone/comments/2jcy4r/facebook_replies_to_outrage_over_lack_of_changelog/ ↩ -
Slack 员工 Anna Pickard 对编写 Release Note 的建议
https://slackhq.com/a-little-thing-about-release-notes-997d2e06842d ↩ -
确实没什么卵用 ↩
网友评论