文案设计还能这样？不愧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 个部分，我用比较表意的方式翻译了一下：

1. 包容用语 Inclusive Language

2. 语法规范 Language and Grammar

3. 词汇术语 Vocabulary

4. 语音声调 Voice and tone principles

5. 写作规则 Writing Guidelines

6. 写作风格 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

除了像前面一样，提供注意事项之外，还提供了几个错误消息的案例。

例如对输入信息的错误提示，要清晰明确，让人知道具体怎么做才能避免错误：

当有未知问题时，尽量不要把问题直接归咎到用户身上：

当出现问题时，不要急于道歉，而是明确指出原因和解决措施：

当出现无法解决的问题时，尽量表达良好的态度：

5.4.功能发现

Feature discovery

向用户介绍新功能，让他们有兴趣尝试，是一很难的事情。

这里给出了一些文案上的建议：

• 考虑当时的场景，他们看到这句话之前在做什、想要什么、需要去哪里。

• 清晰表明用户的利益，让他们了解新功能的价值，例如“帮你更快地找到XX”。
  

• 语言尽量生动有趣一些，让用户感觉这是积极的体验。
  

例如下图这个例子：

标题：这就是一切的起点

正文：创建事项并开始你的敏捷工作流程，通过拖拽来管理他们的顺序。

按钮：添加事项

5.5. 资讯消息

Info message

跟用户发消息时，要当开门见山，说清楚打断他们的理由，并提供真正有用的信息。

标题：你还在吗？

正文：你离开蛮长时间了，所以我们把账号退出了。

按钮：登录

5.6. 成功消息

Success message

这里也只是列了一些注意事项，并没有具体的案例。

标题：

不是必选，信息丰富可快速阅读，尽量在3-4个单词以内，避免使用“成功”这样的词语，不用句号，避免感叹号泛滥。

正文：

避免重复标题内容，写清楚成功背后的原因，保持1-2句话以内，使用赞美的词语。避免直接展示过于专业技术化的信息，如果必要可以放到“了解更多”里。

按钮：

下一步不是必选，但一定提供关闭方式。使用1-2个清晰直接的动词（例如“保存”、“删除”，而不是“确定”、“好的”）。

5.7. 警告消息

Warning message

这里除了注意事项之外，终于又给了一些案例。

警告要在问题发生之前，而不是之后，例如增加新成员的时候就告知费用可能增加，而不是增加后再说要加钱：

尽量使用“我们”作为主语，而不是“你”，这样可以避免让用户感觉问题归咎于自己。

标题尽量简短明确，详细解释写到正文里：

6. 写作风格

在最后一个部分， ADS 明确了文案写作规则，与语音部分类似，主要包含三点关键：

要大胆：提供明确清晰的信息，让用户感觉可靠。

要乐观：让用户感觉充满欣喜，未来可以期待。

务实而有趣：开门见山简明扼要，并且还带点趣味性，不要消耗用户的耐心。

总结一下

很多细节我这篇文章无法全部转述，只能总结一些知识点。

看到这里，不知道你觉得  ADS 这个文案规范怎么样呢？

我整理了 ADS 的组件库和图标库，感兴趣的，可以在公众号后台回复 ADS 领取。

想要学习或者练习体验/交互设计的朋友，可以了解一下「体验设计学习社」。

作品集详细点评+答疑+免费训练营&学习打卡等活动，更有各类大厂内推：

如果你只是想要多认识一些同行，也可以加入我们无广告的纯粹体验研讨微信群：