设计实战教育产品组件化交互设计的实践与思考

网易UEDC – 王媛媛 ：组件化设计，就是设计模块化，组件可复用。是以通用化的视角审视模块设计，根据营业方需求支持多个产品的接入与使用。

在线教育领域内，标题是线上线下教学场景内校验学习的一种基本体例，同时，标题可以存在于题库内，题库和组卷是承载标题的通常载体，而这两个载体在各产品教学体系内有共有的需求，因为需求重合度较高，又具备高度的通用性。

所以，以组件的体例设计「题库」和「组卷」这两个模块，通过多种角度去衡量都是有其存在价值的。多方考虑后，由教育部门EduOS团队负责完成题型的重构、题库的创建与管理、组卷的体例等模块的组件化设计。同时在考虑可行性和基础框架的基础上，实现一个可在网易100 分、中国大学 MOOC 、云课堂 C/B 端使用的题库及组卷。在资源共享的情况下，可以调用组件，可以复用代码，也可以考虑通用模块功能等。

这篇文章重要是以抛出题目，通过需求认同、共识 > 设计前期 > 项目题目及解决方法 > 理解与思考这4个部分进行逐条讲述在这个过程中的实践与思考。

一. 对组件化的认同、共识

是否认同组件化设计？

可能有些交互设计师本能上是抗拒组件化设计的，由于组件化的设计从某种角度上讲可能会扼杀设计师对产品设计的创意。从交互视角看组件化设计，首先必要认同组件化设计。这里可以探究两个题目。

1. 组件化设计能给产品或营业方带来什么？

组件化设计带来的是复用：设计的复用，开发的复用，用户体验的复用。复用可以进步服从，在产品迭代的过程中进步服从，在用户体验的使用上进步服从，避免用户因产品同类功能的操作不同等而降低使用体验，而且后期组件可以同步迭代更新。

2. 一样平常营业方应该会更正视产品内用户场景性体验设计，那组件化设计后会不会捐躯营业方产品的用户体验？

在组件设计初期，交互设计师也必要充分发掘当下产品营业方尽可能多的需求，乃至将来潜在的营业需求，从需求的框架上抽象出组件模块设计。但这里的组件设计并非仅做全局框架设计，组件的细节也是必要打磨的，而且组件化设计要凌驾于肯定的交互规范基础之上，避免后期设计的“滥用”。另外，在打磨细节时，尤其要细致体系的稳固性和可维护性，能保证后期体系经过若干迭代后还能维持一个运作优秀的生态体系。

什么样的需求或产品可以去做组件化设计？

目前组件化已经趋于普遍，单一功能的组件更常见，比如搜索组件、筛选器组件，也有较完备的功能模块组件。每一个组件都是一个完备的产品，它们在营业产品内赓续扮演着再组合更多产品的角色。但并不是所有的功能都适合去做组件，组件自己不存在影响产品的好与坏，最紧张的是在驱动组件化设计及升级之前，要以组件化思维的姿态，对项目近况有比较清晰的评估和认知，周全审视需求方向，考虑解决方案，提炼全功能组件。

在衡量组件化设计这个题目上，也可以去尝试探寻一些量化方法，当然也不局限于量化的数据，更紧张的发掘产品方及用户的诉求。这就必要考验组件提议者对产品需求的思维广度与深度。

二. 设计前期

怎样快速接收并消化组件化需求？

拿到需求后怎么动手去消化并分析需求，也就是我们设计前期应该做好哪些工作？从确定提议做题库组卷模块的组件到项目落地，我几乎没有富余的时间去深入了解需求。

简单分析一下，首先组件化需求的特点是营业需求下沉，需求功能模块化，模块与模块关联性更强。组件化需求的终极目标是将需求实现成由n个box组合而成的功能，类似于乐高积木，虽然每个积木都是相互自力的，但是可以天真，可以多样。同样，组装起来的组件模块也是天真多样的，功能也是壮大的，所包含的逻辑性也就更强。所以，面对组件化需求，根据其需求特点，总结了以下几点快速接收消化需求的方法：

1. 需求思维模块化，快速分解需求。组件与组件之间不应该存在环形依靠关系，所以大可以去快速分解需求。换种说法，就是将营业设计思维转化为通用设计思维。

举个简单例子：题库需求可能涉及到多种题型，比如单选题，多选题，填空题，组合题等。题型与题型之间会有雷同属性和不同属性，那就必要将所有属性抛开题型抽离出来，对雷同属性进行分析，雷同属性即可设计为同类组件，甚至也考虑可以使用统一组件。

2. 尽可能完备地走查和整顿所有已有 & 潜在营业场景，并根据对需求稿的理解构建全局观，全链路考虑解决方案。

3. 提拔同理心，积累塑造本身的知识系统，拓宽本身的需求视野。

三. 项目题目与解决方法

在现实的设计与项目进展中，多多少少都会碰到许多题目。总结了以下几个比较典型的题目及解决方法。同时这几个题目也是做组件化需求尤其要细致的题目。

如何保证组件设计的同等性？

组件化交互设计最基本的一点是保证设计的同等性。在预备将某个功能模块做成组件时，我们通常要考虑所做的设计够不够通用，能不能知足接下来的需求？除了学习参考iOS，andriod和其他操作平台的原生设计规范外，这里分享两种简单的方法：

1. 尊重用户风俗。可以遴选如今比较成功的同类竞品，将其产品框架结构及操作规范梳理一下，一样平常竞品成功的缘故原由不外乎两个：一是给用户带来了使用价值，二是给产品方带来了商业价值。既然给用户带来了使用价值，那这些产品的功能或操作体验在某种意义上讲应该是基本吻合用户生理预期的，这些成功竞品的功能或操作规范也是和用户的风俗相辅相成的，是有借鉴意义的。

2. 将需求最终呈现为交互框架时，可以尝试自上而下对信息结构化归类。比如归类颗粒度为：操作属性，信息展示属性等等，而信息展示属性又可以向下归类为列表类，卡片类等等，这就可以回归到我们常说的交互组件库。比如下图所示，题库的管理与试卷库的管理。题库是对标题的管理，试卷库是对单份试卷的管理，虽然是两个不同的功能模块，但确有着极相似的操作属性与信息展示属性。

如何保证设计方案的可行性？

在组件化交互设计上，保证设计方案可行性也是特别很是紧张的。既然是整个功能或模块去做组件化设计，那它的逻辑性相对来说也是较为复杂的，由于它融合了更多营业方产品的需求。而我们的目标就是必要将这些复杂的需求转化为更简单，更天真的功能，知足不同的需求。

在交互设计上，为了保证设计方案的可行性，首先要考虑整个设计的环路，无论是应用层，框架层，逻辑层都要 一 一 分析，然而真正在项目实践中，时间很难许可我们去套用完备的研究方法论，只能靠经验或本身风俗的设计方法快速产出最终目标。

这里保举一种针对复杂项目分外实用的设计分析方法：通过基因分解，解构基因，再整合基因的方法，梳理结构、时间线、基因之间的关系去组织新的信息结构、并设定目标义务流程。这里的基因可以是需求，可以是模块，可以是场景，也可以过细到项目流程中的每个环节。也可以通过（人）人物原型，（事）要解决的需求，（物）所在的当了局景去分析。分析到位后再整合到整个设计过程中。

以下通过EduOS所做的题库组卷案例简单分析几个模块：

1. 应用层。题库组卷作为教学体系模块，可以从教学后台和用户学习前台两个场景下梳理需求及流程。将每个场景下的时间节点与操作节点梳理出来，并整顿两个场景下的流程关联关系。

2. 框架层。在组卷内，本来的组卷体例根据4种不同的组卷形态存在4种不同的设置体例，情势单一，不够天真。而题库组卷的需求是盼望做更天真，更通用的组卷体例，而不局限于组卷的形态。所以明确了如下图所示的需求设计方向。

另外，此次组卷我们新增了主客观组合在一路的组合卷。所以必要分析新的组合卷比较以往的组卷情势，它们的区别以及各自的属性分别是什么。

3. 逻辑层。再来分别分析一下题库及组卷的营业流程及操作逻辑，结合其操作属性构建完备的设计环路，并将其转化为更直观的流程图。

4. 整合。最后将最终分析出来的有用基因进行整合，将整个环路整顿出来，在这基础上再来进行交互大框架的设计。另外，组件化需求一样平常是在已有功能的基础上被发起的，产品策同等般会对产品设计的体例定义为3种：复用，配置，定制。这3种体例同样影响到交互设计方案。

在了解组件背景（需求大背景）、组件衍生需求场景、组件存在情势的时候，切记不要急于设计方案，即使担任的是交互设计角色，最好也要了解组件如何接入产品、组件特征、营业方产品特征、接入影响范围等等，了解这些对组件化的设计也是有很大帮助的。

EduOS项目从需求环节上就已经梳理出大部分逻辑层的内容，所以在设计过程中能比较快速的理解与分析这些环路。同时，整个过程经过产品，设计，开发，测试共同的努力下，经过多次方案的优化与设计完成了最终产品底层框架的搭建和功能设计。

如何避免非常情况的疏漏？

在组件化设计的过程中，不乏逻辑过于复杂导致需求调整或交互设计不周全的题目。这里保举一种节点式的排除法，即将流程关键点梳理出来，通过这些关键点行止理非常情况。

即将用户对应的操作时间点和影响因子 一 一 列出，连线分析可存在场景，并检查这些场景是否都 一 一 处理。比如影响到门生答题中这个状况下的非常因素就有这几个：试卷发布，授权标题被取消，先生修改标题内容或分值，先生重新判分，答题限时已到，提交截止时间已到，URL进入试卷等等。

四. 理解与思考

以下几点是在整个EduOS项目中对组件设计的几点思考。

天真高效+重易用性

在组件通用的基础上，终极目标是天真高效协作。同时，在项目进行中，可以针对某一项通勤奋能在短时间内尝试多种设计方案，尽量考虑多种场景，简化操作流程，重易用性。好的组件设计，会给产品带来创新，带来更好的体验。

关联性

做产品的组件化设计，要正视关联性，包括功能与功能之间的关联性，同时也包含前后台用户之间的关联性。

营业兼容+可扩展性

做产品的组件化设计，要兼容营业，同时对于扩展性要求很高，所以要求产品及设计能够在熟知营业的基础上，有抽象建模的能力，能够抽象出模块与模块之间的关系，有很好的产品前瞻性，如许保证后台产品架构上清晰天真，扩展性强。同时，对平台载体和性能的限定也要考虑到，设计上也要考虑数据体系维护及设计的延展性。

目前，整个教育产品部门的发展规划模式上也会将部分需求抽象出一种公共能力，即抽象出若干组件去做，并将组件更好的服务于各产品线。

总之，做组件化交互设计，要做到：逻辑思路要清晰，交互设计要规范，产品结构要天真。有些人会简单的认为一个产品的后台就是对一个产品前台功能的配置，在此基础上能够知足产品方和用户使用产品的需求。但产品后台正是表现了整个产品的运营思路和营业逻辑。

迎接关注作者「网易UEDC」的微信公众号：