一 、如何「理解」交互规范
说起设计规范 ，货超互规大家应该都不陌生 ，详细一个成熟的全定设计规范对 产品设计 、研发开发 、局交用户使用 都有着重要的范制指导作用 ：
产品设计 ：保障产品内不同模块的设计一致性，同时提高不同设计师间的腾讯设计 、协作效率
研发开发 ：通过定义的字干标准规范 ，提高流程 、货超互规组件的详细复用率，提高整体开发效率
用户使用 ：让用户能够在产品全局感受到统一且完整的全定体验 ，降低使用成本和学习难度
而一个完整的设计规范一般分成「视觉」「交互」两个部分合并组成 ，在全局原则的腾讯指导下 ，侧重不同的维度和内容分别展开规范的定义 ，最后再合到一起形成一份完整的设计规范。
从用户体验要素来看 ，视觉主要是在「表现层」「框架层」进行规范的统一 ，主要包括 ：形 、色、字 、构 、质 、动 六个层面。
而交互角度相对抽象，主要针对于产品的「结构层」「框架层」入手 ，定义统一的交互规范 ，指导页面 、流程搭建和组件使用规则 。包括 ：全局原则、页面布局、通用流程 、标准组件 、文案规范 。
整体维度呈"从抽象到具体的总分关系" ，不仅对产品的各个维度都有具体的交互指导 ，而且不仅能保证长期使用 ，避免重复返工；同时也便于囊括后续的迭代内容 。而这些内容 ，就是我们通常定义的交互规范 ，也是交互参与定义设计规范的发力点 。
有了对于基本认识和搭建框架之后 ，我们来详细聊聊如何定义交互规范具体内容 。
二 、不同阶段应该定义哪些交互规范 ？
产品有不同发展阶段 ，设计规范同样也有，不同阶段下的产品目标和规范需要覆盖的内容都不尽相同 。我们要既要避免做多 ，保证投入产出比最大化；同时也要构建一个合理的规范迭代思路。
产品探索初期 ：
该阶段的产品核心目标是「验证产品或商业模型」 ，业务需求都是小步快跑 、频繁迭代 。产品处于从 0 到 1 的野蛮生长状态 ，存在着"先满足功能，再优化体验"的情况 ，导致该阶段的产品体验往往不太过关 。
搭建目的：通过定义原则，梳理关键页面和流程 ，搭建基本的规范框架。既让团队对产品有统一的设计价值观和认知判断；从页面到流程 ，又能对应设计参照标准；同时业务可以在规定的框架下发展 ，不仅让产品体验的根基牢固 ，而且不会限制功能设计自由 。
搭建范围：「全局原则」「页面布局」「通用流程」
产品稳定发展期 ：
该阶段的产品基本形态已稳定 ，也形成了初步的模型结构 。后续迭代是在现有结构的基础上 ，进行增加或优化功能。虽然探索期定义了产品原则 、布局和流程 ，但探索期产品的自由生长 ，会导致不少设计细节不一致，从而影响了产品整体的体验和效率。
搭建目的 ：通过回溯整理过往设计 ，沉淀优化成完整的交互规范 。再根据规范统一产品体验，进一步优化流程和效率 ， 让整个产品体验达到相对稳定的状态 。
搭建范围 ：「全局原则」「页面布局」「通用流程」「标准组件」「文案规范」
三 、如何「定义」交互规范
1. 定义交互规范的原则
与行业通用的设计规范（如 TDesign 、AntDesign）"大而全""通用"的特质不同，一般团队内构建的设计规范都是源于某一个产品或业务 ，主要的特点是"专精" 。专注于「业务」本身 ，主要是「团队内成员使用」 ，追求的是投入产出比最大化。
基于此背景 ，当我们在定义「交互规范」时，有三点原则 ：
原则一 ：保持规范的业务性。设计规范既要贴合业务场景归纳完整，同时又要避免凭空定义脱离实际。故我们定义时要代入业务规划 ，尽量富有前瞻性 ，这样定义的规范不仅能覆盖当前需要 ，同时后续也能更好地迭代 。
原则二 ：保持规范的专注性。有的放矢，明确内容优先级 ，避免盲目追求大而全和形式主义 。对于优先级高（覆盖面广 、复用率高）的关键内容重点描述；优先级低（逻辑简单 、认知一致）的内容可简要描述 ，避免事无巨细降低效率。
原则三 ：保持规范的生长性 。设计规范不是一成不变 ，而是跟随业务发展不断迭代完善的，所以需要阶段性的回顾规范 。遇到规范未能覆盖或无法指导设计的地方，及时修订同步团队 ，避免墨守成规 ，固步自封 。
最后 ，还有一点建议 ：在定义规范时，可以站在前人肩膀 ，适度参考行业设计规范 ，能复用用的直接参考 ，具有业务特性的再集合业务综合考虑 ，使整个规范制定效率更高 ，科学性 、指导性更强 。
在找到自己当前所属的产品阶段、明确要建立哪些设计规范后 ，具体应该如何进行落地执行呢 ？建议从以下 4 个步骤入手 。
2. 第一步 ：定义规范分类
如上文中提到 ，一个完整的交互规范分为 ：「全局原则」「页面布局」「通用流程」「标准组件」「文案规范」五个维度 ，但每个维度具体含有哪些内容 ，都是不一样的 。仍然需要根据实际业务需要去定义 ，这样才能尽量保证没有遗漏 ，也更好为下一环节评估工作量 。
通用的做法有两种 ：
方式一 ：整理业务场景下不同的页面、流程等 ，并进行抽象合并 。「全局原则」「页面框架」和「通用流程」具有强业务导向 ，可以采用此方式 。
以「页面布局」为例，就需要将关键页面按统一颗粒度收集（按层级或按场景等） 。
方式二：参考行业通用规范的定义，先罗列完整 ，再根据产品实际业务需要进行增删改 。
「标准组件」「文案规范」已经在行业内有了不少科学的目录和沉淀 ，可以采用此方式 ，例如下图组件的梳理 。
最后可产出如下图的规范分类和具体内容 。（可以列的不是很全 ，后续补充具体部分内容时持续维护这张表 。）
3. 第二步 ：确定分工排期
有了具体内容作为依据 ，便可以根据此进行排期分工 。
分工原则 ：推荐按规范分类进行分工 ，一个大的分类由一人负责，保证专注性。同时团队交互最好都能参与，保证后续对规范更好的沿用。
排期原则 ：「定义规范」和「输出需求」两者经常要并行处理 ，此时提高效率 ，控制投入产出比就很重要了，我们需要明确优先级 ，先做什么后做什么。有 3 个思路可以综合参考 ：
- 并行的思路 ：在定义完「全局原则」后 ，剩下的页面 、流程 、组件 、文案都可考虑并行定义 ，彼此之间没有明确的依赖项 。
- 迭代的思路：近期有迭代的版本 ，如 ：即将改版的模块、反馈较多体验较差的模块 ，其中涉及到的页面框架、组件可优先定义 。
- 复用的思路 ：某些典型页面 、典型流程、典型组件涉及面广 ，许多需求的设计都将借鉴参考 ，亦可优先抽象定义 。
4. 第三步 ：统一撰写原则
设计规范是由不同的设计师一起合作完成 ，所以我们尽量在一开始 ，就需要统一规范的撰写和展现形式 。以此提高后续合并的效率 ，同时又能保证其阅读体验 ，让其它使用者能够更好遵循 。对此，我们定义了几个关键原则：
目录完整：高效检索 ，快速让使用者找到需要的内容 。
原则清晰 ：抽象的内容往往含有许多概念和原则 ，需要让使用者先理解再参考 ，才能保证后续使用正确 、举一反三
多图少字 ：没有人喜欢看字，图片更容易吸收
搭配案例 ：让使用者更好的代入场景 ，理解和使用规范 。
5. 第四步 ：定义具体规范 ★
前面铺垫了许多流程性的内容 ，就像我们日常输出设计需求一样，大家或多或少在工作中都有遇到过 。接下来 ，将重点聊聊 ，我们具体的内容应该如何定义 。依然分成 5 个环节一一讲解 。
① 全局原则
目标 ：明确影响整站各个模块 、各个页面设计的原则和规范，指导我们后续各种规范的定义和设计 。
而全局原则也分两种 ，设计原则和业务原则两种 。
设计原则 ：每个完整的设计规范都需要包含的内容 ，如 ：设计价值观、设计准则。看似相对务虚的东西 ，实则影响后续整个设计方向 。这个部分需要和产品经理 、视觉同学结合产品的定位和发展共同提炼。具体定义方式可参考 ：
你为什么需要设计原则 ？https://zhuanlan.zhihu.com/p/246430795
业务原则 ：源自实际业务本身产生的问题 ，行业内没有标准定义 。需要具体问题具体分析 ，推导出具体目标 ，最后再统一制定规范解决业务问题 。
举一个实际的例子便于理解 ：全局 Z 轴定义
明确问题：整站层级高度没有统一定义 ，导致不同控件间相互遮挡 ，没有统一规则 。需要定义全局 Z 轴规范 ，统一不同场景 、页面 、组件的高度。
梳理借鉴 ：统一梳理相关场景、页面 、组件 ，明确需要定义的范围 。再查找行业规范，有无参考借鉴。（如 Z 轴定义 ，可参考 Material Design）
定义规范 ：最后通过最具代表性的场景进行展示
全局原则没有维度高低之分，例如可能全局涉及到的「右键菜单」也能被定义成全局原则 。不必盲从行业交互规范内庞大且抽象的原则 。只要能够实际解决你业务的需要，能够覆盖整站各个部分 ，都可以纳为全局原则 。
② 页面框架
目标 ：梳理整站所有关键页面 ，整理抽象成相对固定的 框架布局&功能分区 让后续设计新页面时能遵循规律 、找到参考 。
页面框架的搭建一般由四个步骤组成 ：
第一步 ，收集页面：根据早期定义的规范分类 ，收集展示所有相同层级的页面 。这些在定义规范分类时 ，应该已收集完成。
第二步 ，框架布局 ：提取共性 ，搭建框架和布局 ，明确页面大的区域划分和结构 。（TDesign 布局详细指南）
第三步 ，功能分区 ：基于框架布局 ，细化区域内具体的业务功能属性 ，如 ：导航区 、操作区等。这部分是页面框架内最接地气最具指导性的内容 ，同时也是最难定义的 。主要原因如下 ：
定义太细 ，担心缺乏前瞻性限制后续设计：定义越细灵活度就低 ，后续改动和限制性就越高 。为避免这种问题 ，推荐在定义关键页面时 ，按输出设计稿的思路 ：整理「信息架构」→定义「功能分区」，这样后续拓展性和前瞻性更高
定义太粗，无法定义出明确的功能分区 ，担心缺乏实际指导意义 ：同一区域有些页面展示操作 ，有些展示导航 。从规范角度好像不应该 ，但实际套在各个业务内却又合理 。当遇到这种无法达成一致的情况时 ，建议就不定义具体的"功能分区"，避免因为盲目追求统一而限制实际设计 。而可以采用"穷举举例"的方式 ，将该布局下可承载的内容均展示出来 ，既可以起到参考意义，又能供后续沿用达到统一的效果。
第四步 ，加入案例 ：将刚刚定义的布局框架与功能分区 ，与实际案例完整结合 ，便于后续理解和沿用。
③ 通用流程
目标 ：梳理整站所有流程 ，对那些可复用的流程进行整理、抽象、封装 。让后续设计师和研发能够直接沿用 。
"可复用的流程"是指 ：在多个场景下 ，不改变其原有业务逻辑的情况下能够"既插既用"。例如：登录注册流程、扫码关注流程 、分享流程等等 。往往一个通用流程中 ，不同的步骤亦可以打散 ，重新拼装成不同的流程 ，以适配具体的场景使用 。
下面就举一个具体的例子 ：注册流程。一般完整的注册流程如下，通过不同的入口触发后进入 ，通过一定步骤后注册成功 。
当业务有了进一步需求 ，需要通过插件快捷登录时，步骤便可以重新组合 ，再适配具体的场景。
对于设计师要做的 ，就是识别具体的通用流程有哪些 ，并将其给「步骤化」串联起来 。当有新的需求来的时候 ，判断能直接复用 ，还是需要重新组装 ，亦或是新增步骤 。
而这样拼装的思维，恰好对应了研发搭建流程时的思路 。通用流程对于他们就是将不同的步骤进行组合起来。当遇到不同场景时 ，再以搭积木的方式进行拼装 。
而具体的搭建步骤也是由两个步骤组成：1.第一步 ，收集流程；2.第二步 ，抽象步骤。具体方式上面已提到，就不过多赘述 。
④ 标准组件
目标 ：将产品内使用过的组件整理成"标准组件" ，统一定义规则，让后续设计和研发时能直接调取组件，提高设计和研发效率。
其实行业中已经有很多通用组件，可以快速调用 。但由于不同业务的复杂度不一样，也会生成自己独特的业务定制组件 。同时，产品持续在迭代 ，也很难能抽出时间单独定义组件。故基于这个背景 ，结合"需求设计流程"和"组件整理流程" ，有两种高效定义标准组件的方式 。
方式一 ：调用行业通用组件
第一步 ，业务设计确定基本逻辑 。
第二步 ，挑选行业通用组件 ，增加业务规则 。（一般开发在搭建产品初期时 ，便会选择一家行业组件进行使用 ，而组件也仅能在这家提供的组件中挑选）
第三步 ，视觉根据全局视觉原则 ，设计新的样式 。
第四步 ，将交互规则 、视觉样式合并 ，统一成标准组件 。基础规则直接引用行业组件已定义的内容 ，场景规则按需补充 。
方式二 ：业务定制组件
第一步 ，进行正常的业务设计 。交互根据需求搭建原型 ，视觉设计具体样式 。
第二步 ，判断组件是否通用 ，是否可复用到其它场景。例如 ：分享对话框，不同的内容分享都能够用得到 ，像这种就是可抽象成标准组件的典型案例 。
第三步，定义标准组件规范。简单的组件展示具体样式即可 ，团队内设计师基本认知一致 ，无需重新学习 。而复杂的组件为保证后续的正确复用 ，建议包括以下内容 ：
1）更新日志 ：因为组件是变动最多的规范 ，需要明确具体的版本和改动点
2）组件定义 ：简要介绍用途和使用规则，如对话框定义 ：必须是用户主动触发时才出现 、主要使用在二次确认场景需用户确认后才消失等 。
3）组件结构 ：介绍组件构成 、功能分区 、分区定义 ，详细展示不同分区内具体信息和对应规则 。
4）使用场景：详细区分多种场景下不同的使用方式 ，明确给予使用指导
5）设计方案 ：备选 ，如果比较复杂的组件且涉及到流程中的关键环节，建议可以考虑复制一个完整的设计方案嵌入其中，便于团队成员理解沿用 。
第四步 ，跟研发沟通 ，封装成标准组件 。这一步是非常关键也是重要的一步 ，这将大大提高我们后续的组件复用率 ，降低重复性走查的耗时。推荐使用 CoDesign-设计规范功能点击体验 CoDesign 小程序 ，上传「组件库」后能够按目录自动生成规范文档 ，同时将自动标注和切图 ，大大提高研发开发标准组件的效率。
⑤ 文案规范
目标 ：将产品内各个场景内文案进行整理，帮助业务更准确表达意图 ，让设计师更好沿用 ，同时让用户感受到一致的产品风格。
文案就像"产品对用户说的话" ，不同的人说话方式可能并不一样 ，没有绝对的对错。但清晰明了的语言表述 ，让用户更容易理解；符合产品气质的语气 ，能拉近产品与用户的距离；统一的文案描述，又能让用户在整站一致的语境下体验产品 。
需要定义的内容 ，包括但不限于以下 3 个部分 ：
语言 ：语言是指我们通过什么样的规则来组合文字，让它形成一种惯用的表达方式 。例如语句简洁明了，不过度修饰 ，避免重复描述 ，使用简洁清晰的语序，帮助用户快速理解；例如用词精准易懂 ，使用简单 、易于用户理解的词汇 ，避免使用专业术语 ，或过于口语化的表述。单纯说规则可能太虚了，在实际定义规范时 ，还要如下图所示 ，加上实际案例示意避免误解。
语气 ：语气是可以体现产品气质和风格 ，定义时要结合全局原则内的设计价值观 ，明确产品性格后才能更好的定义出符合产品的语气风格 。同一种语境下不同风格的文案就有明显差异。如网络异常时 ：
- 俏皮的文案可能是 ：网络开小差，请稍等一下
- 而正经的文案可能是 ：网络异常 ，稍后重试 。
书写规则 ：主要包括常用词汇的书写方式 ，例如「日期简写方式」「英文大小写方式」「使用全角标点符号」等 。以及易错的词汇短语示意，例如「账号还是帐号」 、「登陆还是登录」等 。这是团队设计师最容易沿用遵循的，也是接地气的部分 。
具体使用指南：以上「语言」「语气」「书写规则」3 个部分，是构成全局文案的基础规范 。如果有充足时间的团队 ，可以考虑再结合实际业务，分别定义不同场景和组件下具体的使用指南。如下图 ：
最后再附上各个行业内定义文案规范例子，供大家参考 ：
- B 端产品文案指南 ：https://www.yuque.com/linyecx/dragon
- AntDesign 文案规范 ：https://ant.design/docs/spec/copywriting-cn
- Clarity Design 文案规范 ：https://design.teambition.com/doc/introduction
- 国家标点符号用法 ：http://www.moe.gov.cn/ewebeditor
四 、如何「推进」交互规范
定义完交互规范 ，后续将考虑如何将其顺利的推进落地 。本文罗列几个推进时重点需要注意的事项。
1. 团队评审 ，达成一致
规范的定义不是一个人的事情 ，而是一个团队事情 ，它将关系到每个后续每个人的设计产出 。所以在制定规范期间 ，应该定期在团队中进行设计评审 。这不仅是评审设计好坏的过程 ，更是让团队达成一致 、大家更深入了解如何使用规范的过程 。
注意 ，参与评审的人不止是设计师 ，当然也包括具体的业务开发 ，很多时候我们会得到新的思路和启发 。
2. 善用工具 ，沉淀规范
规范搭建的过程中，有很多痛点 ：组件库需要多人参与维护和创建 ，容易造成冲突内容丢失；同时沉淀规范文档时，需要图片逐一复制 、粘贴到文档内，更新时又要重复一遍这样的操作 。而这些问题 ，使用 CoDesign 设计规范功能 ，就可以有效的解决提高效率。
首先组件库支持多人同时维护 ，差量更新；其次组件库上传后 ，可以自动生成/更新规范文档 ，避免反复编写文档 ，整体提效；最后当组件库有新版本时 ，会自动提醒团队内其他成员进行更新 ，保障团队设计一致性 。
3. 运用规范 ，指导设计
搭建规范的过程其实也是整体设计走查的过程 ，我们会发现有些设计可能有体验问题 ，或不符合规范 。每当这个时候 ，我们就需要对这些设计进行标记 。在规范定义完成之后 ，迭代排期优化线上的设计 。
而在实际设计使用过程中 ，可能又会发现规范无法满足的地方，此时又可以展开新一轮的提炼和总结 ，再反哺规范 ，形成正向循环促使设计和规范不断完善 。
五 、写在最后
在前言的时候就有提到「交互规范」只是整体规范中的一部分，最终是需要与视觉合并成一份统一的设计规范 ，指导后续具体的设计 。具体的合并方式 ，在定义的章节内已有提到 ，就不再赘述 。
最后 ，我一直认为好的设计规范是提高设计效率 ，引导设计方向 ，而不是因为设计规范而局限了具体业务的设计 ，如果这样 ，还不如不去定义 。
作者：腾讯CDC体验设计
