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

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

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

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

　　对组件化的认同、共识

　　是否认同组件化设计?

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

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

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

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

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

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

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

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

　　设计前期

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

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

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

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

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

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

　　3. 提升同理心，积累塑造自己的知识体系，拓宽自己的需求视野。

　　项目问题与解决方法