较长文本
编写多行/分步说明、页面或功能的叙述性介绍/导向指南。
这显然会根据上下文有很大差异，但这里有一些通用提示：
一：缩写是你的朋友！
它们更具对话感，是让文本听起来更友好、不那么正式的简单方法。（而且它们还能节省一点空间：双赢。）
二：删减那些只会增加字数却没有实际意义的短语。
这种情况在两个特定实例中经常发生。首先，当使用被动语态写作时：
此区块可用于显示单张图片。
每当你看到像“can be”（可以被）或“is used”（被用于）这样的短语时：停下来。你正在使用被动语态。尝试改为主动语态，以获得更简洁（且更短）的句子：
此区块显示单张图片。
其次，当我们犹豫不决而不是做出陈述性声明时，也会发生这种情况：
画廊区块可以帮助你以优雅的布局显示多张图片。
它到底能不能？我们正在开发这款软件：我们可以对其是什么以及做什么进行明确的陈述：
画廊区块以优雅的布局显示多张图片。
我们也经常在“allows you to”（允许你做……）这个短语上犯同样的错误。
预格式化文本允许你保留制表符和换行符。
功能不会“允许”任何人做任何事；它们只是实现最终目标的具体工具。直接说出它们做了什么即可：
预格式化文本保留你的制表符和换行符。
句子越直接通常就越清晰。扫描你的文案，查找“can”（能）、“be”（是/被）、“might”（可能）、“allows you to”（允许你）和“helps”（帮助）这些词——它们是最常见的罪魁祸首，专门寻找这些词是你精简措辞的一种方法。
三：警惕“simple”（简单）、“easy”（容易）和“just”（仅仅/只需）。
决定什么是简单的不是我们，而是用户。如果我们说某件事很容易，而用户的体验并不轻松，这会破坏他们对我们以及我们所构建产品的信任。“just”也是如此——我们中的许多人都知道要避免使用“simple”，但仍然一直在用“just”。“Just click here.”（只需点击这里。）“Just enter your username.”（只需输入用户名。）这是一回事：它暗示某件事没什么大不了的，但我们无法知道用户会觉得什么是大不了的。
具体化也更安全、更有帮助。“Easy”和“simple”是我们尚未写出的解释的简写形式；每当看到它们时，花一分钟思考一下它们代表的是什么。也许“It’s easy to add a block by hitting ‘enter’”（按‘回车键’添加区块很容易）实际上意味着“You can add more content to the page without taking your hands off the keyboard.”（你可以无需将手从键盘移开就能向页面添加更多内容）。太棒了！与其依赖“easy”，不如说出具体内容。
这并不是说你应该把这些词从词汇表中驱逐出去。你可能想写一个工具提示，描述封面图片区块现在需要更少的配置，或者写一封电子邮件，说明我们正在构建一个快速创建自定义区块的工具，在这种情况下，你可以合法地说封面图片区块已被简化（simplified），或者我们正在努力使自定义区块创建更容易（easier）——在那里，这些术语是描述性和相对性的。但要留意你可能如何使用（或过度使用）它们来做出绝对的声明，即某件事是容易或简单的，并利用这些机会变得更加具体和清晰。
四：小心使用“we”（我们）。
每当文本或指令大量使用“we”时，这意味着文本的重点在于软件背后的人，而不是使用软件的人。有时这正是你想要的——但通常不是。重点通常应该放在用户身上，关注他们的需求以及如何受益，而不是“我们做了什么”或“我们想要什么”。
只有我们在乎我们做了什么或想要什么；用户只想要能正常工作的软件。如果你看到很多“we”，请考虑是否应该重构你所写的内容，使其聚焦于用户的利益和成功。
项目符号列表
关于（废话）编写项目符号列表的指南。
一：在所有要点之间保持句子结构平行。
平行结构使列表更容易快速阅读——其可预测性减轻了读者的认知负荷。
良好示例：
你能用这个区块做什么？很多事情！
- 添加引用。
- 高亮链接。
- 显示多张图片。
- 创建项目符号列表。
每个要点都是一个完整的句子，并以句号结尾。（如果你的列表是一堆一两个词的条目，它们通常可以合并成一个普通的句子——更易读，也节省空间。）每一行都以动词开头，告诉用户该区块能做什么。句子的主语始终是用户。
用户可以快速吸收这个列表，因为一旦读完第一项，他们就明白如何阅读其余部分，并知道他们会找到什么信息。
较差示例：
你能用这个区块做什么？很多事情！
- 你可以添加引用。
- 高亮你喜欢的链接。
- 它显示多张图片。适合画廊！
- 项目符号列表
在这里，每一行的措辞都不同（有些以动词开头，有些以名词开头），并且句子的主语发生了变化（有时是你，有时是该区块）。有些行增加了描述，有些没有。有一个不完整的句子，标点也不一致。
阅读这个列表需要做更多工作，因为读者必须重新解析每个要点。他们不能假设每个要点都会包含类似的信息。
注意：这并不意味着每个要点都必须非常短并以动作动词开头！“可预测”不一定意味着“简单”。这只是意味着每个要点应具有相同的句子结构。下面这个列表也是可以的：
你能用这个区块做什么？很多事情！
- 尝试添加引用。有时候别人说得最好！
- 用它来高亮你喜欢的链接——分享链接是互联网的货币。
- 创建一个显示多张图片的画廊，展示你最棒的照片。
在这里，每个要点都以更面向用户的动词开头，并包含一些补充信息以增加趣味性。标点略有变化，这使得各行不会感觉过于公式化，但由于每个要点的基本结构相同，它们仍然易于阅读。
二：如有疑问，以动词开头。（但不要总是同一个动词。）
你必须以动词开头吗？不。但如果你不知所措，使用动词通常不会出错（尤其是因为项目符号列表通常描述的是一系列动作或可能的动作）。
在一个旨在纯粹作为指导的简单列表中（例如，在UI文案中，你只需要用户做出决定），让每个要点都以相同的动词开头可能是可以的：
要继续，请选择一项操作：
- 添加一个简单的文本区块。
- 添加一个拉引号区块。
- 添加一个图片区块。
如果你的列表更具说服力（例如，通过列出优点来说服某人使用某个功能）或包含分步说明，你会希望变换动词以保持读者的参与度，并使用更有趣的语言，如上面的例子所示：
你能用这个区块做什么？很多事情！
- 尝试添加引用。有时候别人说得最好！
- 用它来高亮你喜欢的链接——分享链接是互联网的货币。
- 创建一个显示多张图片的画廊，展示你最棒的照片。
这些并不是硬性规定——例如，你可能会选择在具有说服力的列表中使用相同的动词，以更专注和有力。但它们是为扎实的列表提供良好的起点。
三：当某事物明显是一个列表时，不必告诉我们它是一个列表。
良好示例：
你能用这个区块做什么？很多事情！
- 添加引用。
- 高亮你喜欢的链接。
- 显示多张图片。
较差示例：
你能用这个区块做什么？很多事情！以下是你可以使用它的一些方式示例。
- 你可以添加引用。
- 高亮你喜欢的链接。
- 它显示多张图片。适合画廊！
在尽可能清晰和信任用户之间找到平衡。一方面，我们知道人们并不总是阅读说明；另一方面，冗余会让用户觉得我们认为他们很愚蠢。
四：加粗有时是你的朋友。
使用它将读者的注意力集中在项目符号列表中的关键信息上。当你的要点包含一些次要的补充信息时，这尤其有用。
“关键信息”至关重要：加粗会吸引眼球，因此坚持给定要点中最 vital（至关重要的）的那部分信息：
你能用这个区块做什么？很多事情！
- 尝试添加引用。有时候别人说得最好！
- 用它来高亮你喜欢的链接——分享链接是互联网的货币。
- 创建一个画廊以显示多张图片，展示你最棒的照片。
反过来，加粗太多东西会造成视觉混乱：
你能用这个区块做什么？ 很多事情！
- 尝试添加引用。有时候别人说得最好！
- 用它来突出你喜欢的链接——分享链接是互联网的通用货币。
- 创建一个显示多张图片的画廊，展示你最棒的照片。
当列表简短且基础时，不必费心——加粗只会增加杂乱感。
这个区块能做什么？很多事情！
- 添加一段引用。
- 高亮一个链接。
- 显示多张图片。
文字的缺失本身就创造了焦点；你无需再添加更多修饰。
UI 描述
撰写单行功能描述或用于澄清选项的简短描述的指南。
一：清晰至上！
如果用户不理解使用某个特定选项会产生什么结果，那么你的双关语有多巧妙都无关紧要。文字游戏和习语往往含义不清，容易被误解。如果你确实要使用它们，只能作为补充信息——绝不能用来解释主要观点——而且应该是你相当确信能被广泛人群理解的内容。
二：回顾第一部分，并警惕那些冗长的短语。
主动语态通常是更好的选择，而在空间有限且需要人们做出决策并采取行动时，删减冗长措辞尤为重要。通常你可以缩短 UI 指令短语，使其既更短又更清晰：
当你点击 X 时，Y 会发生。
对比
点击 X 以执行 Y。
虽然感觉上添加额外的词汇有助于引导用户了解产品，但这些多余的词实际上只是掩盖了所要传达的重点：
当你点击“设置”按钮时，弹窗将显示可用的高级设置。
对比
点击“设置”以访问高级设置。
类似的短语还有“一旦你做了 X……”或“如果你想做 X……”。有时在存在基于用户目标的不同路径的决策点上，“如果你想做 X……”是完全合适的。但是，我们常常用它来表达“这是你可以做的一件事”，这可以更简单地表达为：“要做 X……”
三：具体明确。
当一个操作依赖于用户完成某些前置操作时，要明确指出需要什么以及接下来会发生什么。我们常默认使用“当你准备好时”。
准备做什么？要对任何先决条件保持具体。
“当你准备好时”可能意味着：
- 当你想添加另一个区块时”
- 当你对帖子满意时”
- 在你校对完帖子后”
- 当你想添加特色图片时”
- 在你配置完所有设置后”
而当某件事意味着一切时，它实际上什么都没说。指令越具体，就越有用，遵循这些指令的人对产品的信任度也越高。
四：这仍然是写作。它应该具有个性和趣味。
是的，清晰至上，而且这里空间通常受限——但 UI 文本仍然可以读起来有趣。
单行的描述仍然可以是完整的句子。
列表。编号或项目符号。
对比
添加列表，可选编号或项目符号。
你仍然可以使用缩写。
添加列表。我们将提供格式化选项。
对比
添加项目符号列表——我们会给你一些格式化选项。
你仍然可以使用标点符号——破折号、冒号、分号——来控制词语的节奏，连接想法，并制造停顿。
列表。编号或项目符号。
对比
添加列表——编号或项目符号。由你决定！
你仍然可以尝试避免术语，转而使用通俗语言。
添加无序或有序列表。
对比
添加列表，可选编号或项目符号。
（并且值得重复的是：请不要玩文字游戏！“个性”可以——并且在 UI 指令中应当——是微妙的。我们要说的是听起来像人说的话，而不是强行卖弄俏皮。）
五：注意大小写。
关于标题和小标题，有两种大写方式：
在标题式大小写（Title Case）中，几乎每个单词的首字母都大写
在句首字母大写（sentence case）中，仅该行第一个字母大写
功能名称和仪表盘部分通常使用标题式大小写（想想“Site Stats”或“Recently Published”），而功能标签通常使用句首字母大写（如“Show buttons on”或“Comment Likes are”，其中“Likes”因为它是功能名称所以大写，但整体标签使用的是句首字母大写）。
当你查看整页的 UI 文案时，确保在所有内容中保持一致，并且所有类似类型的文案——标题、工具提示、按钮等——都使用相同的大小写格式。
错误消息
编写易懂且有用的错误消息的指南。
一：不要在错误消息中忽视语气/语调——它们传达了很多信息。
语气和语调所能表达的并不亚于单个词汇本身。错误消息必须传达大量信息，通常需要相当简短，但尽量不要牺牲语气，也不要走向过于消极或过于积极的极端。
假设有人试图发布一篇帖子，但他们的用户角色不允许这样做。以下是一些我们可以——但不应该——传达该情况的方式：
您的用户角色不正确。
在这里，我们显得冷漠无情。
停下！您没有权限执行此操作。
在这里，我们显得不必要的惊慌失措和严厉。
哎呀，我们不能让您那样做！
在这里，我们显得过于矫揉造作。
即使在错误消息中，我们也可以保持直接、积极和友好。怎么做？通过第二到第四条建议！
二：尽可能提供解决途径。
好的错误消息不仅仅是提醒某人出了问题。
您的用户角色不正确。
好吧，那又怎样？为什么这很重要？我该怎么做？这条消息如何帮助我？我需要知道我的用户角色为何重要，以及如何获得所需的角色以便我能完成我想做的操作。不提供任何指导的错误消息会让用户无路可走；如果我们现在不告诉他们，他们就无法避免重复导致错误的操作。
三：当空间紧张时，不要依赖术语来缩减字数。
您的用户角色不正确。请联系站点管理员。
也许我们在这里取得了一些进展：现在我知道了有一些事情是我可以做的，这很好。
话虽如此，也许并没有：我仍然不知道我的角色是什么，或者为什么它很重要。此外，我现在不确定什么是站点管理员，谁是我的管理员，或者如何联系他们。
这条错误消息中的所有信息在技术上完全正确，但这并不意味着它传达了任何有用的东西。如果目标是理解和解决问题，技术上的准确性并不总能让我们达到目的。
“您的账户没有发布帖子的权限”虽然没有使用用户角色 UI 的语言，但它解释了出了什么问题，即使我不知道什么是用户角色也能理解。既然我理解了，我也更能理解解决方案，即使消息到此结束：我可以看出我需要获取权限。
与现有 UI 语言保持一致固然好，但不能妨碍理解。
四：不要假设人们理解错误的来源。
您的用户角色不正确。
对我们来说，用户在他们尝试发布内容或更改他们没有权限的设置时收到此消息似乎显而易见。但对用户来说可能并非如此：人们经常到处乱点，特别是当我们不确定如何做某事时，而且我们并不总是记得刚才在看哪个页面或设置（或者是为了什么！）。
好的错误消息还应包含一些帮助用户定位上下文的线索。“您的账户没有发布帖子的权限”提醒了他们正在尝试发布帖子，而这正是导致错误的特定障碍。
五：记住，消息可能在被阅读之前就会消失。
默认情况下，Snackbar（轻提示条）会在出现约六秒后自动清除，无论是否有人读完。这是整个消息的时间预算，它不会为了较长的消息而延长。
因此，请让 Snackbar 足够短，以便一眼就能看完——一行是一个不错的目标。计算字符数在这里帮助不大，因为翻译后的文本通常比英文原文更长：对你来说占一行的消息在其他地方可能会换行成三行。
由于无法确定其格式，处理上传的文件失败。请将其转换为支持的格式并重新尝试上传。
对比
该文件无法读取。尝试将其转换为 JPEG 或 PNG。
当某人确实需要阅读消息并据此采取行动时，不要让它受限于那个六秒计时器。要么让 Snackbar 一直显示直到被关闭，要么使用设计上会停留的通知（notice）。