如何建立交互设计控件库

前几天在公司内部跟大家分享了一个主题：如何建立交互设计控件库。当时HR发这个报名邮件的时候，马上就有同学过来说：既然要分享这个主题，说明你已经建完了，那你的源文件发我一份，我直接用，不就完事了吗？另外有人说：控件库这个东西我们项目组也是老早想建了，但是涉及到很多小的点，突然一下子不是从哪里开始。 那今天的内容，就是针对这些问题，讲讲为什么要自己建，以及怎么建，建完之后怎么落地。今天的主要内容不是停留在axure里面控件库，而是跟视觉、开发协作，实现一个代码化的控件库，也就是说，开发写代码的时候就可以直接拖出来用的 一个模块。

核心内容
我们知道封装的目的是为了“复用”，用低成本换取高回报。所以要封装的对象肯定是个 明确目的、然后能复用的，粒度很小的基本元素，比如说标题栏、搜索结果、文章等。这些模块可以用在很多地方，需要用的时候直接拖就行了。找出这些需求，再将它代码化，实现出来。是不是听起来就很美好？但是这个前期过程是非常虐心的 。下面来讲讲如何封装，怎么去识别哪些控件是值得封装的 ？

流程
跟平时做项目一样，建控件库也涉及到搜集需求--设计-到开发落地这样一个流程，建完之后再不断迭代，要保持组件库的更新，从而保证对于项目的支撑。在搜集需求阶段，交互设计师需要去识别哪些是适合封装的，再进行归纳。我们先看怎么识别。

1.1、识别可重用的元素
我们以一个页面为单位，比如说这个云阅读书架的首页，看一下界面上没法再继续划分的部件，比如说搜索、添加、书籍封面、书籍名称、书籍阅读进度 或者下面的按钮，这些都可以划分为元素。 那么，哪些是可重用的元素呢 ？因为可重用才有意义对吧，不能重用的就相当于再写一个，就没必要封装了。对于可重用这个问题，我们就很有必要了解一下开发的视角，看他们在实现的时候是如何布局的。

以这个页面为例，就是一个书籍列表页面。在开发眼里，它就是划分为这样的三个模块：最顶部的标题栏、最下面的tabbar、剩下的留给中间的listview  。再看另外一个界面的例子，这是我们的一个文章正文，当页面从上往下滑的时候，下面的工具栏会消失，这个过程中，布局跟上个页面就有区别，他涉及到一个层的概念。工具栏所在的层就和文章正文不在同一个层内。

在了解开发同学的视角后，能帮助我们把出这些可重用的元素，像文本、按钮、链接、复选框找出来，或者是他们的组合，并且在设计过程中可以重用。以上这个过程其实是一个穷举、发散的过程，旨在结构分析，找出共通性及可变性。
1.2、归纳整理
发散完成之后，要收，进行归纳整理。这个时候就将前期整理的元素进行分门别类，大致分为这些类。这个分类过程也很重要。就我们云阅读里书籍一样，要符合用户的预知，不能把一本盗墓笔记放到都市言情里面。所以说这个分类也要符合其它设计师和开发的预期，一般都会用系统的规范的命名和分类方法，如果有相类似的，再备注一下所用的地方。比如说下面光列表就有好几个，有文章、有书籍、有专题的。在后面备注一下就可以了。整理之后，这个应该怎么用？怎么落地  举几个例子你就了解了。

以弹层为例，我们要找出现在哪些地方有弹层，有哪几种形式，分别有什么用处。比如说，把云阅读里面的所有弹层给整理出来，最后总结归纳成几种形式。比如说页面当中的。#分别讲一遍。#理完这些是不够的，我们需要小范围评审，交互组内过一遍，跟开发过一遍，这个过程其实是比较快的。没有问题之后，提交给视觉，视觉再细化形成规范，细到尺寸多少，标题描述字号多少。操作键 字号色值多少。甚至这当中有哪些是衍生的样式，也给标示出来，所谓衍生，就是你在代码实现出来后，如果下次要复到衍生样式，你把原有微调一下就可以了，就说  最上面这个活动，有的时候编辑或者运营是没有配图的。展现形式上不同，但我们模块化之后，开发可以把他当同一样东西来处理，就是把这个组件的代码里面的 图片去掉就可以了~

所以说，哪些组件满足封装需求？
*新的变动只需衍生类别，顶多微幅调整，架构基本不动-- 封装变化
*一个物件不用处理多种变化—高内聚
*控件之间关系更清楚，可免不必要的牵连—松耦合
搜集需求以后，我们就得进行设计和开发，这个流程跟在项目过程中是一样的。反复的迭代。在此过程中可能有的两个矛盾点：

2.1、标准VS创新
再炫酷的功能，都要先注册登录。而这个模块无法激起设计师创造“前所未有”这种成就感。但是如果不去做的话，开发就会面对一些未知的问题。
所以说，不管对于开发还是设计， “重用”是最优先考虑的事情
2.2、整体产品的一致性VS业务的个性化需求
完整的产品总是第一位的，任何的个性都是基于此的标准下凸显个性。放任和有节奏的控制所产生的结果不同，这是我们对一致性问题进行设计的真正目的。