关于有赞设计系统你应该知道的事

有赞设计系统第三版（V3.0）已经讨论了将近一年的时间，终于具备了一个相对完整的结构和基本可用的内容，体验设计师们目前正在展开轰轰烈烈的学习和反馈活动，以保证系统能更好地适应业务需求。

我们也开始在一些小范围的项目试用优化后的组件或模式方案，在此要特别感谢产品和开发小伙伴们给予的配合和支持。

对于一个活着的系统来说，迭代更新是生存特征之一，如同生命体。就设计系统这个生命体而言，基础定义和框架决定了它的运行规则，所有的迭代更新都是在这样的规则下产生的，以下是我们（设计者）希望你了解的一些定义和框架：

一、适用范围：

有赞设计系统V3.0（以下简称ZDS 3）适用于有赞SaaS（含微商城、连锁、零售、教育等）、其它管理系统（CRM、企业微信助手、导购员）、手机客户端、移动端适配的HTML界面。

也就是说，ZDS 3适用于B端管理界面，包含多种终端适配。

之所以没有包含C端，有两方面原因：

1、C端线上商城部分是商家通过B端管理的，管理规则的设计才是关键因素；

2、C端消费者是我们的间接用户，消费者体验是需要通过影响商家来完成的。

综上所述，C端的设计系统影响程度和影响范围就不如B端重要且紧急了，当然我们也正在梳理C端线上商城部分规则，此为题外话。

需要强调的一点是，“适用”不等于“一定要用"，即使在以上划定的范围中，ZDS 3能指导生产的界面也仅限于有规律可循的界面。对于那些特殊的界面，比如宣传类、引导类、流量分发类等，它们可以不使用设计系统，用另一套更适合的逻辑来设计。

二、层层推进的框架：

我们在讨论并确定了《设计价值观》和《设计原则》的基础上，确定了我们的”设计语言“。这三者的关系是从抽象到具体层层推演得到的。

设计语言定义了我们应该用什么样的形式来表达、传递、强化设计原则，基于现在主要的界面仍然是以屏幕交互为主，设计语言大部分与视觉相关，我们也在尝试增加一些语音和音效交互的能力。

设计语言在《设计基础 Foundation》这个文档中有详细描述，一共有11种规则，调整了颜色、字体、图形、栅格（布局）、间距、尺寸等，此外还增加了音效、插画、投影、动效等情感化表达的内容，目前还在逐步完善中。

三、术语、文案：

文字作为表达载体之一，是在以屏幕输出为主要手段的用户界面中最常见的元素。针对目前有赞B端界面出现的最大矛盾点，我们将文字分成了《术语和文案》两个部分。

术语是系统中用来描述数据对象、动作、状态的专用词语，保证每个人都使用相同的词来表示相同的事物或相同的含义。

为了达到这个目的，我们创建了《术语表Glossary》，要求体验设计师对描述的数据对象有充分了解，保证在撰写界面文字和文案的时候不用混、不用错。

这个表将与产品小伙伴共建、持续完善。

文案所对应的工作被称为文案撰写。我们总结了文案撰写的5个原则，为了帮助体验设计师熟悉并理解，我们同时创建了《文案案例库Copywriting》，在撰写文案之前，可以对照检查。

这个表也将与产品小伙伴共建、持续完善。

术语和文案还包括了之前整理的《标点符号用法》和《数据格式约定》等与文本有关的约定，在结构和范围上做了少许优化，这也是体验设计师需要共同遵守的文本要求。

四、组件：

组件是耗费了最大脑力来讨论的，主要纠结在“应该如何分类”上。

组件是可在系统中重复使用的、具有特定功能的、界面元素的集合，各大友商的分类标准均不相同，描述也不一致，我们需要根据有赞的实际情况来选择自己的标准。

经过多轮讨论，ZDS 3最终确定了两个维度：功能 or 形式，为什么是“or”？因为在有些组件中，功能和形式的边界并不清楚，比如信息录入类组件，以功能为主；信息展示类组件，以形式为主；导航和反馈类组件，既有功能也包含形式。

几次讨论下来发现无法兼容大部分情况，索性就确定了这么一个两可的维度，然后通过每个组件的定义和描述，来避免应用场景晦暗不清的情况。

另外一个纠结点是，是否需要单独为移动端设计组件？现在的结论是“不用”。原因有二：

1、在移动端管理复杂事务目前还没有成熟的UI解决方案，大家都在摸石头过河；

2、终端环境复杂不可控，出于开发成本考虑，我们优先选择兼容方案，在保证重要界面的基础上可以牺牲一部分可用性。

基于以上判断，我们没有单独为移动端设计组件，如果某个组件只适用于单一终端（电脑端或移动端），那么在组件名称上单独标注出来，如：单元格 Cell（仅移动端）。

事实证明，我们定义出来的55个组件中，只有4个仅移动端才有的组件。

在体验设计知识库的《组件 Components》中可以查阅这55个组件，每个组件都包含以下几个要素：

1、编号-中文名称-英文名称；

2、定义（功能 mix 形式）；

3、Figma文档链接，查阅详细内容；

4、相关组件，帮助理解组件之间的关系；

5、主O的设计师，有问题可以直接问ta。

五、模式：

关于模式我们走了一点弯路。

一开始大家认为模式就是复杂一些的大组件（有同感的举手），后来又和开发语境中的模式（Model）混淆在一起讨论（有同感的请再次举手）。

实际上，在UI语境中，我们的讨论是模式是一种Pattern，而Pattern通俗理解就是“元素以可预测的方式重复的规则”，如下图就示意了16种Patterns：

引申到软件领域，我们解释成：针对某一类问题的（可重复的）解决方案。

“每种模式解决一种特定问题，模式是用来避免重复造轮子的。”

思路纠正过来之后，对模式的定义也更容易了。

另外基于“好的模式还应该提供通用的结构和弹性空间，设计时可以添加、更改、去除某些组件或逻辑”这个要求，我们还会给出配置的方案，希望模式能更好贴合具体业务问题。

目前我们有9种在有赞SaaS域常见的模式，且全部集中在电脑端。在体验设计知识库的《模式 Patterns》中可以了解是哪9种，目前大部分描述还在细化过程中，好消息是每个模式都有主O的设计师，如有任何疑问和想探讨的点，可以直接联系他们。

我们希望未来在移动端也能提炼出好的UI模式，在一定程度上填补上文提到的“移动端缺乏成熟解决方案”的空缺。

六、系统迭代：

由于篇幅有限，定义和框架部分就介绍这么多，细节内容大家可以移步有赞体验设计知识库《ZDS V3.0》浏览。

回到开篇所述，对于一个活着的系统来说，迭代更新是生存特征之一。为此我们也建立了一些机制，比如建立协作流程、体验设计师人人参与和贡献、文档中标明设计主O、成立虚拟管理小组等。

设计系统是对多样化需求进行抽象和归纳，固化为组件和模式，这能大大减少产品、UI、研发和测试的重复工作量。但它仅靠设计师的努力是远远不够的，设计系统的生存状态需要各个业务环节小伙伴贡献力量、群策群力。

希望今天这篇介绍能解释清楚我们的设计思路和目的，未来在更多的应用场景中得到大家的支持和反馈，帮助这个系统“好好活下去”。