来了来了，我来了，我带着在线刷题项目的思考和总结来了。
年前就把这篇文章规划进清单里了，一方面是觉得在在线教育领域里，刷题应该是很具有代表性的一个项目，基于此也应该把这个项目沉淀下来。另一方面，这个项目中着实有些坑让我成长很多，也需要趁着这个机会梳理归纳一下零散的认知。
写在前面：
交互设计衔接需求和用户，交互设计做得不好，甭管界面做得多漂亮，用户体验都是支离破碎的。
组件化设计除了能提升设计开发验收效率，降低后期项目的维护成本，保证项目的可持续发展的稳定性外，还能非常好的保证用户体验的统一性。因此，提炼项目中可全局使用，对个性化需求不高的UI控件进行组件化是很有必要的。
除此之外，对设计师来说，输出组件化设计的过程其实是逼迫你深入项目去抓住细节，同时又从全局的角度对UI控件进行把控和管理。哪些可以进行组件化设计，哪些没有必要进行组件化设计，是很考验设计师对产品需求的认知广度和深度，很锻炼设计师的全局思维和剖析归纳需求的能力。
设计师只有不断拓宽自己的视野，才能更大程度的保证方案的通用性。非常建议设计师都应该有意识的锻炼自己这方面的能力。
当线下的“题海战术”被搬到线上之后，设计师需要注意什么？
我一直没有留心“效率”这个词，也一直以为我在“效率”上做得还不错，直到我在“效率”上跌了个大跤——组件化是由设计端发起，但不止是设计师的事。
在业务复杂又相对稳定的情况下，怎么提升协作和设计开发效率？怎么给用户创造统一的认知和交互？
这是我在某次版本进行了N轮低效率设计验收后的自问，也是我真的意识到交互设计和组件化设计在一个项目中的重要性。
这篇文章会以组件化设计为主线，交互设计为支线剖析刷题项目。
在设计方面，业务的复杂性表现为刷题类型和刷题模式的多样化，及它们之间的自由组合：
无论是什么类型(整卷、章节、错题、收藏)，无论是什么模式(考核、练习、背题)，它们进行自由组合后，交互和逻辑可能不同，但UI层面上是存在共性的。
比如功能区：
比如功能区-操作栏-按钮类型：
比如功能区-操作栏-答题卡：
以上只是列举了答题详情页面里各类型和模式自由组合情况，可以发现它们自由组合后UI元素间是存在的共性联系。
刷题业务当然还由其他场景组成， 场景之间肯定也存在共性联系和共性控件。这里就不一一列举出来了，只要把最核心的场景捋清了，其他也就好办了。
组件化的终极目标是实现共性控件间的自由组合，解决重复性页面设计、低效率的沟通、落地稿还原的问题。因此，每个控件都应该是相互独立的。
基于上面的分析，其实已经可以确定答题详情页面中存在哪些共性控件了。组件化设计思维是把视觉表达模块化，前期创造一个好的设计，后期可以直接进行复用，快速完成产品迭代，还能保证同类功能的操作拥有统一的用户体验。
怎么做组件化设计呢？
在组件设计初期，设计师需要对项目有比较清晰的评估和认知，需要了解业务方产品特性，多维度地把关键点列举出来，以点带面通过关键点去处理各个场景状态，从而把控并创造一个通用性更大的组件。
一个完整的组件方案，必定是可将组件视为一个独立的产品。可以按照下面的步骤开展组件化工作：
在进行组件化之前要先确定好命名规则，是按照尺寸进行区分，还是按照功能进行区分，个人在试验过程中觉得按照功能进行区分会更好用些：
先对颜色、字体、图标这些基础元素组件化操作，获得「原子组件」。其中图标组件化中，某些按照颜色区分状态的图标需要嵌套颜色组件，以达到智能更换颜色的效果：
然后使用「原子组件」拼装出通用性强的「分子组件」，在这一步骤中需要做好布局，比如图标是否跟随文本：
用做好的「分子组件」再拼装出「组织」：
以「组织」为单位，从数据、行为、状态三个维度入手，把各种状态都列举出来，组成可以直接使用的「模板」：
在实际的组件化工作过程中，为了保证组件目录的整洁，我把同类功能的「分子」、「组织」、「模版」划分进了同一个目录中：
最后，在刷题这个项目中，常见的控件类别大概为以下11类：
项目的不同，需要整理的组件也不同，控件分类也不同。把对个性化需求不高，可重复利用的UI控件进行组件化，实现快速调用和统一用户体验的目的。
这里是剖析了刷题里的其中一个场景，其他的场景同理可得，所以就不说啦～
