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

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

　　如何避免异常情况的疏漏?

　　在组件化设计的过程中，不乏逻辑过于复杂导致需求调整或交互设计不全面的问题～这里推荐一种节点式的排除法，即将流程关键点梳理出来，通过这些关键点去处理异常情况。

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

　　理解与思考

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

　　灵活高效 重易用性

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

　　关联性

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

　　业务兼容，可扩展性

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

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

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

　　一个完整的，良性运营的后台是对一个产品健康发展的重要保障。当然，关于某个模块的组件化设计，决计不是一篇千字不到的文章就可以将其整个生命周期阐述清楚的，因此，这里只跟大家交流一下在组件化设计过程中总结出来的设计方法和对后台组件化设计的理解与思考，仅供大家交流~