文案设计还能这样？不愧B端国际大厂
如果你在很多互联网公司工作过，那么可能听过或用过 Jira，它是国内外最受欢迎的研发管理 SaaS 系统（之一）。
而 Atlassian 就是 Jira 的母公司，他们也有一套自己的设计系统 Atlassia Design System，简称 ADS。
Atlassia 的 B 端产品因为是 SaaS（软件及服务），有免费模式，所以客户很广。
虽然和 IBM 的 Carbon Design System 都是 B 端设计系统，但是 ADS 相对更开放，兼容性更强。
我曾经写了一篇介绍 Carbon Design System 的文章《IBM的Carbon设计系统果然不同凡响》，发现里面有很多与我们国内用户习惯完全不同的设计规范。
而 ADS 却没有这方面的问题，整个设计系统看起来与国内的 Ant、Arco 之类的 B 端设计系统比起来，差别并没有那么大。
但是，在研究 ADS 设计规范时，里面的细节还是让我颇为震惊，在国内基本找不到这么详实的细节。
今天我主要从文案的角度来讲一讲，因为这个部分其实很重要，用户大部分的时间是在看字而不是看图。
但是国内的设计系统，却在文案方面做得比较粗糙，缺少详细的规范。
ADS 的文案规范分为 6 个部分，我用比较表意的方式翻译了一下：
包容用语 Inclusive Language
语法规范 Language and Grammar
词汇术语 Vocabulary
语音声调 Voice and tone principles
写作规则 Writing Guidelines
写作风格 Writing Style
内容真的很长，如果你自己去看，哪怕是中文怕也要花费不少时间，更不要说是英文了。
接下来我就给大家整理一下重点，看看有哪些是值得我们学习借鉴的。
1. 包容用语
Inclusive Language
其实讲白了，这个部分讲的主要是政治正确（Political Correction）的问题，规避了一些可能对特定人群产生有冒犯的用语。
里面明确规避了对文化地区、种族、弱势人群、性别、性别取向、年龄、贫困的歧视和粗俗用语，每种类型都给出了不少案例。
例如不能用 Citizen（市民）而要用 The public（公众），考虑到不是所有人都在城市居住。
不能用 Abnormal（不正常）而要用 Atypical（非典型），为了避免擅自定义什么是正常。
第三人称代词不能用 Her （她）或者 Him（他），而要用无性别指向的 They，哪怕指代的是一个人。
……
中文在政治正确方面要求宽松一些，但也确实是有值得借鉴的地方，以免一些员工不小心写出冒犯用语，有损公司名誉。
2.语法规范
Language and Grammar
这个部分主要规范的是一些语法规则，尤其英文经常有多种写法。
例如，他们规定引用名称或标题时，要用斜体字，而不用下划线或其它样式：
正确：According to the 2008 IT Unplugged report, IT is really unplugged!
错误: To learn more, see the 2008 IT Unplugged report
例如，标题短语不允许在结尾加句号：
正确：Public room
错误：Public room.
例如，尽量用缩略语：
正确：Can't, don't, it's
错误：Cannot, can not, it is
中文的语法虽然简单一些，但也会有类似的问题，例如：
用阿拉伯数字还是用中文大写？
英文和中文之间要不要加空格？
省略号究竟用六个点“……”还是三个点“…”
……
3. 词汇术语
Vocabulary
很多名词可能有好几种叫法，就连对自己产品的称呼，都可能不是那么明确。
例如究竟使用“团队”、“组织”还是“团队”？
这里可以把词汇术语规范化，以免造成不必要的误解。
但是很可惜，这一部分 ADS 没有公开出来，具体如何我们看不到了。
4. 语音声调
Voice and tone principles
这里是针对语音给出的指南，如果产品没有任何地方提供语音，那么就不需要这一部分了。
ADS 认为语音代表个性，而声调代表情绪。
他们把声音划分了 3 个维度：
Less bold（不太大胆） - more bold（相对大胆） Less optimistic（不太积极）- more optimistic（相对积极） Practical（务实） - “winky”（有趣）
并规定了在什么情况下，要用什么倾向的声音。
例如在出现警示时，用户会出现担忧不安的情绪，这是要轻声细语，用 less bold 的声音会比较好。
而在用户情绪良好时，例如在获得成就时，就要用更加大胆的声音，激发正面的情绪。
不过很可惜的是，这个规范是纯粹文字说明，并没有语音示范，没有相关经验的人看着会比较难懂。
5. 写作规则
Writing Guidelines
这部分的内容很多，详细明确了各种具体的文案规则，包含 7 种重要场景。
5.1. 日期时间
Date and time
在位置不够时允许用简写，例如 Monday 写出 Mon，January 写出 Jan。
写日期的顺序是，周、月、日、年，中间用“,”分割，例如：Monday, January 8, 2020。
纯数字的日期虽然更加标准，但难以阅读，如果一定要用，可以用“-”分割，例如：2021-05-23。
时间段不能写 2014 - 2015，而要写成 from 2014 to 2015。
时间要在数字后面直接加 a.m. 或 p.m.，例如 8 a.m. 而不是 8:00 am。
5.2. 空状态
Empty state
这里规定了空状态的文案的注意事项，但没有给出具体案例。
标题要求信息量丰富、阅读效率、生动有趣，不用标点符号，并提示下一步操作。
正文要告知原因，下一步可以去哪里，避免重复标题内容，并且保持一到两句话的长度。尽量避免跳转操作，如果必要则可以使用“了解更多”链接。
按钮的要求就更多了，要求使用 1-2 个命令式动词（例如“删除”或“创建”，而不是“确定”或“好的”），允许拒绝、取消或退出。操作按钮作为标题的补充向用户明确下一步操作。但如果没有必要，也可以不展示。
5.3. 错误消息
Error message
除了像前面一样，提供注意事项之外，还提供了几个错误消息的案例。
例如对输入信息的错误提示，要清晰明确，让人知道具体怎么做才能避免错误：
考虑当时的场景，他们看到这句话之前在做什、想要什么、需要去哪里。
清晰表明用户的利益，让他们了解新功能的价值，例如“帮你更快地找到XX”。
语言尽量生动有趣一些，让用户感觉这是积极的体验。