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

2017-10-17 09:45:00

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

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

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

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

对组件化的认同、共识

是否认同组件化设计？

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

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

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

一般业务方应该会更重视产品内用户场景性体验设计，那组件化设计后会不会牺牲业务方产品的用户体验？

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

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

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

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

设计前期

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

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

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

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

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

尽可能完整地走查和整理所有已有 & 潜在业务场景，并根据对需求稿的理解构建全局观，全链路考虑解决方案。
提升同理心，积累塑造自己的知识体系，拓宽自己的需求视野。

项目问题与解决方法

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

如何保证组件设计的一致性？

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

尊重用户习惯。可以挑选现在比较成功的同类竞品，将其产品框架结构及操作规范梳理一下，一般竞品成功的原因不外乎两个：一是给用户带来了使用价值，二是给产品方带来了商业价值。既然给用户带来了使用价值，那这些产品的功能或操作体验在某种意义上讲应该是基本符合用户心理预期的，这些成功竞品的功能或操作规范也是和用户的习惯相辅相成的，是有借鉴意义的。
将需求最终呈现为交互框架时，可以尝试自上而下对信息结构化归类。比如归类颗粒度为：操作属性，信息展示属性等等，而信息展示属性又可以向下归类为列表类，卡片类等等，这就可以回归到我们常说的交互组件库。比如下图所示，题库的管理与试卷库的管理。题库是对题目的管理，试卷库是对单份试卷的管理，虽然是两个不同的功能模块，但确有着极相似的操作属性与信息展示属性。

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

在组件化交互设计上，保证设计方案可行性也是非常重要的。既然是整个功能或模块去做组件化设计，那它的逻辑性相对来说也是较为复杂的，因为它融合了更多业务方产品的需求。而我们的目标就是需要将这些复杂的需求转化为更简单，更灵活的功能，满足不同的需求。

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

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

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