基于业务梳理设计规范方法心得总结

从2014年开始接触设计规范，到建立一套较为全面的设计规范供企业产品线使用。当中经历多个阶段与迭代，现在想想当时的艰难与困苦，如今再忆确实一段宝贵的财富。

项目初衷：

为项目的设计、产品与开发赋能，减少重复作业的资源消耗，提高设计师、产品经理以及开发的效率；为产品一致性提供可以依据的确定文档，查漏补缺的去优化产品中不一致，体验不够优秀的地方。

最早接手的时候，项目仍然处于相对早期的阶段，当时的设计规范还相对简单，内容较少。因为加入团队的时间比较早，有幸在不同的业务模块里摸爬滚打，也感谢当时老板的信任，让我接手设计规范的重担。

遇到问题：

刚接手时，不知如何下手。只能去搜集、查阅一些图书、线上材料，然而情况并不乐观，当时能够找到的基本是一些将对简单、平台单一的设计规范，比如iOS的设计规范。通过借鉴它们归类的方法，描述的方式等等，逐渐形成了第一个比较完整的，基于我们当时产品的交互设计规范大纲：控件、页面以及执行类规范，如下图。

初版设计规范大纲

本以为就像写作文一样，有了大纲，往里填内容会更容易一些。然而真正在实操过程中，才发现理想很丰满，现实很骨感。虽然思路变得清晰多了，在充实细节中还是会遇到困难：

颗粒度：企业级应用涉及非常多的业务模块，如何把具体的设计切割成合适的颗粒度，供不同模块的设计师方便又准确的调用；
进度：结构化的深度梳理设计规范，并撰写精细的设计文档，以及配合开发进行设计的代码化，都需要大量的时间和精力去学习、研究与测试，规范输出的进度是非常大的挑战。持续推行与优化：除了推行已经规范化、文档化的设计规范，还要不断的满足新的业务需求，同时收集用户反馈进行不断优化。
_

摸索答案

先上总结：首先要找到对设计规范颗粒度分类整理的依据，合理分类后，书写设计规范包括：罗列页面元素，并标注必须元素与可选变量；对页面元素根据业务需求，或者考虑后续的业务扩展等方面，进行设计延展性方案的归纳展示与注释；从产品整体性、一致性、良好用户体验角度给出推荐用法；执行类规范给出详细设计流程与注释。

针对问题一：颗粒度

企业级应用涉及非常多的业务模块，如何把具体的设计切割成合适的颗粒度，供不同模块的设计师方便又准确的调用；

首先如何把设计规范结合业务以合适的颗粒度分类整理
现成可以获得的一些设计规范，基本都是一些基础控件，非常常见的页面模板，在业务广泛，结构层级复杂的企业级的应用中，能够直接拿来用的部分非常少。企业级应用的设计通常分模块进行，对应模块有对应的设计师负责，这就涉及到除了设计本身之外的协作问题。企业级应用的模块在业务上有千姿万缕的关系，它的使用对象通常也是跨模块使用产品，因此，产品系统级别的一致性是非常重要。如何既满足业务需求，又达到系统的一致性，是设计规范划分合适颗粒度的最基本诉求。

颗粒度太粗，设计师设计时的自由度就会很高，不同业务模块的设计，甚至同一业务模块的类似功能的设计都很容易导致不必要的不一致。比如下图，用基础控件输入框与按钮去搭建对话框，不同的设计师可能会基于自己的经验、偏好给出不同的组合，这种不一致在系统中是应该避免的。

而颗粒度太细，也会导致缺乏组件灵活性，复用度低，进而造成重复设计重复开发的资源浪费。设计规范合理的颗粒度划分既要满足多元化的业务需求，也要尽可能的保证产品系统性的一致性。

具体做法举例：经过不断推演，同事的讨论以及实践经验，针对设计解决方案颗粒度切割问题，得到的判断参考条件是：控件作为独立控件或是组合控件进行设计规范整理，需要至少满足一点以下条件（如果同时满足多个条件，则调高控件代码化的优先级）：
a，作为整体，在大于两个以上模块重复使用
b，在用户实际业务场景中，其被使用的频率高（需要产品经理给出大致的数据范围，比如业务员每天/月/季度/年需要操作频次）
c，作为整体，在多个业务团队中被重复使用
d，控件作为整体多出现在用户使用的核心功能场景中
e，在既定的发布计划中会作为是重要的组成部分

在对系统做整体走查后，根据以上提到的判断参考条件进行梳理与统计，将设计规范涉及的内容按照控件分为了两大类：独立控件与组合控件。独立控件即大家日常所见的一些单一变量的基础控件，如输入框，复选框，下拉菜单等。在实际项目中，因为产品已经做了一段时间，大家对一些独立的基础控件的理解与使用的成熟度已经相对较高，独立控件的设计规范定义与细节也有的参考，所以做起来相对容易。

组合控件是由一些独立的基础控件及其他元素组合而来，在产品中却通常作为整体在系统被使用，也大量的存在于系统当中，尤其基于实际产品而制定的设计规范中，这部分规范所占的比例相对较高，也更加复杂。比如时间日期选择控件，就是组合了时间选择与日期选择两个独立基础控件而来的，适用一些既需要选择日期，也需要精确时间的业务场景；Choose From List（CFL）也是一个典型的组合控件，在用户的实际业务场景中，为用户提供一些复杂的选择场景提供多元化，多维度的信息的选择列表；页面模板与一些操作流程类的规范都可以归纳在组合控件当中。

以CFL为例进行设计规范书写举例。不熟悉SAP产品的同学可能不知道 Choose From List（CFL），它是在普通消费类产品里比较少见的一种控件，即使有也是非常简单的运用方式，但在企业级应用里却使用广泛，至少在SAP的产品里使用极其广泛。其目的是为了满足一些需要提供多样化信息作为选择参考或依据的业务场景。因为承载的信息量大，但又是临时性的选项承载容器，一般是以弹框作为载体展示给用户，除了提供多样化、多维度的信息外，有些业务场景可能还需要筛选与过滤的功能，来辅助用户快速定位到所需要的选项。

在沉淀这类控件的设计规范时，首先要做的，是对这一控件进行元素拆解，并做出标注，并且针对元素给出必须存在的元素与变量—即可选的元素(提供变量是基于业务团队可以结合自己的业务需要进行控件选择，也可以去掉一些业务上不需要的元素，这样既保证在大的层面上控件的统一，也能一定程度的满足不同业务的需求）。比如CFL的组成元素有：header, list, filter, search，header, footer，actions，如下图。

在通常所见的设计规范中，这些组成元素每一个单独拎出来，都可以作为一个单独的控件进行细节描述，有的可能还要进行拆解成多个更小的元素，独立书写设计规范。但因为CFL在我们的产品里一般都是作为完整控件被使用在业务中的，所以这里没有把它拆解成为多个小的控件，让业务团队自行组合。因为这样会非常容易导致一些一致性问题，如同一个弹框里面的控件使用不一致，摆放位置不一致等；而且对于多个业务团队可能需要分别自行搭建自己的CFL,造成设计与开发资源的浪费。

CFL__的组成元素举例

除了描述组合元素的基本组成要素，后面的设计规范还需要对不同的元素，以及这些元素根据业务实际需要的额外变量进行详细描述，并提供设计图例。还是拿CFL举例，在我们的产品体系中，根据业务上对信息量的不同需求，设置了可以承载不同信息量的CFL，以不同尺寸的弹框作为载体呈现出来。在此基础上，叠加具有单选/多选能力的，支持树形结构展示的列表等，以及需要根据业务场景显示或者隐藏的操作按钮，如filter, 新建图标等。如下图a，对于不同的行信息的显示给出的图例，并罗列出了不同情况下这些信息的组合方式与显示顺序，让读者清晰的知道，需要显示一列信息时候该选用那种；如果需要标签加上识别主体时候，哪种显示方式适用；如果系统化可以接受不同的显示顺序，那从系统性的角度给出用户一个推荐用法，以保证在大多数情况下用户看到的列表的内容显示方式是一致的；为了保证信息显示的清晰，突出信息纵向的对比，针对单一信息的列表是被放在小尺寸的弹框中的，而多元信息的选择列表是被呈现在中号尺寸的弹框中的，如下图b。

图a CFL中不同显示元素的列表元素

图b 不同尺寸、不同信息显示量与数据结构不同的CFL

除了以上的这些静态设计内容的样式展示与描述之外，组合控件还通常会遇到操作型的功能按钮被集成进去。对于这部分内容，如果该功能仅仅是运用在这一个组合控件中，那需要将这一功能涉及到的操作性步骤进行设计展示，并配以文字说明。如果这部分操作可被其他组合控件复用，那依据前述所列的判断标准，可以单独将这一部分独立出来，收录到执行类设计规范中，在本设计规范描述引用出处即可。比如CFL中的header 与footer, 这些是在其他的弹框或者页面中会被反复使用的，因此可以将其独立出来进行单独说明；而CFL中的filter则是该组合控件中独立使用的，这里的交互方式在不会被其他地方复用，因此，对于这部分的交互流程与细节就收纳到该组件中, 如下图，小尺寸CFL筛选操作图例。

小尺寸CFL筛选操作图例

接下来，是读者在看设计规范时候，在这么多内容中，他如何选择一个合适的控件来使用的问题。分享一点根据实践总结的一些经验吧（可能不是百分百适合所有情形，希望能有一些参考价值，也希望后续继续耕耘设计规范能够有更有效的提炼总结进行分享）：

i，针对简单的控件，最容易出错的是用错场景，其次是一些可以控件细节的误用。针对此类问题的解决方案是：建议针对产品，在不影响产品功能与体验的情况话，尽可能的精简控件的多样性，从源头进行控制；另外，对于能够清晰定义使用场景的控件，最好在设计规范中罗列建议使用的场景，同时罗列不建议使用的场景，避免误选误用。

比如在我们的产品里，会使用各种各样的弹框，弹框的尺寸也根据实际需要被定义为大、中、小三个设计控件具体是使用规则是最难清晰描述的一部分。根据实践的经验，总结可以得到以下个尺寸，对于不同尺寸推荐的是根据实际的需要选择合适的尺寸的弹框。但如果能够加上一些推荐场景的适用建议，则会帮助读者更容易的判断该用什么尺寸的弹框（如下图）。

大尺寸的弹框及适用场景建议举例

ii, 对于由多个控件组合的整体控件。这里控件通常是一些与业务场景强相关，且重复出现在系统中的内容，对于控件整体使用的把握相对容易，但是这类控件往往附带很多条件属性，在使用过程中往往会出现条件选择错误的情形。对于这个问题的解决，最好的是能够在设计规范中，在基本的控件组合元素讲清楚之后，能够将组合控件差别较大的种类以实例的形式罗列出来，供选择用户参考决策。

如前文举例的CFL，这是个典型的组合控件，根据不同的使用场景能够罗列出的常用组合方式有：简单信息选择（单选、多选），多层级选择（单选、多选），多元信息选择（单选、多选、批量）， 而这些不同信息量的选择判断可以作为用户判断的第一个基准，在匹配信息量之后，再根据实际需要增加/减少控件里面的其他组件，如筛选、功能按钮等。

CFL简单信息单选与多层级信息多选选择列表

CFL多元信息单选选择列表

iii, 页面模板与操作流程类的设计规范，设计规范本身已经非常详细，尤其是操作流程类规范，多数根据产品实际的业务需求，结合业务梳理出来的，设计规范本身是带有操作步骤及细节的，所以选择及使用起来遇到的问题不是特别多；对于页面模板类，一般也会有非常清晰的定义，哪些页面可以承载哪些内容，用在具体的哪些层级与业务内容上，如首页、分析页面、报表页面等，读者是可以非常清晰的根据业务需要进行选择。但也可能还是会遇到一些取舍与自由组合的问题，比如产品详情页面的一些组合元素是否在某些业务模块中需要去掉，有些复杂的业务需求缺少对应的页面模板，多以建议在提供页面模板像基础控件一样，提供适用的场景，方便读者做判断。

针对问题二：进度

结构化的深度梳理设计规范，并撰写精细的设计文档，以及配合开发进行设计的代码化，都需要大量的时间和精力去学习、研究与测试，规范输出的进度是非常大的挑战。

这个问题，应该是个共性的问题。我们对于设计规范的完善是分阶段进行的。当时项目推行的是敏捷开发模式（虽然没有非常严格，但是节奏在企业软件的开发来说还是比较快的），如果等所有的细节文档都写好，再进行交接开发，往往是难以赶上项目开发进度的。因此，结合项目特点与进度，第一阶段的设计规范采取了轻文档，重沟通的模式进行合作。这一阶段的轻文档主要体现在计规范的使用细节的文字描述上，而设计图例的细节仍然是保留的，设计的文档在不断的产出，沉淀成设计团队的第一批设计资产。这一阶段也是快速进行设计规范的代码化，让合作的团队尽快的使用起来的阶段。记得当时有段时候开发团队专门停下来进行架构的重新搭建，也是在为后续平台提供更大的能力做准备。那个时期对于设计架构的前瞻性灵活性等也都有新的要求，我们是直接搬到开发团队当中坐着，快速反应开发对设计规范当中的问题。

当第一个阶段趋于结束，大部分核心的控件，页面，操作流程等代码化之后，很多重复性的设计控件，页面等可以直接被不同的业务团队调用了。第二个阶段除了要处理收集到的不同业务模块设计模板的新需求，另一部分重要的工作是将第一阶段中缺失的设计规范中的使用细节慢慢补起来。很多人都觉得既然设计规范已经被代码化了，具体的使用细节应该不需要再补了吧，但我们认为是有必要的，考虑的原因有三个：1.人类大脑的记忆总归是有限的，时间久了之后，对于细节的记忆会慢慢模糊，不同人对重点的记忆与理解会逐渐偏离原本的定义；2.团队成员终归会有新老成员交替的现象，新的团队成员在使用缺乏细节描述的设计规范时，可能会难以理解系统中一些设计的考虑因素，在使用时也可能因为缺失使用指导选错模板等问题；3. 产品会不断的进行更新迭代，设计规范也会需要不断的跟新迭代，对于细节的使用描述缺失会对未来遇到的使用情境缺乏判断的依据。

同时，考虑到不同读者对设计规范的需求，为了方便产品经理直接使用现成的设计控件，我们输出了基于PPT的设计组件库，产品经理不需要任何专业的设计软件就可以自行搞定一些非常简单的业务，业务模块的设计师去review就可以了。设计师更多的精力也能够放在理解更为复杂的业务，以及去推行用户为中心的设计思维方法，去更好的服务产品。

在第二期的基础上，我们又尝试了将设计规范进行第三期的升级。不仅将设计规范的交互与视觉进行融合，还将原本文档式的设计规范迁移成在线版本，方便多有人随时查阅，对于最新的更新也能第一时间被读者获取，下图是我们建立设计规范网站（原设计稿）。

设计规范网站图例

整个过程同时穿插新设计规范的不断积累与旧设计规范基于用户反馈的不断改进，设计规范的整理进行了将近三年的时间。这三年里从对基础控件的只其然到只其所以然，对复杂系统的页面与流程有了更为系统整体的认知，在处理新业务时更加游刃有余。

针对问题三：持续推行与优化

除了推行已经规范化、文档化的设计规范，还要不断的满足新的业务需求，同时收集用户反馈进行不断优化。

任何规范与制度可能都会带来一些负面的声音。比如我们遇到会有人跳出来说，设计规范限制了创造性，开发中也有太多的限制，缺乏想要的灵活性，有时候反馈时效也没办法满足项目的进度要求。确实，我们也在这些方面不断的去尝试解决这些问题，虽然不能做到让所有人百分百的满意，但是产品执行一套统一的设计规范，无论是短期还是长期带来的收益都是不可忽视的。

设计规范的持续推行有很大一部分工作是去不断的去查漏补缺，纠正错用误用的案例。比如在第一版本的设计规范初具雏形的时候，我们针对所有系统做了一致性的排查，发现即使是下拉菜单这种控件，都会被用的五花八门。因为是企业级产品，这个基础控件被广泛的运用到不同模块中，而不同模块对于同一名称的下拉菜单中的选项可能是完全不同的，也可能是部分相同的。我们需要解决的问题：第一，如何保证不同模块下对同一类型操作的名称一致性；第二，在不同的业务单据下，对于有相同操作选项的下拉菜单选项中，如何既保留业务内在联系，又能提供菜单选项的顺序有据可循。

为了解决这个问题，我们通过产品走查的办法，首先，归纳同一名称下的下拉菜单的选项在跨模块中有哪些，并且进行统计具体的模块中，这一下拉菜单的选项有些什么；进而，对所收集到的菜单选项进行整理排序，找到不同模块中有关联或者相同的选项，保证其在不同的模块中在业务上是合理的，同时顺序是有延续性的。例如在售前与销售的一条业务线中，可能涉及的业务单据会有从活动-线索-机会-报价-销售订单等，同时业务的灵活性允许用户从任意起点进行基于本单据生成新单据。如活动可以生成线索，机会，报价或者销售订单，线索可以生成机会和报价，机会则可以生成报价与销售订单，报价可以生成销售订单。而他们在单据页面统一的父级名称都叫“生成”，但二级菜单的选项则根据业务单据不同显示不同的内容，虽然同一下拉菜单，交互行为的操作上是平级的，但菜单的选项其实是有业务先后关联性的，并且这个业务先后的关联性要在不同的业务单据中保持统一。

当做完这层次的梳理之后，同时顺便梳理了不同单据上需要的功能按钮，并进行了归类，最终输出了复用的单一共功能按钮以及需要下拉菜单选项的20个功能按钮，统一了单一选项按钮在不同单据的名称，统一名称的下拉菜单中的按钮内容及顺序。在后续设计师基于产品经理的需求进行功能按钮的选择或者增加时，对于复用的功能按钮有了唯一的参考来源，最大程度的保证了产品级别功能的一致性。

在持续优化方面，为了能够充分满足各个业务团队对于设计规范的需求，我们还制定了设计规范反馈机制与流程，将涉及到的人员都融入到这个流程中，力求能够深入了解业务线上的需求，产品的整体性设计规范更好的去服务产品，而不是游离产品之外的书写一些设计规范，缺乏实际使用价值。对于设计的创造性，我们不仅鼓励从业务团队发起的设计提案，同时也会结合实际用户需求以及用户反馈尽可能去创造性的解决问题，但也会综合考虑创新设计在产品层面的适用性、灵活性与扩展性以及投入产出比，来评判是否沉淀为新的设计规范。如果不作为产品整理的设计规范仅仅运用于单一业务线，创新的思路与方案去解决用户的问题是非常被欢迎的。

设计规范中后期对于规范的升级迭代以及设计新规范的合作机制与流程

对于规范代码化复用的时效性，在前面的规范分类阶段也有提到，根据实际业务的需求紧急程度、重要性、使用频次等等要素去总整体的评估，排定代码化的优先级。这块对于整体产品开发进度的安排也有非常高的要求，要留足开发时间的提前量，才能在想要复用代码化的控件时候得以运用。

写在最后：

后来的故事很多人都知道了，随着Fiori的不断完善，公司全面推行Fiori, 我们也面临着follow fioir 的转变，无论是哪方面的follow, 我们的产品在不断的融合Fiori，但对于从产品需求出发的设计规范，仍然需要维护，具体原因之前分享的文章中有提过，在面对庞大且细致的Fiori 设计规范，如何去运用到产品中，对于不能满足的情况设计的决策与对策仍然深受着之前做设计规范的影响，之前沉淀下来的许多经验也可以被运用到。

近年，许多企业都在不断的推陈出新的发布自己的设计语言与设计规范，优秀开源的设计规范成了许多设计者以及不希望自己去重复造轮子的企业首选，但我觉得无论运用哪一套设计规范，结合自己的业务形成自的使用规则与指导还是必要的，随着产品及团队的不断壮大，产品具有清晰、有据可循的使用规则是能够帮助产品在优秀的体验上走的更远。