一 、如何「理解」交互规范
说起设计规范，货超互规大家应该都不陌生 ，详细一个成熟的全定设计规范对 产品设计 、研发开发 、局交用户使用 都有着重要的范制指导作用 ：
产品设计 ：保障产品内不同模块的设计一致性，同时提高不同设计师间的腾讯设计、协作效率
研发开发 ：通过定义的字干标准规范 ，提高流程 、货超互规组件的详细复用率 ，提高整体开发效率
用户使用 ：让用户能够在产品全局感受到统一且完整的全定体验 ，降低使用成本和学习难度
而一个完整的设计规范一般分成「视觉」「交互」两个部分合并组成 ，在全局原则的腾讯指导下 ，侧重不同的维度和内容分别展开规范的定义 ，最后再合到一起形成一份完整的设计规范 。
从用户体验要素来看 ，视觉主要是在「表现层」「框架层」进行规范的统一 ，主要包括 ：形 、色、字 、构 、质 、动 六个层面 。
而交互角度相对抽象 ，主要针对于产品的「结构层」「框架层」入手 ，定义统一的交互规范 ，指导页面 、流程搭建和组件使用规则 。包括 ：全局原则 、页面布局 、通用流程 、标准组件 、文案规范 。
整体维度呈"从抽象到具体的总分关系" ，不仅对产品的各个维度都有具体的交互指导 ，而且不仅能保证长期使用 ，避免重复返工；同时也便于囊括后续的迭代内容 。而这些内容 ，就是我们通常定义的交互规范 ，也是交互参与定义设计规范的发力点 。
有了对于基本认识和搭建框架之后 ，我们来详细聊聊如何定义交互规范具体内容。
二、不同阶段应该定义哪些交互规范 ？
产品有不同发展阶段 ，设计规范同样也有 ，不同阶段下的产品目标和规范需要覆盖的内容都不尽相同。我们要既要避免做多 ，保证投入产出比最大化；同时也要构建一个合理的规范迭代思路。
产品探索初期 ：
该阶段的产品核心目标是「验证产品或商业模型」，业务需求都是小步快跑、频繁迭代。产品处于从 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体验设计
