导语:浏览了许多关于“设计规范”的文章,发现很多都是在针对通用流程和视觉方面在整理,关于交互层面的内容比较少。基于此,结合最近项目中沉淀的实际案例,以及参考了不少行业通用的设计规范,总结了一篇关于搭建交互规范的流程、框架、要点。希望能够帮助大家更好的沉淀交互规范。
 

文章概览

本文共三个章节,阅读全文大概需要15分钟。

1.如何「理解」交互规范

说起设计规范,大家应该都不陌生,一个成熟的设计规范对 产品设计、研发开发、用户使用 都有着重要的指导作用:
产品设计保障产品内不同模块的设计一致性,同时提高不同设计师间的设计、协作效率
研发开发:通过定义的标准规范,提高流程、组件的复用率,提高整体开发效率
用户使用:让用户能够在产品全局感受到统一且完整的体验,降低使用成本和学习难度
而一个完整的设计规范一般分成「视觉」「交互」两个部分合并组成,在全局原则的指导下,侧重不同的维度和内容分别展开规范的定义,最后再合到一起形成一份完整的设计规范。
从用户体验要素来看,视觉主要是在「表现层」「框架层」进行规范的统一,主要包括:形、色、字、构、质、动 六个层面。
而交互角度相对抽象,主要针对于产品的「结构层」「框架层」入手,定义统一的交互规范,指导页面、流程搭建和组件使用规则。包括:全局原则、页面布局、通用流程、标准组件、文案规范
整体维度呈“从抽象到具体的总分关系”,不仅对产品的各个维度都有具体的交互指导,而且不仅能保证长期使用,避免重复返工;同时也便于囊括后续的迭代内容。而这些内容,就是我们通常定义的交互规范,也是交互参与定义设计规范的发力点。
有了对于基本认识和搭建框架之后,我们来详细聊聊如何定义交互规范具体内容。

2.不同阶段应该定义哪些交互规范?

产品有不同发展阶段,设计规范同样也有,不同阶段下的产品目标和规范需要覆盖的内容都不尽相同。我们要既要避免做多,保证投入产出比最大化;同时也要构建一个合理的规范迭代思路。
产品探索初期:
该阶段的产品核心目标是「验证产品或商业模型」,业务需求都是小步快跑、频繁迭代。产品处于从0到1的野蛮生长状态,存在着“先满足功能,再优化体验”的情况,导致该阶段的产品体验往往不太过关。
搭建目的:通过定义原则,梳理关键页面和流程,搭建基本的规范框架。既让团队对产品有统一的设计价值观和认知判断;从页面到流程,又能对应设计参照标准;同时业务可以在规定的框架下发展,不仅让产品体验的根基牢固,而且不会限制功能设计自由。
搭建范围:「全局原则」「页面布局」「通用流程」
 
产品稳定发展期:
该阶段的产品基本形态已稳定,也形成了初步的模型结构。后续迭代是在现有结构的基础上,进行增加或优化功能。虽然探索期定义了产品原则、布局和流程,但探索期产品的自由生长,会导致不少设计细节不一致,从而影响了产品整体的体验和效率。
搭建目的:通过回溯整理过往设计,沉淀优化成完整的交互规范。再根据规范统一产品体验,进一步优化流程和效率, 让整个产品体验达到相对稳定的状态。
搭建范围:「全局原则」「页面布局」「通用流程」「标准组件」「文案规范」

3.如何「定义」交互规范

3.1 定义交互规范的原则

与行业通用的设计规范(如TDesign、AntDesign)“大而全”“通用”的特质不同,一般团队内构建的设计规范都是源于某一个产品或业务,主要的特点是“专精”。专注于「业务」本身,主要是「团队内成员使用」,追求的是投入产出比最大化。
基于此背景,当我们在定义「交互规范」时,有三点原则:
原则一:保持规范的业务性。设计规范既要贴合业务场景归纳完整,同时又要避免凭空定义脱离实际。故我们定义时要代入业务规划,尽量富有前瞻性,这样定义的规范不仅能覆盖当前需要,同时后续也能更好地迭代。
原则二:保持规范的专注性。有的放矢,明确内容优先级,避免盲目追求大而全和形式主义。对于优先级高(覆盖面广、复用率高)的关键内容重点描述;优先级低(逻辑简单、认知一致)的内容可简要描述,避免事无巨细降低效率。
原则三:保持规范的生长性。设计规范不是一成不变,而是跟随业务发展不断迭代完善的,所以需要阶段性的回顾规范。遇到规范未能覆盖或无法指导设计的地方,及时修订同步团队,避免墨守成规,固步自封。
最后,还有一点建议:在定义规范时,可以站在前人肩膀,适度参考行业设计规范,能复用用的直接参考,具有业务特性的再集合业务综合考虑,使整个规范制定效率更高,科学性、指导性更强。
在找到自己当前所属的产品阶段、明确要建立哪些设计规范后,具体应该如何进行落地执行呢?建议从以下4个步骤入手。

3.2 第一步:定义规范分类

如上文中提到,一个完整的交互规范分为:「全局原则」「页面布局」「通用流程」「标准组件」「文案规范」五个维度,但每个维度具体含有哪些内容,都是不一样的。仍然需要根据实际业务需要去定义,这样才能尽量保证没有遗漏,也更好为下一环节评估工作量。
通用的做法有两种:
方式一:整理业务场景下不同的页面、流程等,并进行抽象合并。「全局原则」「页面框架」和「通用流程」具有强业务导向,可以采用此方式。
以「页面布局」为例,就需要将关键页面按统一颗粒度收集(按层级或按场景等)。
方式二:参考行业通用规范的定义,先罗列完整,再根据产品实际业务需要进行增删改。
「标准组件」「文案规范」已经在行业内有了不少科学的目录和沉淀,可以采用此方式,例如下图组件的梳理。
最后可产出如下图的规范分类和具体内容。(可以列的不是很全,后续补充具体部分内容时持续维护这张表。)

3.3 第二步:确定分工排期

有了具体内容作为依据,便可以根据此进行排期分工。
分工原则推荐按规范分类进行分工,一个大的分类由一人负责,保证专注性。同时团队交互最好都能参与,保证后续对规范更好的沿用。
排期原则:「定义规范」和「输出需求」两者经常要并行处理,此时提高效率,控制投入产出比就很重要了,我们需要明确优先级,先做什么后做什么。有3个思路可以综合参考:
– 并行的思路:在定义完「全局原则」后,剩下的页面、流程、组件、文案都可考虑并行定义,彼此之间没有明确的依赖项。
– 迭代的思路:近期有迭代的版本,如:即将改版的模块、反馈较多体验较差的模块,其中涉及到的页面框架、组件可优先定义。
– 复用的思路:某些典型页面、典型流程、典型组件涉及面广,许多需求的设计都将借鉴参考,亦可优先抽象定义。

3.4 第三步:统一撰写原则

设计规范是由不同的设计师一起合作完成,所以我们尽量在一开始,就需要统一规范的撰写和展现形式。以此提高后续合并的效率,同时又能保证其阅读体验,让其它使用者能够更好遵循。对此,我们定义了几个关键原则:
目录完整:高效检索,快速让使用者找到需要的内容。
原则清晰:抽象的内容往往含有许多概念和原则,需要让使用者先理解再参考,才能保证后续使用正确、举一反三
多图少字:没有人喜欢看字,图片更容易吸收
搭配案例:让使用者更好的代入场景,理解和使用规范。

3.5 第四步:定义具体规范 ★

前面铺垫了许多流程性的内容,就像我们日常输出设计需求一样,大家或多或少在工作中都有遇到过。接下来,将重点聊聊,我们具体的内容应该如何定义。依然分成5个环节一一讲解。

3.5.1 全局原则

目标:明确影响整站各个模块、各个页面设计的原则和规范,指导我们后续各种规范的定义和设计。
而全局原则也分两种,设计原则和业务原则两种。
设计原则:每个完整的设计规范都需要包含的内容,如:设计价值观、设计准则。看似相对务虚的东西,实则影响后续整个设计方向。这个部分需要和产品经理、视觉同学结合产品的定位和发展共同提炼。具体定义方式可参考:
你为什么需要设计原则?
 
https://zhuanlan.zhihu.com/p/246430795
业务原则:源自实际业务本身产生的问题,行业内没有标准定义。需要具体问题具体分析,推导出具体目标,最后再统一制定规范解决业务问题。
举一个实际的例子便于理解:全局Z轴定义
1)明确问题:整站层级高度没有统一定义,导致不同控件间相互遮挡,没有统一规则。需要定义全局Z轴规范,统一不同场景、页面、组件的高度。
2)梳理借鉴:统一梳理相关场景、页面、组件,明确需要定义的范围。再查找行业规范,有无参考借鉴。(如Z轴定义,可参考Material Design)
3)定义规范:最后通过最具代表性的场景进行展示
全局原则没有维度高低之分,例如可能全局涉及到的「右键菜单」也能被定义成全局原则。不必盲从行业交互规范内庞大且抽象的原则。只要能够实际解决你业务的需要,能够覆盖整站各个部分,都可以纳为全局原则。

3.5.2 页面框架

目标:梳理整站所有关键页面,整理抽象成相对固定的 框架布局&功能分区 让后续设计新页面时能遵循规律、找到参考。
页面框架的搭建一般由四个步骤组成:
第一步,收集页面:根据早期定义的规范分类,收集展示所有相同层级的页面。这些在定义规范分类时,应该已收集完成。
第二步,框架布局:提取共性,搭建框架和布局,明确页面大的区域划分和结构。(TDesign布局详细指南)
第三步,功能分区:基于框架布局,细化区域内具体的业务功能属性,如:导航区、操作区等。这部分是页面框架内最接地气最具指导性的内容,同时也是最难定义的。主要原因如下:
– 定义太细,担心缺乏前瞻性限制后续设计:定义越细灵活度就低,后续改动和限制性就越高。为避免这种问题,推荐在定义关键页面时,按输出设计稿的思路:整理「信息架构」→定义「功能分区」,这样后续拓展性和前瞻性更高
– 定义太粗,无法定义出明确的功能分区,担心缺乏实际指导意义:同一区域有些页面展示操作,有些展示导航。从规范角度好像不应该,但实际套在各个业务内却又合理。当遇到这种无法达成一致的情况时,建议就不定义具体的“功能分区”,避免因为盲目追求统一而限制实际设计。而可以采用“穷举举例”的方式,将该布局下可承载的内容均展示出来,既可以起到参考意义,又能供后续沿用达到统一的效果。
第四步,加入案例:将刚刚定义的布局框架与功能分区,与实际案例完整结合,便于后续理解和沿用。

3.5.3 通用流程

目标:梳理整站所有流程,对那些可复用的流程进行整理、抽象、封装。让后续设计师和研发能够直接沿用。
“可复用的流程”是指:在多个场景下,不改变其原有业务逻辑的情况下能够“既插既用”。例如:登录注册流程、扫码关注流程、分享流程等等。往往一个通用流程中,不同的步骤亦可以打散,重新拼装成不同的流程,以适配具体的场景使用。
下面就举一个具体的例子:注册流程。一般完整的注册流程如下,通过不同的入口触发后进入,通过一定步骤后注册成功。
当业务有了进一步需求,需要通过插件快捷登录时,步骤便可以重新组合,再适配具体的场景。
对于设计师要做的,就是识别具体的通用流程有哪些,并将其给「步骤化」串联起来。当有新的需求来的时候,判断能直接复用,还是需要重新组装,亦或是新增步骤。
而这样拼装的思维,恰好对应了研发搭建流程时的思路。通用流程对于他们就是将不同的步骤进行组合起来。当遇到不同场景时,再以搭积木的方式进行拼装。
而具体的搭建步骤也是由两个步骤组成:1.第一步,收集流程;2.第二步,抽象步骤。具体方式上面已提到,就不过多赘述。

3.5.4 标准组件

目标:将产品内使用过的组件整理成“标准组件”,统一定义规则,让后续设计和研发时能直接调取组件,提高设计和研发效率。
其实行业中已经有很多通用组件,可以快速调用。但由于不同业务的复杂度不一样,也会生成自己独特的业务定制组件。同时,产品持续在迭代,也很难能抽出时间单独定义组件。故基于这个背景,结合“需求设计流程”和“组件整理流程”,有两种高效定义标准组件的方式。
方式一:调用行业通用组件
第一步,业务设计确定基本逻辑。
第二步,挑选行业通用组件,增加业务规则。(一般开发在搭建产品初期时,便会选择一家行业组件进行使用,而组件也仅能在这家提供的组件中挑选)
第三步,视觉根据全局视觉原则,设计新的样式。
第四步,将交互规则、视觉样式合并,统一成标准组件。基础规则直接引用行业组件已定义的内容,场景规则按需补充。
方式二:业务定制组件
第一步,进行正常的业务设计。交互根据需求搭建原型,视觉设计具体样式。
第二步,判断组件是否通用,是否可复用到其它场景。例如:分享对话框,不同的内容分享都能够用得到,像这种就是可抽象成标准组件的典型案例。
第三步,定义标准组件规范。简单的组件展示具体样式即可,团队内设计师基本认知一致,无需重新学习。而复杂的组件为保证后续的正确复用,建议包括以下内容:
– 更新日志:因为组件是变动最多的规范,需要明确具体的版本和改动点
– 组件定义:简要介绍用途和使用规则,如对话框定义:必须是用户主动触发时才出现、主要使用在二次确认场景需用户确认后才消失等。
– 组件结构:介绍组件构成、功能分区、分区定义,详细展示不同分区内具体信息和对应规则。 
– 使用场景:详细区分多种场景下不同的使用方式,明确给予使用指导
– 设计方案:备选,如果比较复杂的组件且涉及到流程中的关键环节,建议可以考虑复制一个完整的设计方案嵌入其中,便于团队成员理解沿用。
第四步,跟研发沟通,封装成标准组件。这一步是非常关键也是重要的一步,这将大大提高我们后续的组件复用率,降低重复性走查的耗时。推荐使用CoDesign-设计规范功能,上传「组件库」后能够按目录自动生成规范文档,同时将自动标注和切图,大大提高研发开发标准组件的效率。

3.5.5 文案规范

目标:将产品内各个场景内文案进行整理,帮助业务更准确表达意图,让设计师更好沿用,同时让用户感受到一致的产品风格。
文案就像“产品对用户说的话”,不同的人说话方式可能并不一样,没有绝对的对错。但清晰明了的语言表述,让用户更容易理解;符合产品气质的语气,能拉近产品与用户的距离;统一的文案描述,又能让用户在整站一致的语境下体验产品。
需要定义的内容,包括但不限于以下3个部分:
1.语言:语言是指我们通过什么样的规则来组合文字,让它形成一种惯用的表达方式。例如语句简洁明了,不过度修饰,避免重复描述,使用简洁清晰的语序,帮助用户快速理解;例如用词精准易懂,使用简单、易于用户理解的词汇,避免使用专业术语,或过于口语化的表述。单纯说规则可能太虚了,在实际定义规范时,还要如下图所示,加上实际案例示意避免误解。
2.语气:语气是可以体现产品气质和风格,定义时要结合全局原则内的设计价值观,明确产品性格后才能更好的定义出符合产品的语气风格。同一种语境下不同风格的文案就有明显差异。如网络异常时:
• 俏皮的文案可能是:网络开小差,请稍等一下
• 而正经的文案可能是:网络异常,稍后重试。
3.书写规则:主要包括常用词汇的书写方式,例如「日期简写方式」「英文大小写方式」「使用全角标点符号」等。以及易错的词汇短语示意,例如「账号还是帐号」、「登陆还是登录」等。这是团队设计师最容易沿用遵循的,也是接地气的部分。 
4.具体使用指南:以上「语言」「语气」「书写规则」3个部分,是构成全局文案的基础规范。如果有充足时间的团队,可以考虑再结合实际业务,分别定义不同场景和组件下具体的使用指南。如下图: 
最后再附上各个行业内定义文案规范例子,供大家参考:
B端产品文案指南:
https://www.yuque.com/linyecx/dragon/occ7pr#UEUSw
AntDesign 文案规范:
https://ant.design/docs/spec/copywriting-cn
Clarity Design 文案规范:
https://design.teambition.com/doc/introduction
国家标点符号用法:
http://www.moe.gov.cn/ewebeditor/uploadfile/2015/01/13/20150113091548267.pdf

4.如何「推进」交互规范

定义完交互规范,后续将考虑如何将其顺利的推进落地。本文罗列几个推进时重点需要注意的事项。

 

4.1 团队评审,达成一致

规范的定义不是一个人的事情,而是一个团队事情,它将关系到每个后续每个人的设计产出。所以在制定规范期间,应该定期在团队中进行设计评审。这不仅是评审设计好坏的过程,更是让团队达成一致、大家更深入了解如何使用规范的过程。
注意,参与评审的人不止是设计师,当然也包括具体的业务开发,很多时候我们会得到新的思路和启发。
 

4.2 善用工具,沉淀规范

规范搭建的过程中,有很多痛点:组件库需要多人参与维护和创建,容易造成冲突内容丢失;同时沉淀规范文档时,需要图片逐一复制、粘贴到文档内,更新时又要重复一遍这样的操作。而这些问题,使用CoDesign设计规范功能,就可以有效的解决提高效率。
首先组件库支持多人同时维护,差量更新;其次组件库上传后,可以自动生成/更新规范文档,避免反复编写文档,整体提效;最后当组件库有新版本时,会自动提醒团队内其他成员进行更新,保障团队设计一致性。

4.3 运用规范,指导设计

搭建规范的过程其实也是整体设计走查的过程,我们会发现有些设计可能有体验问题,或不符合规范。每当这个时候,我们就需要对这些设计进行标记。在规范定义完成之后,迭代排期优化线上的设计。
而在实际设计使用过程中,可能又会发现规范无法满足的地方,此时又可以展开新一轮的提炼和总结,再反哺规范,形成正向循环促使设计和规范不断完善。

5.写在最后

在前言的时候就有提到「交互规范」只是整体规范中的一部分,最终是需要与视觉合并成一份统一的设计规范,指导后续具体的设计。具体的合并方式,在定义的章节内已有提到,就不再赘述。
最后,我一直认为好的设计规范是提高设计效率,引导设计方向,而不是因为设计规范而局限了具体业务的设计,如果这样,还不如不去定义。