e库网女装网店代理(全局交互规范制定指南)

和阳光一起灿烂

2022-04-20 02:20:38

我浏览了很多关于“设计规范”的文章，发现很多都是针对一般的流程和愿景安排的，关于交互的内容却很少。基于此，笔者结合近期项目中沉淀的实际案例，并参考行业内众多常见的设计规范，总结出构建交互规范的流程、框架和要点。希望能帮助你更好的沉淀交互规范。

一、如何「理解」交互规范

说起设计规范，大家应该都不陌生。一个成熟的设计规范在产品设计、R&D和用户使用中起着重要的指导作用:

产品设计:保证产品中不同模块的设计一致性，同时提高不同设计师之间的设计和协作效率。

R&D:通过定义的标准和规范，提高流程和组件的复用率，提高整体开发效率。

用户:让用户在产品整体情况下感受到统一完整的体验，降低使用成本和学习难度。

一个完整的设计规范通常分为“视觉”和“交互”两部分。在总体原则的指导下，强调不同的维度和内容来分别定义规范，最终共同形成一个完整的设计规范。

从用户体验要素来看，视觉主要在“表现层”和“框架层”进行规范统一，主要包括形状、色彩、人物、结构、质量、运动六个层次。

而交互角度相对抽象，主要针对产品的“结构层”和“框架层”，定义统一的交互规范，指导页面、流程构建和组件使用的规则。包括:全局原理、页面布局、一般流程、标准组件、文案规范。

整体维度是“从抽象到具体的总分关系”，既能为产品的各个维度提供具体的交互指导，又能保证长期使用，避免重复返工；同时也方便覆盖后续迭代内容。这些内容就是我们通常定义的交互规范，也是交互参与定义设计规范的发力点。

有了基本的了解和框架，下面就来详细说说如何定义交互规范的具体内容。

二、不同阶段应该定义哪些交互规范？

产品有不同的发展阶段，设计规范也是如此。不同阶段的产品目标和规格需要涵盖不同的内容。既要避免做多，又要最大化投入产出比；同时也要构建规范迭代的合理思路。

产品探索的初始阶段:

在这个阶段，产品的核心目标是“验证产品或商业模式”，业务需求是小步快跑，频繁迭代。产品处于从0到1的野蛮生长状态，存在“先满足功能，再优化体验”的情况，导致这个阶段的产品体验往往会失败。

目的:通过定义原则，梳理关键页面和流程，构建基本规范框架。让团队对产品有统一的设计价值和认知判断；从页面到流程，也可以对应设计参考标准；同时业务可以在指定的框架内发展，既让产品体验的基础牢固，又不限制功能设计的自由度。

建设范围:全球政策、页面布局和通用流程

稳定的产品开发期:

在这个阶段，产品的基本形态已经稳定，初步的模型结构已经形成。后续迭代是在现有结构的基础上增加或优化功能。虽然在探索期明确了产品的原理、布局和流程，但是产品在探索期的自由成长会导致设计细节不一致，从而影响产品的整体体验和效率。

目的:通过对以往设计的回顾性整理，沉淀优化成完整的交互规范。然后按照规范统一产品体验，进一步优化流程和效率，让整个产品体验达到一个相对稳定的状态。

构建范围:全球政策、页面布局、一般流程、标准组件和文档规范。

三、如何「定义」交互规范

1.定义交互规范的原则。

与行业内通用设计规范(如TDesign、AntDesign)的“大而全”、“通用”的特点不同，通用团队构建的设计规范都是来源于某个产品或业务，主要特点是“专业化”。专注于“业务”本身，主要是“团队成员使用”，追求投入产出比的最大化。

基于这一背景，我们在定义“交互规范”时有三个原则:

原则一:维护标准化业务。设计规范既要符合业务场景，又要避免空定义脱离实际。所以我们在定义的时候，要把它代入到商业计划书中，尽量做到前瞻性，这样定义的规范既能覆盖当前的需求，也能更好的进行后期迭代。

原则二:保持规范的重点。有的放矢，明确内容轻重缓急，避免盲目追求大、全和形式主义。重点描述高优先级的关键内容(覆盖面广，复用率高)；低优先级(逻辑简单，认知一致)的内容可以简单描述，避免因琐事降低效率。

原则三:保持规范增长。设计规范不是一成不变的，而是随着业务的发展不断迭代完善的，所以需要定期评审规范。在规范没有覆盖或指导设计的地方，及时修改同步团队，以避免墨守成规和自满。

最后还有一个建议:在定义规范时，可以站在前人的肩膀上，适度参考工业设计规范，参考可复用的直接引用，结合业务特点进行业务整合，使整个规范更加高效、科学、具有指导性。

在找到你目前所属的产品阶段，明确了你要建立的设计规范之后，你应该如何在地面上实现？建议从以下四个步骤入手。

2.步骤1:定义标准分类。

如上所述，一个完整的交互规范可以分为五个维度:全局原则、页面布局、通用流程、标准组件、文案规范。但是，每个维度的具体内容是不一样的。还是要根据实际的业务需求来定义，这样才能保证尽量没有遗漏，才能更好的为下一个环节评估工作量。

有两种常规做法:

方法一:组织不同的页面、流程等。在业务场景中，并抽象和合并它们。全局策略、页面框架和通用流程具有很强的业务导向性，可以采用这种方法。

以“页面布局”为例，需要按统一粒度(按级别或场景等)收集关键页面。).

模式二:参考通用行业规范的定义，先完整列出，再根据产品实际业务需求进行增删改。

“标准组件”和“文案规范”在业内已经有了很多科学的目录和沉淀，可以采用这种方法，比如梳理下图中的组件。

最后可以产生下图的规格分类和具体内容。(能列出的列表不是很全，后面添加具体部分时会持续维护这个表。)

3.第二步:确定分工时间表。

有了具体的内容作为依据，我们就可以据此安排分工了。

分工原则:建议按照标准分类分工，大分类一人负责，保证集中。同时，最好参与团队互动，这样才能保证后续更好的使用规范。

调度原理:“定义规范”和“产出需求”往往需要并行处理。这时候提高效率，控制投入产出比就很重要了。我们需要明确轻重缓急，先做好该做的事情。有三个思路可以综合参考:

并行思维:定义了“全局原则”后，剩下的页面、流程、组件、文档都可以并行定义，它们之间没有明确的依赖关系。

迭代思路:近期有迭代版本，比如要修改的模块和反馈较多、体验较差的模块。可以首先定义所涉及的页面框架和组件。

重用思想:一些典型的页面、流程和组件涵盖的范围很广。很多需求会设计参考，抽象定义可以优先考虑。

4.第三步:统一写作原则。

设计规格说明书是由不同的设计师共同完成的，所以我们需要在一开始就尽可能统一规格说明书的书写和呈现形式。这样可以提高后续合并的效率，同时保证阅读体验，让其他用户更好的跟随。在这方面，我们定义了几个关键原则:

完整目录:高效检索，让用户快速找到所需内容。

原理:抽象的内容往往包含很多概念和原理，需要用户在参考前理解，以保证正确使用和举一反三。

多图少字:没有人喜欢看文字，图片更容易吸收。

搭配案例:让用户更好的代入场景，理解和使用规范。

5.步骤4:定义具体的规范★

前面铺了很多程序化的内容，就像我们日常的输出设计需求，在工作中或多或少都遇到过。接下来，我们将重点讨论如何定义我们的具体内容。还是分五个环节来一一讲解。

(1)全局原则

目的:明确影响全站各模块和页面设计的原则和规范，指导后续规范的定义和设计。

有两个全局原则:设计原则和业务原则。设计原则:每一个完整的设计规范都需要包括内容，如设计值和设计标准。看似相对撤退的东西，实际上影响了整个后续的设计方向。这部分需要结合产品定位和开发，和产品经理、视觉同学一起细化。具体定义可以参考:

为什么需要设计原则？

https://zhuanlan.zhihu.com/p/246430795

业务原理:来源于实际业务本身引起的问题，业内没有标准定义。具体问题需要具体分析，导出具体目标，最后制定统一的规范来解决业务问题。

举一个实际的例子便于理解:全局Z轴定义

明确问题:全站水准高度没有统一的定义，导致不同控制之间相互遮挡，没有统一的规则。需要定义全局的Z轴规范，统一不同场景、页面、组件的高度。

借鉴:统一梳理相关场景、页面、组件，定义要定义的范围。再找找行业规范，看看有没有参考。(关于Z轴的定义，请参考材料设计)

定义:最后通过最有代表性的场景来展现。

全球原则之间没有维度差异。比如可能涉及全局原则的右键菜单，也可以定义为全局原则。你不必盲目遵循行业交互规范中庞大而抽象的原则。只要能切实解决你的业务需求，覆盖全站各个部分，就可以作为总体原则接受。

(2)页面框架

目的:将全站所有关键页面梳理出来，整理抽象成一个相对固定的框架布局&功能分区使新页面的后续设计有章可循，有据可查。

页面框架的构建通常包括四个步骤:

第一步，收集页面:根据早期定义的标准分类，收集并显示同一级别的所有页面。这些应该在定义规范分类时就已经收集了。

第二步，框架布局:提取共性，构建框架和布局，定义页面大区域的划分和结构。(t设计布局详细指南)

第三步，功能划分:基于框架布局，细化区域内的具体业务功能属性，如导航区、操作区等。这部分是页面框架中最接地气、最有指导性的内容，也是最难界定的。主要原因如下:

定义太细，担心后续设计缺乏前瞻性限制:定义越细，灵活性越低，后续的改动和限制就越高。为了避免这个问题，建议在定义关键页面时，遵循输出设计稿的思路:整理“信息架构”→定义“功能分区”，这样后续的扩展性和预见性更高。

定义太粗，怕缺乏实际指导意义，没有定义明确的功能分区:同一区域的页面有的显示操作，有的显示导航。从规范的角度来看，似乎不应该，但实际在各项业务中设置是合理的。当这种情况无法达到时，建议不要定义具体的“功能分区”，以免盲目追求统一而限制实际设计。但可以用“穷尽实例”的方式，把这个版面下可以承载的内容全部展示出来，既可以起到参考作用，也可以供后续使用，达到统一的效果。

第四步:添加案例:将刚刚定义的布局框架和功能划分与实际案例完全结合，方便后续理解和使用。

(3)一般过程

目标:整理全站所有流程，将那些可复用的流程整理、抽象、打包。让后续设计师和R&D可以直接使用。

“可重用流程”是指:在多种场景下，它可以“即插即用”而不改变其原有的业务逻辑。比如:登录注册流程，扫码关注流程，分享流程等等。通常，在一个通用流程中，不同的步骤可以被分解并重新组装成不同的流程，以适应特定的场景。

这里有一个具体的例子:注册流程。一般来说，完整的注册流程如下。被不同入口触发后，通过一定步骤后注册成功。

当业务需求更进一步，需要通过插件快速登录时，可以将步骤重新组合，然后适应具体场景。

设计师需要做的是确定具体的一般流程，一步一步连接起来。当新的需求来临时，判断是否可以直接重用，是否需要重新组装，或者是否需要增加新的步骤。

这种组装的思路正好对应了R&D的思路和建造过程。对他们来说，一个常见的过程是将不同的步骤结合起来。遇到不同的场景，就用积木组装起来。

具体的建筑步骤也由两个步骤组成:1 .第一步是收集过程；2.第二步是抽象步骤。具体方法上面已经说了，我就不多赘述了。

(4)标准组件

目的:将产品中使用的组件组织成“标准组件”，统一定义规则，以便在后续设计和R&D中直接调用组件，提高设计和R&D效率。

其实业内有很多常用组件都可以快速调用。但由于不同业务的复杂程度不同，也会产生各自独特的业务定制组件。同时，产品不断迭代，很难找到时间单独定义组件。因此，基于这一背景，结合“需求设计过程”和“组件排列过程”，有两种高效定义标准组件的方法。

方法1:调用行业通用组件

首先，业务设计决定了基本逻辑。

第二步，选择行业中常见的组件，添加业务规则。(一般在构建产品的初期，会选择使用一个行业组件，组件只能从这个提供的组件中选择)

第三步:视觉根据全局视觉原理设计新款式。

第四步是将交互规则和视觉风格组合成标准组件。基础规则直接引用行业组件的定义内容，场景规则按需补充。

模式二:业务定制组件

第一步是进行正常的业务设计。根据交互需求搭建原型，视觉设计具体风格。

第二步，判断组件是否具有通用性，是否可以复用到其他场景。比如共享对话框，可以用于不同的内容共享，比如这个就是可以抽象成标准组件的典型案例。

第三步是定义标准组件规范。简单的组件就能表现出特定的风格，团队里的设计师基本都有相同的认知，不需要重新学习。对于复杂的组件，为了保证后续的正确重用，建议包括以下内容:

更新:因为组件是最易变的规范，所以需要指定具体的版本和变化点。

组件定义:简单介绍用途和使用规则，如对话框的定义:必须由用户主动触发，主要用途直到第二次确认场景被用户确认后才会消失等。

组件:介绍组件的组成、功能分区和分区定义，详细展示不同分区中的具体信息和对应规则。

使用场景:详细区分各种场景下的不同使用模式，给出明确的使用指导。

设计方案:备选，如果部件复杂，涉及工艺中的关键环节，建议可以复制一套完整的设计方案嵌入其中，方便团队成员理解和使用。

第四步，与R&D沟通，打包成标准组件。这一步是非常关键和重要的一步，它将大大提高我们后续组件的复用率，减少重复走查的耗时。建议使用协同设计规范功能，点击体验协同设计小程序。上传“构件库”后，可以根据目录自动生成规范文档，同时可以自动标注和裁剪标准件，大大提高了R&D和开发的效率。

(5)复制规范

目的:组织产品各个场景中的文案，帮助商家更准确的表达意图，让设计师更好的使用，让用户感受到一致的产品风格。

文案就像“产品对用户说的话”。不同的人可能说话方式不同，没有绝对的对错。但清晰的语言表达让用户更容易理解；符合产品气质的基调，可以拉近产品与用户的距离；统一的文案描述，还能让用户在全站一致的语境下体验产品。

需要定义的内容包括但不限于以下三个部分:

语言:语言是指我们用什么规则来组合词语，形成一种习惯表达方式。比如语句简洁明了，没有过度修饰，避免重复描述，使用简洁明了的语序，帮助用户快速理解；比如用词要精确易懂，要使用简单易懂的词，避免使用过于口语化的技术术语或表达方式。单纯说规则可能太空洞。在实际定义规范时，有必要展示下图，加上实际案例，以免产生误解。