在日常工作中，您是否也有过因为没有规范的文档，而出现的文件找不到、或交接时信息错漏等头疼现象？本文将分享一些关于完整的设计规范系统的搭建方法，（主要针对于多端产品）希望对您有所帮助。

-------------------------------------- 

1、为什么建立

2、”设计规范系统“是什么

3、如何建立

4、如何使用

首先，我们需具体分析目前所存在的问题方能对症下药。最直观的方法便是从其使用性、内容结构两个方面进行分析：

1.1.使用性层面：

各端规范大多是穷举组件，少量标注，极少附有使用说明；每个组件的撰写结构、顺序不一致；每份文档格式相对独立；对于需同时进行多端设计的同学有可能会出现混乱；

1.2.内容结构层面：

• 各个平台的风格差异过大；

大多属于历史遗留问题，在初期规划时，对产品调性的把控不周，致使风格差异甚大；

• 组件的统一性、可复用性低；

每个组件几乎独立存在，组件间缺乏联系，各端倍数不明确，导致在多端产品线上，无法快捷跨平台适配；

• 团队协同效率低；

经常找不到文件，需要老同事帮忙；或是文件版本较前难以追溯；再者工作交接时，新同事很难快速了解；

• 可持续发展性弱；

研发团队没有建立组件库的意识。大多数组件样式单独写死，无法统一修改，全局改动需耗费较多成本。这也是设计师经常会遇到一种现象，仅需要全局改动某一个按钮样式，或者某一个组件样式时，得到研发同学给到的反馈大部分时候都是“这个实现起来很困难”、“这个不好做”...

• 个人工作效率低；

调用资源时，经常需要去翻查以往的源文件然后复制粘贴到新文件里面，遇见文件大的可能还要卡上几次。这种重复又无任何意义的操作着实浪费时间；

• 缺乏文件管理观念；

文档存储不统一，历史版本无整理；切图命名不规范，增加开发陈本外；

等等以上，这些都是日常得不能再日常的现象了。这些问题在产品快速发展的过程中将更加暴露的彻底且不可逆。如果您希望设计越来越好，值得信赖，就需要让我们从头开始，建立一份完整的设计规范系统来帮助我们的产品在成长中呈现规律且清晰的生长模式，并且是可控制、可迭代的。

那到底“设计规范系统”是什么？需要具备什么特质呢？

“设计规范系统”指的是用于推进各端的设计规范格式统一而建立的规范系统。在设计规范的统一格式基础上，能更加快速的进行多端设计语言的统一。主要运用于多端产品线规范。完整的规范系统需要具备简单易懂、结构清晰、倍数确定、异同明确等特质。

以希沃易课堂、希沃品课为例，都是典型的多端产品。包含大板端、电脑端、网页端、平板端、移动端等多平台组合结构。对于这类多端产品，日常中，最繁琐最耗时间且最没有意义的工作不外乎就是适配工作了。拥有一套完整的规范系统可以更加有条理的设计，也让工作更容易。

建立一个相对完整的规范系统需包含哪些部分？可以从建立原因提取出关键问题点来作为整个系统的结构框架。分别为：设计手册、资源库、产品实时文档、命名&存储规范、使用说明。

设计手册即是目前惯使用的视觉规范；又可细分为设计语言、组件库两部分。

设计语言一般包括原则性的说明（产品设计原则、通用原则、内容策略等）以及视觉元素（颜色、大小、字体等）的基础定义。组件库则可按照组件类型划分为通用、导航、数据录入、数据展示、反馈六种类型。设计语言的“视觉元素”与组件库是整个规范系统最基础的规范部分，也是最核心的内容。

资源库则可以理解为日常工作中的切图池。按照切图的类型以及日常工作中资源的调配关系，可分为图标库、图形库、组件库三部分。资源库主要作用于日常工作中资源的切换或调取。传统的资源查找、复制方式过于繁琐，资源库一键更改的快捷方式可大大提高设计效率。

2.3."完整文档"

完整文档指的是线上版本的视觉稿全文件。一般分为（sketch）源文件或输出标注稿两种。源文件一般可作为后续多版本拓展、内部协同、工作交接等作用，标注稿则可为设计走查等提供检验标准。

2.4."命名格式"

命名格式指的是在规范系统中建立统一的命名标准格式。在这基础上方可建立规范化的文档管理模式。比如文件存储、资源库的切图资源、样式库等。

2.5."使用说明"

使用说明即是整个规范系统的基础使用法则说明。可供新手快速了解产品的整体设计语言，或在团队协作中起到统一基础准则作用。通常需要罗列说明的内容有：整体的各端倍数关系、通用字号、通用列表等基础属性、共性。

在建立之初，需了解并明确元素与元素、元素与组件、组件与组件、以及组件与规范系统间的关系。

• 原子设计

2013年网页设计师 Brad frost 从化学中受到启发：原子元素结合在一起，形成分子，进一步结合并形成相对复杂的生物体。

而宇宙中的物质最小单位“原子”则是由英国化学家/物理学家约翰·道尔顿提出，原子是一种最后的不可分割的物质微粒。进一步说明，原子是所有物质的基本组成部分，分子是两个或两个以上的原子通过化学键组合构成有机物，最终形成宇宙万物。并且在已知宇宙中的所有事物都可以分解为一组有限的原子元素（化学元素周期表）。

于是  Brad frost 将这个概念应用在界面设计中并提出了原子设计方法论（Atomic design）。由原子、分子、组织、模块和页面共同协作以创造出更有效的用户界面系统的一种设计方法。

原子是最基本和最小颗粒度的单位，在设计中以“元素”的形式存在，例如：颜色、文字、图形、线条等；分子是由原子排列组合构成，在设计中以“组件”的形式存在，例如：标签、按钮等；组织是由原子、分子排列组合构成，在设计中以“模块”的形式存在。例如：列表等；模板是由原子、分子、组织排列组合构成，在设计界面中以“原型图”的形式存在；页面是由模块填充了内容后形式，也就是设计中的“视觉稿”。

原子设计理论最大的价值，就是为设计体系、组件库的构建提供思路和方法。从抽象到具象、由局部到整体，层级分明，充分发挥了设计元素的可复用性，避免重复生产，为设计师构建组件库提供了清晰的方法论指导。且可随着产品的不断迭代，只需改变某些原子、分子的属性或组合方式，便可使整个体系同步更新，易于扩展和维护。

• 建立的步骤

在明确所有关系之后，便可确定规范系统的制作原则：从小到大，从大到小；寻找相同点，定义倍数关系。所谓从小到大，从大到小的意思便是，从每一个端到整体产品，再从整体框架到每一个组件。保证每一个端，每一个组件都在框架内。 1.确定设计手册的内容；

也就是确定视觉、组件库中哪一些元素、组件是需要归纳到设计规范里面的。设计界面中构成的最基本元素一般有：颜色、布局（尺寸）、字体、分割线、蒙层、圆角半径、阴影等，2个以上排列组合即可组合成组件。

组件库则是由元素（视觉）组合而成的组件，或由组件与组件排列组合构成模块；可根据组件视觉属性、操作属性划分为通用、导航、数据录入、数据展示、反馈六种组件类型。

组件库中“通用”是属于最基础的的组件，是最基础的元素进行最简单的组合且是设计中几乎各个界面都会经常运用得到的组件。而数据录入中的“输入框”、数据展示中的“列表”从结构上其实更亦似通用的基础组件。很多组件、模块都是在这基础上进行二次组合而成。

2.确定整体内容框架结构；

“视觉”即是确定“视觉”元素、“组件库”组件的撰写维度有哪些。“视觉”部分是属于最基础构成部分，每个部分都是独特的元素，因此每个元素的撰写维度也尽不相同。可根据每个元素的特点进行分析撰写即可。

色彩一般应用于背景、图标、文字、分割线等场景，根据其具体使用场景以及颜色属性可归类为三种类型：中性透明色、中性实色、产品级色彩体系。文本、分割线、蒙层等这类型元素的使用场景较为多变，采用透明色值可以更加融合于背景，属于中性透明色。图标、背景则常为具体色值，属于中性实色。而产品级色彩体系则主要有产品的主题色、辅助色、功能色等带有产品特色的运用。另外也需注意作为背景色的动作用色，即normal、hover、click、disabled、focus等常用状态用色。

布局通常包括设计尺寸、基础布局。需了解并明确各端的基本尺寸大小，再根据各端使用特性或交互特性定义其基础布局。例如各端界面排布方式、窗口大小等。

字体一般包含字体选择、字号标准、文字颜色等信息。大多按照各平台系统默认字体为基础字体。常用字号可按照使用属性划分为五个区间：说明、常规、标题、大标题、特大标题。同时，根据各端常用字号梳理和统一标准用字。另外还需考虑文字在深浅背景上的用色。 

阴影、分割线、圆角半径、蒙层等属性相对单一，可按照简单的按照类型、使用场景进行分析。

“组件库”中的组件都是由元素组合而成存在一定的共性。大体可从组件简介、使用场景、交互说明、结构解说、尺寸、出现位置、动作解说等这七个维度进行分解。需注意通用单一、多平台组件的框架差异。

3.定义命名格式规范；

可命名的大致分为文件存储、资源库的切图资源、图层样式库等三部分。文件部分主要为源文件、标注稿的文档管理，通常用按照项目划分、版本号作为子目录名称即可；切图资源类型主要有三类：图标、图形、组件，其中，图标、图形可根据类型、功能模块、自身属性定义命名格式，而组件的命名则可根据设计手册的框架作为主结构再根据组件特性定义。图层样式库的内容是有赖于设计手册中的内容而存在的，因此可依据设计手册的框架为基础，再结合实际使用定义命名结构。

需注意的是所有命名格式都需使用“/”符号区分层级结构，除文件命名外。层级结构命名可使用中文，不一定非要全英文，毕竟大部分人并不熟悉英文，特别是一些专业名词，只要是合理并且能清晰展示框架结构即可。在样式命名上，也可适当标注相关属性，如字号或字阶区间等属性，方便快速查看信息。

4.根据已确定的内容、框架梳理产品各端基础规范（设计手册），并统一呈现格式；

“设计手册”源文件需按照已定义好的框架分为6个模块，分别为设计语言（视觉）、通用、导航、数据录入、数据展示、反馈。每块内容按照统一的布局格式排布内容。头部为主信息，包含名称、设计尺寸倍数等。所有内容从上到下、从左到右分类排序。左侧为文本说明区域，例如使用说明、微交互等，右侧有样式展示区域。

5.创建颜色样式库、文字样式库；

根据已定义好的内容建立。颜色图层样式需注意深浅两种背景用色，以及常用背景色的动作用色，即normal、hover、click、disabled、focus等常用状态用色。

文字图层样式则按照基础字阶表、深浅色场景建立样式库。

需要注意的是，样式库中的字体选择，需考虑各个平台设备的字体差异，以及日常工作中调取组件时更替字体的便利性。在协同工作环境中，选择一个较为通用的字体作为组件库的基础字体更能提高效率。多方案的文字样式库，其制作与维护成本都较高，并且在实际运用中，使用者未必能及时替换对于平台的字体，再者这种多方案的组件库、样式也违背了规范系统的初衷。

在无法制定多方案样式库的情况下，只能提取各平台共性进行折中选择。众多平台设备中，IWB、android、win、web等惯用于 Microsoft YaHei；IOS、Mac则是苹果系，PingFang SC。而内部产品所承载的平台大部分是IWB、android、web、win等平台，再者IOS、Android共用一套视觉、Mac、win也共用一套视觉，则可视为使用Android、win为基准，故定义 Microsoft YaHei 为基础字体。

另外，需考虑当作为文本按钮时的颜色应用是如何（normal、hover、click、disabled、focus状态的颜色应用）。以及对齐方式、段落格式，目前sketch的文本样式在实际应用中是没办法编辑文字的对齐方式、粗细、行高等属性，所以需要把各个所需的文本属性单独建立为样式组件。

最后，考虑到实际的使用场景中，使用频率较高，或者子级内容较为庞大，又或者子级多且内容单一，可以适当调整样式的命名结构。例如，文本颜色，在实际的检索中，更多的是关注的是其色值，而不是透明与否的性质，即可省略“中性透明色”该层级。

6.建立资源库

资源库本身是个sketch文件（sketch中的library或组件库）。由于在规范系统中，不单单只包含组件，还有各种图标、图形等各种资源、各种样式，避免“组件库”跟框架中的组件库混淆，故此定义为资源库，也是为了能更好的理解整个框架结构。

建立资源库的好处在于可以即时同步更新新编辑内容。当你编辑资源库里的某一个组件时，那么调用了该组件的其他sketch文件会收到组件库更新提示，可以对新编辑内容进行预览、对比和确认，使该文件中所有调用的组件同步更新到最新编辑版本，也可进行选择性更新。

利用已建立好的图层样式，创建资源库。常见类型有：图标、图形、组件。把图标、图形建立为组件也是为了方便资源调取，提高资源的复用性。特别是图形类资源，这类资源普遍为一次性消费，把所有的资源整合到一起后，在后续的工作中可当作为灵感素材库，也可在项目紧急时快速获取有用素材。

在建立时，每一个元素需赋予已定义好的图层样式，才能在后续的运用中起到作用。

其次，作为一份通用于多平台设备的规范系统，需要考虑每个平台之间的异同关系，并且有明确的倍数关系。后才可定义通用组件再可进行各端组件合并，或重新定义较为复杂的组件。

在做触摸大屏、电脑端、网页端、移动端、平板端这几个平台的通用组件时，一定会十分的头疼。常规的移动端多尺寸适配就已经够各设计师挠头了，何况现在各种类型的平台设备，倍数关系不同不说，直观视觉感受差异更是大，还需考虑可交互的动作展示效果。

可以从各端的基础属性进行共性提取。从下表中可得知PC、web、pad1@x三端为相同倍数关系，命名为关系A；IWB与Moblie为相同倍数关系命名为关系B，关系A与关系B之间的差异为视觉阶梯参数中，后者比前者高一个参数。另外，Pad、IWB、Moblie为相同的触摸操作模式，需注意交叉关系中的部分组件展示样式的差异性。 

再者，资源库的内容展示排布需按照框架结构的类别进行归纳，并且带有分类文字标明。通常在一个较为完整的资源库文件里，组件的类型会十分的复杂且数量多。按照一定的顺序、类别归纳整理排布，有利于后续进行迭代调整或者检索时快速找到对应的组件。统一的排序方式也有利于组件之间的对比与校对。

在大部分公司里，规范经常都是处于被动又尴尬位置，不是做了没人看，就是没做就有人喊着要的；又或者写完共享出去就完事，也不确定所有人是不是能够完全明白规范里的所有内容等现象。这些其实都是团队对于高效协作意识不够所导致的。

在规范制定完成后，需对规范内容进行核心部分提取并，尽可能的把基础信息、通用信息等能让人一眼便知晓规范的大致信息的内容提取出来作为规范的基础准则且形成文档形式。然后对内部团队包含研发团队进行一次且详细的规范讲解，快速的提高大家对规范认知以及熟悉度。这对于工作交接、团队协作、甚至是多方案产品都是大大提高工作效率的第一步。

了解是否为组件以及有无图层样式的差异；作为一个组件并且运用图层样式时，则可以快速在右侧操作面板进行快速的更换组件、或者更换图层样式，比如颜色、文字属性。且若引用的library有内容更新，则可点击右上角的通知进行同步更新。

如果只是普通的界面元素组合但运用了图层样式，除了不可快速替换组件以为，仍可以快速在样式库中更换属性或者更新属性信息。

但若两者均无，则需找到相关的属性说明文档再为此更换其属性，操作起来较为繁琐不说，多人协作时，内容的维护与更新的信息是无法即时同步的，需流水线式的更替，稍有信息不对称的情况，就有可能出现内容不统一。

资源库的组件调用也是十分便捷，在顶部工具栏中的添加可进行快速的调取使用。如若是替换组件，则可选中组件才右侧操作面板进行更替，或选中组件后右键选择“替换”进行更替组件。

3.记录每一次内容更新记录；

详细的记录每一次更改的内容以及更改时间，如果允许，图例说明是最好的呈现方式。把更新内容记录下来不单是为了内容追溯、同步信息更是为后续迭代做基础，

4.定期维护完整文档；

完整文档有很多种管理模式，但在维护前需明白，这本身便是属于投入产出比低的工作。需根据团队自身要求去维护，而不是无意义的为了做而做。

关于维护的方式，在实践一段周期后，发现以大版本为节点，或以版本周期为节点能更好的做好维护工作，如Vx.x.0、Vx.0.0。通常在这些版本周期大概为10个小版本并且长伴随大改版或者大功能迭代，可以配合这类契机点进行文档整合，事半功倍。

在梳理好的文件里，可适当标明信息，例：v1.1.0（完整文档）。

规范是需要灵活运用的，不是把设计师框死，也并不存在绝对的对与错，只有适合与否。

end--------------------

希望这篇文章，在你对设计规范系统搭建时能提供一些帮助。

@chenlinchun 设计笔记

部分落地稿

Powered by Froala Editor